I'd like to transfer DNS records from Network Solutions to DNS Made Easy, mainly to take advantage of "DNS Failover" provided by DNS Made Easy to automatically fail a couple of key A records over to new IPs in my data center where I replicate servers to for DR if DNS Made Easy senses that the primary IP on prem is unavailable.

This guide is helpful, but I don't understand the first step regarding TTLs. My understanding of TTLs has always been that hosts cache records for an amount of time as told by the TTL when querying records. If that understanding is correct, how can I have any control over expiration?

My plan is to:

  1. Create new zone files on new DNS provider at my leisure
  2. Change existing nameservers at the registrar to the new DNS Made Easy nameservers at night, cross my fingers and wait for morning

What can I do in relation to the TTLs to improve my chances of making this seamless?

  • 2
    Put the same records in place on the new provider, then cut over. The TTLs on the old provider will determine how quickly you can get rid of them. If your TTL is one hour, you can (relatively) safely remove the old provider after an hour. If it's a day, a day. – ceejayoz Apr 14 at 22:51
  • Are we talking about TTLs on actual records; A, CNAME, MX, TXT? The article I linked to discussed actual NS records, whose TTLs I don't appear to have any control over in Network Solutions. – Tedwin Apr 14 at 22:56
  • 2
    That's not all that relevant; your change of nameservers at the registrar will generally have nearly immediate effect (if the registrar is working properly). – Michael Hampton Apr 14 at 23:44
  • @MichaelHampton No it depends on the TTL of NS records at the parent (registry). For .COM it is 2 days. If both old and new nameservers have same content, then the change may take time but will be invisible (because same content). If both do not have same content, for at least 2 days some people will get some results, others will get other results. – Patrick Mevzek Apr 16 at 16:46

My understanding of TTLs has always been that hosts cache records for an amount of time as told by the TTL

This is right. TTLs were defined like this, from the venerable RFC1034:

TTL which is the time to live of the RR. This field is a 32 bit integer in units of seconds, an is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded.

Note in passing:

  • it is a maximum value, resolvers are free to empty their cache before reaching the TTL value (for policy reasons or to make space in the cache)
  • some resolvers will clamp TTL values to a minimum if the value in the wild is deemed too low; typically below 5 minutes you risk to have some resolvers not honoring it

Normally a change for any record is recommended to be that way:

  1. You lower the TTL of the current record, to something like 5 minutes
  2. You wait at least the value of the previous TTL, before going to next step
  3. You change the record, keeping the small value
  4. You test everything is right
  5. You then can put back an higher TTL value

To be complete, depending on your NS infrastructure you might also need:

  • to lower the SOA MINIMUM value, which is in fact the "negative TTL": this is only relevant if you add a record that was not there previously
  • to lower the SOA REFRESH value, if you do not control the secondary nameservers, so that they will get the new value faster (or send them NOTIFY messages and make sure it triggers AXFR/IXFR queries from them shortly after).

Your case is slightly different:

  • if you change the set of nameservers
  • and if the new nameservers are configured with exactly the same zone content as the previous ones
  • then it means that contacting the old nameservers or the new ones will have the exact same effect
  • hence you can change them without changing any TTLs.
  • but you need to wait at least the TTL of the NS records in the parent zone, after the change, to consider that all resolvers will have received the new set of nameservers. This is only after this delay that you can start to make changes in the content of the zone.

Some examples:

$ for tld in com biz info org guru fr de ; do echo -n $tld ' '; dig @`dig $tld. NS +short|head -1` nic.$tld NS +noall +auth | grep "IN NS" | head -1 | awk '{ print $2}' ; done
com  2d
biz  2h
info  1d
org  1d
guru  1d
fr  2d
de  1d

PS: in case of a signed domain name (DNSSEC) things are a tad more complicated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.