dns authority changes and lame servers

Mark Andrews Mark_Andrews at isc.org
Fri Oct 19 00:01:08 UTC 2007



	The correct way to change a delegation is to:

	* add the new servers as stealth servers for the
	  current zone.
	* if the old master is to be removed, make it a slave
	  of the new master.
	* add the new NS records to the zone.
	* wait for all the slaves to have the new zone.
	* inform the parent zone of the new NS records.
	* wait until all the old NS RRsets have expired from
	  caches (implies waiting for the parent's changes to propagate).
	* remove the old NS records from the zone.
	* wait for all the slaves to update.
	* inform the parent zone of the new NS records.
	* wait until all the intermediate NS RRsets have expired from
	  caches (implies waiting for the parent's changes to propagate).
	* any slaves that are not being remove and that are still
	  using the old master (or slave that is going away) need
	  to be configured to use the new master by this point.
	* stop serving the zone on the old servers.

	Note: all through this process the namesevers listed in the
	NS records are answering for the zone in a consistant manner.

	Note: even if the parents informed you that the delegation
	was removed you still have to wait for the records to expire
	from caches *before* you can stop serving the zone.

	One can collapse the above slightly by informing the parent
	of the final NS RRset, rather than the intermediate NS
	RRset, but that won't work with registrars that check the
	childs NS RRset.

	One way to get around this would be to charge a cleanup fee
	that only gets charged when the client fails to notify you
	in advance that they are going change delegations.

	Mark



More information about the NANOG mailing list