1

I'm planning on switching from one registrar to another. Fortunately I've been able to pre-enter the zone information so that when the transfer takes place, everything should behave the same.

However, having been burned in the past I'm a bit paranoid and want to be able to set up monitoring systems ahead of time to make sure that the domains keep pointing to the same locations.

My concern is, how do I set something like that without running into the issue of cached DNS lookups? I really want each lookup to be new so that there are no problems.

So I guess I'm looking for two things:

  1. a reliable tool for testing DNS lookups (one that for obvious reasons is not hosted on any of my servers, since there is a danger they won't be able to send me an email when something goes wrong) and
  2. a test that doesn't pull up a cached record and keeps the DNS information fresh and up-to-date

Also, I'm assuming that everything will go okay for cached servers, since the new records match the old ones. But is there anything dangerous in this assumption? Is there any reason to think the change of registrars and nameservers at the same time might have side effects I'm not aware of?

How it went, in case anyone's interested

Apparently during the transfer the old nameservers were kept, so for a while none of the domains pointed to an IP at all (I guess as soon as the transfer takes place, the old registrar wipes its records). I had to update those records to point to the new nameservers and re-import all the zone records (fortunately the new registrar's system has a nice import tool for zone files, very helpful!). For some strange reason, the local name server of the web hosting service took much longer than other DNS servers to update its records, so the server itself was confused about which records it could serve. If anyone else is going through the same process, here are some things you should do to avoid what I went through:

  1. Make sure that the zone records are functionally identical across registrars. [But see below]. Unfortunately one record that was supposed to be an A record got stored as a CNAME record with bad results. This is easy for registrars that will let you export your records as a zone file, difficult for ones that just have a web page you need to cut and paste.
  2. Make sure that the new registrar is definitely set up to be the new DNS host For some reason, during the transfer process I did not correctly set up the domain to be DNS hosted by the new registrar. This was during the shopping cart process, not a configuration step after purchase. Apparently what I needed to have done at that point is cancel the transfer request and start over, because there was no way for me to change it so that it would switch on activation.
  3. Make sure that when the domain transfer goes through, you are set to get an alert. I didn't find out the transfer took place until one of the domains stopped working because I wasn't set up as the authorized contact for the domain.
  4. Above all, try not to be halfway through an eight hour car trip with your family when the transfer finally goes through. Thank goodness Dunkin Donuts has free WiFi -- who knew? (Oh, and this really complicated testing DNS at the time, since I couldn't use any proxy web servers to test DNS queries from multiple locations since web proxies are blocked by the software used by Dunkin Donuts to provide WiFi access).

A couple of things I did get right after all:

  1. Replacing loads of A records with CNAME records. This probably would have been a lot harder to manage if I'd had to keep track of dozens of identical A records. Furthermore, I only had to worry about a couple of domains propagating correctly since the rest of them all pointed back to other domains.
  2. Saving a backup of the zone file. When the records were lost during the transfer, it was very useful to have a zone file already ready with the records that I needed. The only change I might have made was doing a final scan of the zone file and comparing it with the old configuration pre-transfer, as unfortunately the zone file was missing a couple of subdomains.
  3. Using a fairly low TTL. Unfortunately, most registrars don't let you have a TTL shorter than 1/2 hour, but I don't understand people who opt to set the TTL to something like a week. I'd much rather have the infrastructure take a bunch of extra query hits than have some computer somewhere still pointing to the wrong place after five days.
Improve this question

2 Answers 2

Reset to default
1

Double check your current DNS and your future DNS, just to be sure...I have done what you are going to do and know exactly what you are going through! If you were switching IP addresses, I would recommend that you lower the TTL on the existing records, but in this situation with the names and IP's staying the same, your only exposure is going to be if you didn't set up the new records correctly...Being able to pre-stage them is a great thing...I think you will not have an issue.

Improve this answer
2

You could use host/dig/nslookup command line utilities and google dns (8.8.8.8/8.8.4.4) as independent name server. And of course you must use authoritative dns servers of you domain.

# host -t ns example.net 8.8.8.8
# host -t mx example.net 8.8.4.4
# host -t txt example.net ns1.example.net

There would be cache anyway, due to TTL of your zone.

Improve this answer
2
  • As far as I understand it, Google does cache. So my concern is that Google has all the right info because they've cached it, and then another name server comes along and has the wrong info. :(
    – Jordan Reiter
    Jul 25, 2013 at 16:45
  • Actually most of NS servers will cache the results according to TTL of queried zones
    – ALex_hha
    Jul 25, 2013 at 16:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .