Cloud admin on 07 Aug 2012 05:50 am
We recently had a customer that was migrating from one DNS provider to another due to large outages from their existing supplier ie. a failure to keep their DNS services working correctly. They went ahead and migrated by changing their A Record and MX records for their domain/ sub-domains and only contacted us when they started getting outages during propagation as they suspected they must have done something wrong and they were not sure of how to check.
The best way to check this out is to use the DIG command. DIG is an acronym for Domain Information Groper. Passing a domain name to the DIG command by default displays the A record of the queried sit (the IP address).
We can use Dig to check the new nameserver are correctly returning the A record and MX records. To do this:
Dig@<nameserver URL or IP> <DomainName to check>
If this is correct then it means that the name servers have the correct records which means when they are changed at the registrar we can assume they will be correct.
In the case of the company in question the DNS was correctly returning the new NameServer and MX records for the Domain but their local recursor was still returning the old NameServer records as propagation had not taken place.
Other recursors can be checked to identify whether propogation has taken place there i.e.:
dig @18.104.22.168 ns <domain> would check the Verizon recursor
Others of note are:
22.214.171.124, 126.96.36.199 – OpenDNS
188.8.131.52, 184.108.40.206 – Google
Others can be found on the OpenNic Wiki
So in the companies case caching of the prior NameServers and the TTL (time to live) was causing the problem as the new NameServers were not completed propagating. Essentially there were two different “nameservers”, each returning different values, and, being selected randomly (due to cached ns records).
One of the things we were able to do help smooth the transition was to ensure each NameServer returned identical values by making both zones were 100% identical ie. on the original service we changed the NameServer NS records to match the new NameServer NS records. Ideally this would have been done as soon as migration occurred.