I am in the process of migrating a web server which has a few thousand small sites, and does its own DNS. Each site has a hostname in the form of "customer.ourcompany.com" and some also have "www.customersdomainname.com".
When we do the migration, the IP is going to change, so we need to update all DNS entries for all domains. Because this machine is also the authority for ourcompany.com, the IP for ns1.ourcompany.com must also be changed.
This is the problem. For all of the client domains, we need to make sure that any glue records will contain the correct IP.
Are glue records always used by registrars, even if they are not technically needed for a domain? We migrated another webserver once, and I needed to log in to the registrar's site (GoDaddy) and update EVERY namerserver entry by simply swapping ns1 for ns2 and vice-versa. This forced GoDaddy to lookup the new IPs for nameservers, and store them as glue records. I am afraid of having to do this again, but with 2000 domains, not all at the same registrar.
Thoughts?
I think you might be a bit confused by the definition of glue records. As a very brief summary of the process: When you register a domain (example.com) with a domain registrar you need to provide hostnames for the nameservers which will be authoritative for that domain.
If the nameservers exist on the same domain as that which you are registering (ns0.example.com) then you will also need to provide IP addresses for them. These will form your glue records. Without these glue records, DNS lookups will become stuck in a catch-22 situation whereby they don't know how to resolve a domain's address because they can't first resolve the nameservers.
However if the nameservers exist on a different domain then no glue records are required. You simply provide hostnames (no IP addresses) for the nameservers and DNS lookups will resolve these first before then resolving the requested domain.
With this in mind there are two possible scenarios for what you are trying to do. From what you have described I suspect that the first one applies to you:
If all of the client domains have a nameserver of
ns1.ourcompany.comin the zonefile and WHOIS records then you will only need to change the IP address stored in zonefile and glue records for the domainourcompany.com. Because this is the only self-referential hostname that needs bootstrapping during the lookup process.If each client domain uses
ns1.customersdomainname.comand has a glue record pointing at your IP address then you have a bit more work to do. You will need to update each and every one of the domains. Some registrars provide APIs which you can use to automate the changes. While you are at it though, I'd advise consolidating to the setup that I described above, to prevent a repeat of such work in the future.I don't think there is going to be an easy way to do this in one step if you do not manage your own DNS (or have it managed for you by a DNS management company rather than registrars that do offer specialist extras in the DNS management options), unfortunately.
You might be able to speed things up if interfaces of the registrars in question have a "bulk change" option (some do, some doing) and that option covers updating nameserver glue records.
If you must change your public facing DNS's IP address, then I strongly suggest that you overlap the two setups so that they are both active at the same time. This will allow you to continue to serve from the old address while the rest of the internet is updating to the new one. Eventually, once requests to the old address peter out, you can bring it offline. Modifying TTLs can help speed up this process.
If this is a Bind server, scripting the changes to the zone files isn't all that difficult, especially if your using a fairly small number of IP addresses. Usually, I'll copy the entire directory off to a temp location and run them thru sed. This gives you the chance to verify all the changes before dropping them back into place.