[dns-operations] caches only resetting TTL? was Re: Where to find "DNS resolution path corruption"?
Mark_Andrews at isc.org
Tue Feb 26 21:58:06 UTC 2008
This is just the result basic DNS management practices not being
When you add a nameserver, you configure the server to serve
*the* (singular) zone. You add it to the NS RRset for the
zone. You add it to the delegating NS RRset.
When you remove a nameserver from a zone, you first remove
it from the NS RRset for the zone and the delegating NS
RRset. You then wait for the TTL's of both the parent and
child zones before deconfiguring the zone on the server.
This allows for server that have the old NS RRset cached
to get the new zone contents without having retry to one
of the new servers. This also allows for the complete NS
RRset to be changed without the zone going down for some
clients which would be what would happen if you immediately
deconfigured the old servers.
Note: nowhere in this is there two distinct sources of zone
data. There is only one zone and it is served by new and
Registrars and registries should play their part by ensuring
the current working servers for a zone have the new NS RRset
before it is installed in the parent zone. At the very
least they should warn the user that they are about to make
a management mistake and only let them proceed with a explict
In all cases old servers should be deconfigured.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the dns-operations