Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del From: del@thrush.mlb.semi.harris.com (Don Lewis) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: DNS glue records and BIND 4.8 Message-ID: <1990Oct3.052611.6154@mlb.semi.harris.com> Date: 3 Oct 90 05:26:11 GMT References: <1990Sep25.140536.16449@mp.cs.niu.edu> <106322@uunet.UU.NET> <5652@munnari.oz.au> Sender: news@mlb.semi.harris.com Organization: Harris Semiconductor, Melbourne FL Lines: 111 Nntp-Posting-Host: thrush.mlb.semi.harris.com In article <5652@munnari.oz.au> kre@cs.mu.oz.au (Robert Elz) writes: >In article <106322@uunet.UU.NET>, asp@uunet.UU.NET (Andrew Partan) writes: >> We are currently having a problem caused (I think) by someone with a >> glue records for uunet.uu.net with the wrong address. > >Possibly, but also possibly not. > >> The only address >> that uunet.uu.net has is 192.48.96.2; however the address 137.39.1.2 >> keeps showing up. > >> We have been trying to track this down & kill it for a while now, but >> can't figure out where it is coming from. > >I think you'll find that its simply the various secondaries that >you have sending each other bogus info ... ie: currently munnari.oz.au >(one of the secondaries) believes that uunet has the 137 address, >and will almost certainly return that to uunet at some stage. >As you say, BIND will simply accept that and store it when it is >sent back, and then return it to munnri at some later time. > >I believe that the only way to kill this is to shut down every nameserver >from which you might conceivably ever have your address returned to you, >purge their caches, and backup zone files that contain the bad address, >and then restart them all (affectively simultaneously). > I solved a similar problem a while back. Host A was the primary server for Y.Z and secondary for X.Y.Z. Host B was the primary server for X.Y.Z and secondary for Y.Z. Host C was originally a secondary for X.Y.Z, but this function was transferred to host D. The NS record for X.Y.Z that pointed to C kept propagating back and forth between A and B via zone tranfers. Since I only had access to host A, I edited the Y.Z zone file to increment the serial number, and I edited the backup zone file for X.Y.Z on host A to remove the spurious NS record pointing to C. I then restarted BIND on host A, which loaded the primary and secondary zone files which were now free of references to C. When it came time for host B to refresh its copy of the zone file for Y.Z, it got an uncontaminated copy. The next time BIND on host B was restarted, it came up clean. This is will not work if the X.Y.Z zone file is updated and BIND on host B reloads it before being restarted from scratch, or if BIND on host A somehow receives bogus delegation information for X.Y.Z in the meantime (which shouldn't happen if everything is properly configured). >Bind badly needs to be taken away and quietly buried somewhere it >won't be accidently discovered for a very long time - say in the >middle of a nuclear waste dump... Yep. >Back to the initial issue - I must say I'm a fan of adding as many glue >records as possible, it does mean more update work, but it also means >that we can always supply an A along with the NS, saving the requesting >site from having to go and (possibly) make several queries, even in >those cases where this will work. No, no, no! How many zones is a host like uunet.uu.net a secondary server for? If uunet.uu.net changed its address, the primary zone files for all of these zones would have to be updated. How long would that take, considering the diligence of many of the people in change of maintaining these files (how many name servers still believe that NIC.DDN.MIL is still a root server and still lives at 10.0.0.51?). If you are concerned about efficiency, just have BIND go ask for the addresses of these servers and cache the answers. Personally, I don't think this is that much of a win. BTW, BIND has a bug that causes it to insert the A records for the name servers of subzones into the zone transfer data if these A records are cached, even if these A records do not belong in a subzone. This information will not time out on the secondary server until the zone file on the primary is updated. > >Because of this, I think its a very good idea (you might even say >essential) to notify all your secondary servers, your parent servers, >all servers for which you are the secondary, and the servers for the >parent domains of those domains, whenever you change the IP address >of a server. Yes, it is very important that the glue records in any parent zones be correct. If not, then a host requesting the address of the server will get the *incorrect* address information from the parent and take it at face value. The secondary servers need the correct IP address in order to do zone transfers from the primary. Care must also be taken in order to avoid looping the old data between servers as illustrated above. >Or better yet - avoid changing the addresses of servers... If this were only possible. >ps: it would be real nice if BIND could go and discover the A records >for all NS's it delegates dynamically after it is started (and then >again whenever they time out) - that way the only glue records that >will be useful are for those where you are delegating down, and even >there, BIND should go verify those with the servers concerned, using >the glue records just as hints, as it does with the list of root servers >in root.cache - never returning them in an answer until after verified >with their owner. Yes. It could also return them in an answer before they were verified, but with a TTL of 0. BIND should also whine to the administrator if it finds that the glue information is different than the authoritative information. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901