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
