home *** CD-ROM | disk | FTP | other *** search
/ PC-Online 1996 May / PCOnline_05_1996.bin / linux / source / n / bind / bind-4.001 / bind-4~ / bind-4.9.3-BETA9 / conf / Info.Ultrix-ncache < prev    next >
Internet Message Format  |  1994-04-08  |  3KB
  1. Path: vixie!Pa.dec.com!bind-redist-request
  2. From: hubert@cac.washington.edu (Steve Hubert)
  3. Newsgroups: local.mail.dns.bind
  4. Subject: Negative caching problem
  5. Date: 28 Jan 1994 11:10:29 -0800
  6. Organization: A blearily-installed InterNetNews site
  7. Lines: 45
  8. Sender: daemon@vix.com
  9. Distribution: local
  10. Message-ID: <Pine.3.90.9401280920.18244C-0100000@shiva2.cac.washington.edu>
  11. NNTP-Posting-Host: gw.home.vix.com
  12. X-Received: by gw.home.vix.com id AA01707; Fri, 28 Jan 94 11:10:20 -0800
  13. X-Received: by inet-gw-2.pa.dec.com (5.65/13Jan94)
  14.     id AA12608; Fri, 28 Jan 94 11:09:05 -0800
  15. X-Received: from relay1.UU.NET by inet-gw-2.pa.dec.com (5.65/13Jan94)
  16.     id AA11016; Fri, 28 Jan 94 10:33:56 -0800
  17. X-Received: by relay1.UU.NET (5.61/UUNET-internet-primary)
  18.     id AAwavg00600; Fri, 28 Jan 94 13:11:19 -0500
  19. X-Received: from shiva2.cac.washington.edu by relay1 with SMTP 
  20.     (5.61/UUNET-internet-primary) id AAwavg00573; Fri, 28 Jan 94 13:11:12 -0500
  21. X-Received: by shiva2.cac.washington.edu
  22.     (5.65/UW-NDC Revision: 2.29 ) id AA18978; Fri, 28 Jan 94 10:09:31 -0800
  23. X-To: BIND list <bind@uunet.uu.net>
  24. X-Cc: Namedroppers list <namedroppers@nic.ddn.mil>
  25. X-Mime-Version: 1.0
  26. X-Content-Type: TEXT/PLAIN; charset=US-ASCII
  27. X-Status: seems like an ultrix bug to me
  28.  
  29. We've been experimenting a little with negative caching and have run into
  30. a problem.  The problem is with the Ultrix4.2a gethostbyname() resolver
  31. algorithm.  We wonder how widespread this problem is, since I believe this
  32. is based on some old version of BIND. 
  33.  
  34. We have a host carson.u.washington.edu.  Suppose I am on a host called
  35. host.cac.washington.edu.  I have searching turned on in the resolver
  36. options and a search list of "cac.washington.edu" "washington.edu".  If I
  37. try something like "telnet carson.u" here's what can happen. The first
  38. question my resolver asks is for the A record for
  39. carson.u.cac.washington.edu. If it isn't in the negative cache, the answer
  40. may be fetched from an auth. server and an auth. NXDOMAIN returned.  If
  41. the answer is in the negative cache the same NXDOMAIN answer will be
  42. returned but it will be non-authoritative.  The non-authoritative NXDOMAIN
  43. answer causes the Ultrix search algorithm to terminate the search and not
  44. try the next element which would be carson.u.washington.edu.  So "telnet
  45. carson.u" fails with a no such host error.  Typically, it works the first
  46. time and then fails the second (when it has been cached).  The offending
  47. code is in res_query().  There they have something like: 
  48.  
  49.   switch (hp->rcode) {
  50.     case NXDOMAIN:
  51.       if (hp->aa)
  52.         h_errno = HOST_NOT_FOUND;
  53.       else
  54.         h_errno = TRY_AGAIN;
  55.   ...
  56.  
  57. The TRY_AGAIN answer causes the search to terminate early in res_search().
  58.  
  59. The 4.9.2 version of this same piece of code is simply:
  60.  
  61.   switch (hp->rcode) {
  62.     case NXDOMAIN:
  63.       h_errno = HOST_NOT_FOUND;
  64.   ...
  65.  
  66. So, the question is, is this just an Ultrix bug in gethostent.c, or did
  67. it originate with some old BIND and might it therefore be much more
  68. widespread? 
  69.  
  70.  
  71. Thanks,
  72. Steve Hubert <hubert@cac.washington.edu>
  73. Networks and Distributed Computing, Univ. of Washington, Seattle
  74.