home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sun / admin / 5052 < prev    next >
Encoding:
Text File  |  1992-07-28  |  2.5 KB  |  53 lines
  1. Newsgroups: comp.sys.sun.admin
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!destroyer!lambda.msfc.nasa.gov!avdms8!jpc
  3. From: jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
  4. Subject: Re: DNS & Resolver. Things Sun should do.
  5. Message-ID: <jpc.712372686@avdms8.msfc.nasa.gov>
  6. Keywords: DNS
  7. Sender: news@lambda.msfc.nasa.gov (Newsmaster)
  8. Nntp-Posting-Host: avdms8.msfc.nasa.gov
  9. Organization: NASA/MSFC
  10. References: <yvent.711983630@theseas> <1992Jul24.144817.23307@aio.jsc.nasa.gov> <hanson.711995288@pogo> <jpc.712190285@avdms8.msfc.nasa.gov> <1992Jul27.130038.27277@ccu.umanitoba.ca>
  11. Date: 29 Jul 92 01:18:06 GMT
  12. Lines: 39
  13.  
  14. mills@ccu.umanitoba.ca (Gary Mills) writes:
  15.  
  16. >In <jpc.712190285@avdms8.msfc.nasa.gov> jpc@avdms8.msfc.nasa.gov (J. Porter Clark) writes:
  17.  
  18. >>Does this mean that the bug wherein NIS remembers that a DNS lookup
  19. >>failed will be fixed?  I'm referring to a longstanding problem in which
  20. >>an initial failure of the resolver (perhaps because the response from
  21. >>the nameserver arrived too late) will cause the lookup to fail from
  22. >>that point on.
  23.  
  24. >I don't see this problem.  After I add a new host to the DNS, I can start
  25. >doing ypmatch on that host, and in five or ten minutes it will appear.
  26. >I assumed this was due to caching by ypserv, which should be a good thing
  27. >because it should reduce traffic between NIS and DNS.
  28.  
  29. Sure.  If you add a new record to DNS relatively close (in terms of
  30. delay) to the host, you will get a ypmatch.  No problem there.  But
  31. let's say somebody out in some part of the net quite distant to you
  32. adds a new host to his DNS over there.  Now try to ftp to it or ping
  33. it.  Maybe you folks out there have some sort of special relationship
  34. with the Internet somehow, but that DNS lookup is going to take a
  35. little while to ripple through the DNS hierarchy from where I am.
  36. Chances are very good that the first lookup is going to fail for me.
  37. If I wait a few seconds after the first lookup and try again with DiG
  38. or nslookup, it will usually work.  But the problem is, NIS has already
  39. learned from its earlier failure and will never return an IP address
  40. for that hostname until ypserv and ypbind have been restarted.  cd
  41. /var/yp and make will *not* work, either.
  42.  
  43. This, to me, is a Bug.  I have seen a followup and a reply in which
  44. this was deemed to be desirable or otherwise unavoidable behavior.
  45. How?
  46.  
  47. I think it's dandy that ypserv caches the data.  But if it gets a
  48. request for a hostname mapping that's not in its cache, it should go to
  49. DNS.  Every time.
  50. --
  51. J. Porter Clark    jpc@avdms8.msfc.nasa.gov or jpc@gaia.msfc.nasa.gov
  52. NASA/MSFC Communications Systems Branch
  53.