Subject: Negative caching problem
From: [email-masked] (Steve Hubert)
Date: 28 Jan 1994 11:10:29 -0800
Newsgroups: local.mail.dns.bind

We've been experimenting a little with negative caching and have run into
a problem.  The problem is with the Ultrix4.2a gethostbyname() resolver
algorithm.  We wonder how widespread this problem is, since I believe this
is based on some old version of BIND. 

We have a host carson.u.washington.edu.  Suppose I am on a host called
host.cac.washington.edu.  I have searching turned on in the resolver
options and a search list of "cac.washington.edu" "washington.edu".  If I
try something like "telnet carson.u" here's what can happen. The first
question my resolver asks is for the A record for
carson.u.cac.washington.edu. If it isn't in the negative cache, the answer
may be fetched from an auth. server and an auth. NXDOMAIN returned.  If
the answer is in the negative cache the same NXDOMAIN answer will be
returned but it will be non-authoritative.  The non-authoritative NXDOMAIN
answer causes the Ultrix search algorithm to terminate the search and not
try the next element which would be carson.u.washington.edu.  So "telnet
carson.u" fails with a no such host error.  Typically, it works the first
time and then fails the second (when it has been cached).  The offending
code is in res_query().  There they have something like: 

  switch (hp->rcode) {
    case NXDOMAIN:
      if (hp->aa)
        h_errno = HOST_NOT_FOUND;
      else
        h_errno = TRY_AGAIN;
  ...

The TRY_AGAIN answer causes the search to terminate early in res_search().

The 4.9.2 version of this same piece of code is simply:

  switch (hp->rcode) {
    case NXDOMAIN:
      h_errno = HOST_NOT_FOUND;
  ...

So, the question is, is this just an Ultrix bug in gethostent.c, or did
it originate with some old BIND and might it therefore be much more
widespread? 

Thanks,
Steve Hubert <[email-masked]>
Networks and Distributed Computing, Univ. of Washington, Seattle