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.49vs483 < prev    next >
Text File  |  1993-07-06  |  2KB  |  38 lines
  1. Newsgroups: comp.protocols.tcp-ip.domains
  2. From: marka@syd.dms.CSIRO.AU (Mark Andrews)
  3. Subject: Re: BIND 4.9 bug?: Losing RRs at zone boundries
  4. Message-ID: <C95n1r.G37@syd.dms.CSIRO.AU>
  5. Sender: news@syd.dms.CSIRO.AU
  6. Organization: CSIRO Division of Mathematics and Statistics, Australia
  7. References: <1993Jun24.191743.23086@cs.cornell.edu>
  8. Date: Fri, 25 Jun 1993 02:03:27 GMT
  9.  
  10. In article <1993Jun24.191743.23086@cs.cornell.edu> parmelee@cs.cornell.edu (Larry Parmelee) writes:
  11. >We've just observed a problem today where our SECONDARY nameservers
  12. >lost some critical MX and A records.  The RRs in question were MX and A
  13. >records for some of our subdomains, for example "CS.CORNELL.EDU" lost
  14.  
  15. >Anyone else seen this problem?  Anyone have a fix?
  16. >
  17. >-Larry Parmelee
  18. >parmelee@cs.cornell.edu
  19.  
  20. This is a side effect of the switch to 4.9. Older buggier nameservers
  21. passed out MX and A records for the child zone. When the parent zone is
  22. updated it no longer has theses bogus records transmitted and the
  23. secondaries dutifully note that this has happend and cease to know about
  24. then.
  25.  
  26. This can be fixed by
  27.     1. restart all the secondaries (the cached zones are ok) or
  28.     2. update the serial numbers of all the child zones.
  29.  
  30. As far as I can tell it only happens when a nameserver is secondaring
  31. both the parent and child zone.
  32.  
  33. When a primary nameserver switches to 4.9 I recommend updating all
  34. serial numbers for the zone that it is a primary, and for all zones that
  35. are children of those it in primary for.
  36.  
  37. Mark.
  38.