Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!LCS.MIT.EDU!sra
From: sra@LCS.MIT.EDU (Rob Austein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: name handling in DNS resolvers
Message-ID: <9105182128.aa02177@yaya.lcs.mit.edu>
Date: 19 May 91 01:28:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 49

Any further discussion on this topic should move to the mailing list
Namedroppers@NIC.DDN.MIL (aka USENET comp.protocols.tcp-ip.domains).

There are two issues here:

1) What kind of user interface will allow nicknames without accidently
   breaking things for users whose configuration, although legal, is
   not what the implementor had in mind?

2) What kind of user interface can the Internet support without
   spending too much of the available bandwidth on DNS queries?

Previous messages from John Romkey and James Van Bokkelen gave some
reasons why issue (1) is harder than it looks.  Here's another: what
should your resolver do if, in the process of following your search
path, it hits a zone whose name servers are dead or inaccessible?  The
only safe thing to do is give up.  This does not make users happy.
Users who are not intimately familiar with the DNS find this
particularly frustrating, since, from their point of view, whether a
particular nickname works on a given day is completely unpredictable.

Issue (2) is the reason for the comments in RFC 1123 about avoiding
excessive root queries.  As someone who has written a resolver that
supports negative response caching, I think RFC 1123 allows lazy
implementors to get away with murder by allowing the use of search
paths with only the internal-dot detection algorithm.  Ok, it protects
the root and the top-level name servers, but there are some pretty
huge non-leaf zones further down the tree (in the MIL subtree, for
example), and the internal-dot algorithm doesn't help them at all.
The only defense that the name servers of these zones have against
being beaten into the ground by resolvers with lame search path
implementations is to trust the administrators who own those resolvers
not to put these name servers on search paths.  Given the number of
administrators who appear to believe that the readability of the Bind
Operators Guide and the DNS RFCs could be improved by translating them
all into ancient Sanskrit, I do not find this prospect reassuring.

Also note that even negative response caching doesn't solve all the
problems with search paths, because some name servers lie.  If you
cache negative responses, you believe those lies without trying again
until the TTL expires, unless you impose an arbitrary ceiling on the
TTLs in your negative response cache.

The people at WSMR-SIMTEL20.ARMY.MIL are running my resolver code.
The last time I checked, they had both search paths and negative
response caching turned off, because they prefered a predictable
universe to the convenience of search paths.  I don't blame them.

--Rob Austein