0

I'm about to transfer a domain from one registrar and DNS provider to another, and I want to test the new DNS host before starting the transfer. The new host provides plain DNS service beforehand, so the domain can be set up there with all records in place; this can then be tested by looking up every entry in it using dig @newserver hostname etc. However, this doesn't allow testing of the name server settings. My thinking was that I could create hosts file entries for the NS records, and thus have it look up entries on the new name server, but that didn't work. Next up I tried running a local dnsmasq server serving up static locally-defined records for the NS entries pointing the old provider's DNS server names to the new provider's IPs, and while manual dig queries result in the expected IPs, running in a browser does not (even if I clear local caches).

How can I achieve this?

Synchro
  • 2,983
  • 5
  • 25
  • 35

2 Answers2

0

First, good thinking to test before the transition. You'd be surprised at how many sysadmins don't test.

Using @newserver ignores the NS records and sends the request directly to newserver. You can test that it serves the right NS records by specifying "NS" on the command line:

dig @newserver mydomain.com ns

That verifies that you have the right NS records in the new zone files.

This assumes the new registrar will set up a DNS server with your zone before the transfer.

When external people do DNS lookups they ignore the NS records in your zone. They only query the NS records that are in the parent zone. For example, if this is a .com domain, there is a (huge) zonefile for all of .com which includes NS records for mydomain.com. When you transfer the domain, those records will change. There is no way to test the new NS records there without making the change.

Again, assuming the new registrar will set up your DNS zone before the transfer: You could tell the old registrar to add the new NS records (add them, don't remove the old NS records). At that point about half your DNS queries will go to the old DNS servers and half will go to the new DNS servers. You can verify things work correctly that way. (even better: add one NS record at a time). You can remove the old NS records one at a time and do even more testing.

If the new registrar will not set up your DNS zone before the transfer, create a new domain with the same zonefile. You'll have to create a zonefile that works for both zones; easy if you use relative names instead of FQDNs. (Tip: use "@" any time you want to specify the domain name itself). Test the records there. Re-use the exact zonefile on the new domain... this way you'll know the zonefile worked.

TomOnTime
  • 7,567
  • 6
  • 28
  • 51
  • I know I can look up NS entries individually, but what I want is to spoof the whole machine to look at the new DNS, as if I could provide the `@newserver` option to browsers, email clients etc. What I was trying to do is make a local DNS server override the IPs for the old host's name servers to point at the new one, so a lookup for ns1.oldhost resolves to ns1.newhost's IP, thus fooling the whole system to get its names from there, and thus making everything act as it will after the real DNS switch. – Synchro Nov 25 '13 at 14:53
  • Ah, my apologies. That wasn't clear to me from the original question. – TomOnTime Nov 25 '13 at 15:51
0

You could set up a DNS server set up in a configuration called "split DNS". Some domains would have their lookups directed at the new server and all others would follow the regular path. http://en.wikipedia.org/wiki/Split-horizon_DNS

If you are using BIND, this might help: http://www.cyberciti.biz/faq/linux-unix-bind9-named-configure-views/

TomOnTime
  • 7,567
  • 6
  • 28
  • 51
  • I'm already placing a local DNS in front of the normal one and having it return static records instead of looking them up (which is a very limited kind of split DNS I guess). As far as I can see, this works (in that when I do a manual NS lookup on the domain (which involves querying the old DNS host), my local DNS is returning the spoofed IP), but for some reason that's not enough to make it get everything else from there.I have a suspicion that this is more about how the OS does lookups in general than the workings of DNS. – Synchro Nov 26 '13 at 17:06