I am currently migrating a DNS zone from one DNS server provider to another. I am trying to estimate how long it will take for the change to propagate, and to understand what the delay might be if I chose to rollback mid-stream.
Previously, I thought I could do:
dig example.com ns
To see what the remaining TTL on the NS record was, but now I understand that this NS record is the NS record for subdomains in the zone, and not the NS record that emanates from the root servers, which is the one that ultimately determines to which name server the query will be sent.
I tested this by setting up a test record in the zone in each of the providers:
Provider1 test.example.com 10.0.0.1
Provider2 test.example.com 192.168.0.1
For both providers, the TTL on the NS records in 0, while the NS records at the TLD Registrar level point to the name servers of Provider1.
When I change the NS records in the zone at Provider1, I can see this reflected in NS queries almost immediately (using 'dig example.com ns').
However, when I send a query for an A record, ie
test.example.com
it always returns
10.0.0.1
regardless of what the NS records in the zone at Provider 1 are set to.
On this basis, I've concluded that the NS records within the zone file are irrelevant to the migration, and that only the name servers records at the TLD level are important.
However, I can't get a read on how long it is likely for a change there to propagate, either forward or back.
Is it possible to query what TTL are am working with for records emanating from the TLD root servers?
This is an incorrect hypothesis, but an easy mistake to make. You can read a little more on the subject of apex NS records here. The short version is that both matter, and the one being used will differ depending on whether a caching DNS server has previously queried your domain or has not.
Keep in mind that most recursive DNS servers enforce a minimum TTL, so any conclusions drawn from experiments with a TTL of zero are almost certainly inaccurate. The only case where this is not so is when you control the minimum TTL policy used by the server you're querying.
I'm going to focus on this topic since you have a few false starts in the rest of your question. First, it's important to remember that TTLs are cached on recursive DNS servers. Since everyone on the internet is using different recursive DNS servers, the only assumption you can make is that it will take up to n seconds, with n being the value of the TTLs.
This brings us to which TTLs are relevant here:
NSrecords expire, requests for individual records that are in cache will not automatically expire. Example: Iftest.example.com IN Aexpires ten minutes from now, butexample.com IN NSexpires five minutes from now,test.example.comwill remain in cache even after theNSrecords have changed. Any problems related to the value of this record on the new servers will not become evident until the record has expired and has been refreshed.NSglue records served by the TLD DNS servers. These are used by recursive servers that needed to obtain information about your domain when it is first requested. These TTLs influence how long it is before the DNS servers listed in your zone file are used for the next refresh. (refer to the Q&A I linked above for clarification on this)NSrecords listed at the top of your zone file. Once the glue record TTLs have expired, these TTLs might be used instead. Implementations vary on this detail. Since you are dealing with an entire internet's worth of different implementations, the only safe assumption is that some servers are using it.You can't assume that all of the cached
NSrecord TTLs on the internet are from one source or the other. This forces you to plan around the higher of the two unless you are truly not concerned with recursive DNS servers that you do not operate.Putting all of this together, we arrive at the following conclusions:
NSrecords in the glue, and theNSrecords in the zone.NSrecord change. Not only do you need all of the servers available for clients that haven't picked up the latest change, but any inconsistency in record data between the two can serve to make things even more confusing.You can do this easily with nslookup on Windows, I'm assuming you could do the same with dig. With nslookup you simply query one of the GTLD name servers for the name server records of your domain using debug to get a list of name servers for your domain with the TTL of those name server records.
The syntax for performing a similar query using
digis:It used to be you could query the SOA record for the domain to get the default TTL values:
But that's been deprecated in favor of the $TTL directive.
If you have particular records you're interested in, you could add the +ttlid flag to dig:
To get the exact TTL remaining:
(second field is TTL - in this case 604800)