Date: Sun, 06 Dec 1998 16:54:08 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: alk@pobox.com Cc: net@FreeBSD.ORG Subject: Re: resolver behaviour Message-ID: <199812062154.QAA01615@whizzo.transsys.com> In-Reply-To: Your message of "Sun, 06 Dec 1998 14:59:05 CST." <13930.53261.509843.979179@avalon.east> References: <13930.17883.922553.625725@avalon.east> <48026.912946905@gjp.erols.com> <13930.53261.509843.979179@avalon.east>
next in thread | previous in thread | raw e-mail | index | archive | help
There are more than two types of responses you'll get returned from a name server when you make a query upon it. Either you get: - the data you asked for; - you get a NXDOMAIN (non-existant domain) error response; - you might get a "administratively prohibited" error; - you might get a response indicating that the server won't perform recursion for you; - you might get a "server failure" message, indicating that a server which is an authoratative server for a zone knows that it's broken. - or the software performing the query abandoned it waiting for a response, perhaps due to a timeout. The BIND *implementation* model (which differs from the architectural model of the DNS) presumes that a small stub of code is linked in the application (the resolver), and has robust connectivity to a name server that's willing to perform recursive queries on behalf of the resolver. This implementation model isolates both state and implemenation complexity outside the application or process which wishes to perform a DNS query. There are advantages in doing this, such as having a cache which persists beyond the lifetime of a single process, smaller memory footprint for each application, etc. However, the downside is the inability to retain any state from process to process; one instance of sendmail has no memory or hints from the previous one. The is OK in the BIND implementation model, as the presumption is that the named daemon (which is running ON THE LOCAL MACHINE) has this cached state and can do the right thing. This implementation model presumes robust connectivity between the resolver and the "local" nameserver that's willing to perform recursive queries and maintain cache state. The named daemon already keeps track of "dead" or non-responsive name server; in fact, for the multiple name servers associated with a zone, it times the response from each one (when it has occasion to make multiple queries), and will prefer the one which responds the fastest. Much of what you want, I think, is already implemented inside of named. The mistake, I think, is in loading too much functionality in what is intended to be a very simple software module with minimal complexity. This is all by design. The fact that multiple name server can be listed in /etc/resolv.conf is so that the resolve isn't completely screwed should the local named process fail; perhaps you backup to some other machine on the same LAN. But the underlying presumption is that the connectivity between the resolver stub and the named process be robust and the failure modes "simple." It's just wrong that you would get a non-existant domain error from one name server, and the correct data from another; multiple authoratative servers for a zone are supposed to have identical copies of the zone. If they don't then there is a problem with the name servers, and not how the resolvers are behaving. It's also very dangerous to ignore non-existant domain error responses; if you do, then you defeat a powerful scaling tool in the DNS which enables name servers to cache negative responses. Having previously operated one of the root name servers in a previous job, I was amazed as the number of truly bogus names which are trying to be resolved. At the time, a whole bunch of them ended in .BITNET :-) Negative caching helped this problem a lot, since the source of many of these bogus names were sendmail daemons trying to canonicalize names with various suffixes, sigh. The negative cached kept that from happening as an external event very frequently. Louis Mamakos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812062154.QAA01615>