Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!uunet!munnari.oz.au!cs.mu.oz.au!kre
From: kre@cs.mu.oz.au (Robert Elz)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: DNS glue records and BIND 4.8
Message-ID: <5652@munnari.oz.au>
Date: 29 Sep 90 17:41:15 GMT
References: <1918@ccadfa.adfa.oz.au> <1990Sep25.140536.16449@mp.cs.niu.edu> <106322@uunet.UU.NET>
Sender: news@cs.mu.oz.au
Lines: 74

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.

I had this problem with munnari.oz.au too, when 2 (of 4 previously)
addresses were removed (actually, moved to another host, which made
the problem worse).

> 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).

This is not really practical...

For munnari, I created a hacked version of named (introducing some bugs
along the way, so you really don't want it) which refuses to accept any
info that resides in any zone for which this named is the primary server.

That means that munnari will simply not believe anyone who claims to
tell it what its own address is (munnari.oz.au is the primary server
for the oz.au domain).   This then allows everyone else to selectively
purge their caches, update their backup files, etc, and theoretically
should eventually result in the old addresses dying out.

However, when I wanted to upgrade my named a while ago, I started the
new version, without my hack in it, and it took about 30 seconds for
the ancient old addresses (supposedly dead for months) to return to
munnari's cache.   Back to the hacked version...

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...

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.

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.

Or better yet - avoid changing the addresses of servers...

kre

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.