TLD nameservers that also cache?

Robert Elz kre at munnari.OZ.AU
Fri Jul 7 16:40:08 UTC 2000


    Date:        Thu, 6 Jul 2000 16:57:27 +0200
    From:        Brad Knowles <blk at skynet.be>
    Message-ID:  <v0422080bb58a3d171a0d@[195.238.1.121]>

While there can be problems with upper level nameservers also
running caches (or running secondaries for sub-domains for that
matter, when they're not all under the same admin control), the
particular "problem" you're referring to isn't one of them.

  | 	Of course, when we make changes on our own local network (e.g., 
  | to move www.skynet.be to a different IP address), we restart our own 
  | caching nameservers, so that our customers can see these changes as 
  | quickly as possible.

The DNS was intentionally designed with the intent of changes taking
time to propogate.  The problem you are experiencing is from failing
to account for that when you make other changes that require DNS updates.

ie: the right way to change the address of something important is to
keep both the old and new addresses running for the period until the
old ones have expired from the caches.

That can be done via alias addresses, routing tricks, ...

And you can (or should be able to) change the TTLs on the zone to
make this period be less than the TTL you might normally set.
I don't understand your comment about having to change thousands
of zones TTLs?  The nameserver addresses (A records) will exist only
in your zone, regardless of how many other zones also use the same
NS records.  So you change the TTL in your zone, and the lower TTL
will just be automaticlly found when the A records are used as additional
info when doing a NS lookup in one of the other zones.

On the other hand, if you're naming the nameservers by thousands of
different names (ns.domain-name for ever domain-name that is served)
then you have real problems changing the addresses - every zone needs
to be edited to update the A records that apepar in it, and every domain
needs its delegation updated to get the glue records in the parent
updated - compared with all fo that, changing the TTLs as well would be
just a small extra burden (in this enviromnemt you're unlikely to be
changing those addresses very often).

There's nothing intrinsically wrong with having your resolvers chase
the chain down from the root, (lookup BE at . lookup xxx.be at be ...)
You perhaps generate some extra queries (. might have info about xxx.be
even if it isn't caching - there might be configured glue), but on
the other handm your local cache will build up more info which can be
used to avoid queries later.   But I wouldn't be doing this just to
avoid the problem you described - I'd just be doing the renumbering
properly in the first place, and the "problem" just vanishes.

kre



More information about the bind-workers mailing list