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