Home / server / Questions / 963036
Accepted
Tedwin
Asked: 2019-04-15 14:49:25 +0800 CST

How to transfer DNS records to new DNS provider with very little or no downtime in resolution

  • 772

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?

domain-name-system

1 Answers

  1. Best Answer

    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.

    • 2