[dns-operations] caches only resetting TTL? was Re: Where to find "DNS resolution path corruption"?

[Mark Andrews]

	This is just the result basic DNS management practices not being
	followed.

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

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

	In all cases old servers should be deconfigured.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org