How do I switch my domain from being delegated to and served up by one set of content DNS servers to being delegated to and served up by another set?
This is the Frequently Given Answer to such questions.
Three sets of content DNS servers are involved in this:
This procedure assumes that the intermediate names of the old and the new content DNS servers for your domain are different from one another. Changing the intermediate names when changing content DNS servers, when not done properly, can trigger a bug in BIND that can cause people in the rest of Internet who are using BIND for their proxy DNS service to be unable to resolve queries for names in your domain for a period.
If you have followed best practice, the intermediate names of your content DNS server are within your domain itself and you can follow a special-case procedure that doesn't involve changing the intermediate names at all. This simplification is the primary reason why having intermediate names merely within the bailiwick of your superdomain's content DNS servers, and not within your own domain itself, is merely good practice.
The general-purpose procedure is as follows:
Copy the data for your domain from the database(s) of the old content DNS servers for your domain to the database(s) of the new content DNS servers for your domain. Any changes to any of your domain data (apart from the delegation data) must be made identically on both the old and the new content DNS servers from this point until you reach the final step.
Make a note of the time-to-live of the delegation that is currently being published by the superdomain content DNS servers.
Change the delegation data in the database(s) of the new content DNS servers in your domain to list only those new servers. Have the new content DNS servers for your domain start publishing the new data.
Change the delegation data in the database(s) of the superdomain content DNS servers to list both the old and the new content DNS servers for your domain. Have the superdomain content DNS servers start publishing the revised data.
Change the delegation data of your domain in the database(s) of the old content DNS servers to list only the new servers for your domain. Have the old content DNS servers for your domain start publishing the revised data. It is important not to omit this step.
Wait for the length of time that you noted previously, so that you can be sure that no caching resolving proxy DNS server has the old delegation information that listed the old content DNS servers.
Make another note of the time-to-live of the delegation that is currently being published by the superdomain content DNS servers.
Change the delegation data in the database(s) of the superdomain content DNS servers to list only the new content DNS servers for your domain. Have the superdomain content DNS servers start publishing the revised data.
Again, wait for the second length of time that you noted, so that you can be sure that no caching resolving proxy DNS server has the intermediate stage delegation information (published by your superdomain's content DNS servers) that listed both sets of content DNS servers.
Remove the data for your domain from the database(s) of the old content DNS servers for your domain.
This procedure assumes that the intermediate names of the old and the new content DNS servers are to be the same as one another. This will be the case if you have followed best practice such that those intermediate names are within your domain itself. You can leave the intermediate names unchanged and simply alter the IP addresses that they map to so that they are those of the new content DNS servers. Because the intermediate names do not change, you don't run the risk of triggering a bug in BIND and the procedure is shorter, since it doesn't involve waiting twice and doesn't involve editing any of the databases twice.
(You can find this same procedure, expressed in terms of djbdns specifically, on Dan Bernstein's tinydns FAQ page.)
The special case procedure is as follows:
Copy the data for your domain from the database(s) of the old content DNS servers for your domain to the database(s) of the new content DNS servers for your domain. Any changes to any of your domain data (apart from the delegation data) must be made identically on both the old and the new content DNS servers from this point until you reach the final step.
Make a note of the time-to-live of the ("glue" resource records in the) delegation that is currently being published by the superdomain content DNS servers.
Change the delegation data in the database(s) of the new content DNS servers in your domain to map the intermediate names to the IP addresses of those new servers. Have the new content DNS servers for your domain start publishing the new data.
Change the delegation data in the database(s) of the superdomain content DNS servers to map the intermediate names to the IP addresses of the new content DNS servers for your domain. Have the superdomain content DNS servers start publishing the revised data.
Change the delegation data of your domain in the database(s) of the old content DNS servers to map the intermediate names to the IP addresses of the new content DNS servers for your domain. Have the old content DNS servers for your domain start publishing the revised data. It is important not to omit this step.
To ensure that all caching resolving proxy DNS servers will have expired the old delegation information and switched to querying the new content DNS servers, wait for the length of time that you noted previously.
Remove the data for your domain from the database(s) of the old content DNS servers for your domain.
You will, most probably, not have the right to edit the database of the superdomain content DNS servers directly. Most commonly, your domain will be a second-level domain, that database will be derived from a top-level domain's registry, and you will edit it indirectly by submitting requests to a registrar, which will pass along those requests to the registry on your behalf.
The procedure for communicating such changes to the registry via a registrar varies from registrar to registrar, and does so too widely to be discussed in detail here. In general, the general-purpose procedure will involve changing both "DOMAIN" and "HOST" information, whereas the special-case procedure will only involve changing "HOST" information.
There is a bug in BIND that is described in this BugTraq article. (Despite the fact that the article mentions version 8.2.2 of BIND specifically, it is in fact present in all versions that apply the "credibility" rules, including version 9.) Triggering it will cause BIND proxy DNS servers to be unable to resolve queries for names in your domain for a period of time of any length up to and including the time-to-live of the "NS" resource record set for your domain, which may be several days.
The special-case procedure avoids triggering it because the intermediate names of the content DNS servers do not change. Therefore the "A" resource record "glue" published by the superdomain's content DNS servers will match the cached "NS" resource records, the IP addresses of the new content DNS servers will thus be obtainable, and query resolution will thus be able to proceed.
The general-purpose procedure avoids triggering it by ensuring that, at all times, the set of content DNS servers published by the superdomain's content DNS servers is always the same as, or a superset of, the set of content DNS servers published by both the old and the new content DNS servers. This is why the procedure involves changing the delegation published by the superdomain's content DNS servers twice; and why one has to wait for the time-to-live interval until the old delegation information has expired from the caches of all caching resolving proxy DNS servers before making the second change.
If you happen to be using the "zone transfer" mechanism for replicating your database amongst your old content DNS servers, an easy way to copy the data to the new content DNS servers is to temporarily make the latter "slaves" of the former just long enough for the database to be copied by the replication mechanism, and then to turn that replication off.
If you are using djbdns and are replicating the database amongst your old servers by simply copying the database file (in whatever way), an easy way to copy the data to the new servers is to use grep or awk on the "data" file of the old servers to pick out the database records for your domain, and add those records to the "data" file of the new servers.
It is important that the delegation information published by the old content DNS servers for your domain be updated. If this is not done, caching resolving proxy DNS servers may well continue to query the old servers indefinitely.
This is because many content DNS server softwares helpfully include, in responses that they send, the delegation information for domains along with the actual answers to what they were asked. (BIND does this. tinydns does this.)
The purpose of their doing this is to reduce the query load on the superdomain's content DNS servers and to reduce DNS traffic. Sending the delegation information along with answers keeps the delegation information current in the caches of any caching resolving proxy DNS servers that happen to query names in the domain often enough, because with each answer received the delegation information held in the cache is updated. The delegation information does not have the opportunity to expire, because it is continually updated. Because it does not expire, those resolving proxy DNS servers do not have to resort to querying the superdomain's content DNS servers in order to retrieve the delegation information afresh.
Since the superdomain's content DNS servers are never queried afresh for the delegation information (and since the new content DNS servers, obviously, are not queried for it either), resolving proxy DNS servers will never see the updated delegation information if it is only published by the superdomain's content DNS servers and by the new content DNS servers. The old content DNS servers will, in effect, "capture" any resolving proxy DNS servers that happen to query them regularly enough. Therefore, it is important to change the delegation information that the old content DNS servers publish as well, so that all caching resolving proxy DNS servers eventually switch to using the new delegation information and thus the new content DNS servers.
Both procedures involving waiting for a multiple of the time-to-live value of your domain's delegation information. This has two ramifications:
You must plan ahead. Your old content DNS servers will need to still be running for quite some time after you commence the procedure.
For example: If you are following the general-purpose procedure and your delegation information has a time-to-live value of 7 days, your old content DNS servers will need to continue running for a whole fortnight.
For example: If you are using someone else's content DNS servers to publish the DNS data for your domain, your hosting agreement runs out in 2 days whereupon those servers will cease publishing your data, and your delegation's time-to-live value is 3 days, then you've left things too late.
Don't use long time-to-live values for your delegation information if you intend to change content DNS servers often. (It is unusual to want to do so, of course.)
For example: If you want to change your content DNS servers every week, using the general-purpose procedure, don't give your delegation information a time-to-live value greater than 3.5 days.
It is possible (but bad practice) to combine your content and proxy DNS services with ISC's BIND and Microsoft's DNS server. It isn't strictly necessary to remove the data from the old content DNS servers if you have followed best practice and not done this.
However, if you have followed bad practice it is necessary. With ISC's BIND and Microsoft's DNS server, where a server vainly attempts to wear all of the hats at once content DNS service is always used in preference to proxy DNS service. Your servers will continue to return the old and no longer current information about your domain from their own databases, rather than querying the new content DNS servers as is intended.
Of course, if you are following bad practice, you should reorganize your DNS services so that you are not.