Every DNS answer carries a TTL (time to live) that tells resolvers how long they may cache it. When you move a website or mail service, the TTL decides how long some visitors keep reaching the old server. Planned well, a DNS cut-over finishes within minutes; planned badly, it drags on for a day or more.
This guide covers the mechanics from the DNS standards and a practical timeline you can follow with dig.
What TTL actually controls
RFC 1035 defines the TTL as the time interval, in seconds, that a record may be cached before the source should be consulted again; a TTL of zero means the answer should be used only for the current transaction. Recursive resolvers (your ISP's, your company's, public ones) count it down from the moment they fetch the record. Until it reaches zero they answer from cache, whatever you have changed on your DNS host.
Two consequences follow:
- A TTL change is itself cached. If a record has a TTL of 86400 (one day) and you lower it to 300, resolvers that fetched it an hour ago keep the old copy, with the old one-day TTL, for up to 23 more hours. Lowering the TTL only helps once the old TTL has run out.
- Changing the TTL and the value at the same time gains nothing. The new short TTL only applies to resolvers that fetch the new record.
Negative answers are cached too
When a name or record type does not exist, the answer (NXDOMAIN or an empty answer) is also cached. RFC 2308 says the TTL for that negative answer is the smaller of the SOA record's MINIMUM field and the SOA record's own TTL. The same RFC deprecates the old use of MINIMUM as a zone-wide minimum and suggests that resolvers cap negative caching, noting that one to three hours works well and values over a day have been problematic.
In practice: if you test new.example.com before creating it, resolvers may remember that it does not exist for as long as your SOA allows. Create records first, test second.
See the TTLs you are publishing
Query one of your authoritative nameservers directly so no cache is involved:
dig @ns1.your-dns-host.example www.example.com A +norecurse +noall +answer
dig @ns1.your-dns-host.example example.com MX +norecurse +noall +answer
dig example.com SOA +shortThe second column of each answer line is the TTL. The SOA output lists, in order, the primary nameserver, the administrator mailbox, the serial, refresh, retry, expire and minimum values; the last one feeds negative caching as described above.
Through a recursive resolver the TTL you see is the time remaining in that resolver's cache, so it counts down between queries:
dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answerA migration timeline
Assume the records you will change have a TTL of 3600 seconds (one hour). Scale the waiting times to your real TTLs.
- At least one old TTL plus a margin before the change (here, the day before): lower the TTL of every record you will change to 300 seconds. Typical candidates are A and AAAA records for the site, any CNAMEs, and for a mail move the MX, SPF TXT and autodiscover records. Do not change any values yet.
- Verify on each authoritative nameserver that the new TTL is published, then wait out the old TTL so that every resolver's cached copy has expired.
- Make the change (new IP address, new MX host). Resolvers will pick it up within about five minutes.
- Keep the old server running. Some clients and resolvers may still reach it for a while, and RFC 8767 allows resolvers to keep serving expired (stale) data if they cannot reach your nameservers, suggesting a cap of seven days. For a website, serve the same content or a redirect; for mail, keep the old server accepting and forwarding messages.
- Raise the TTL again once everything is stable, for example back to 3600. Permanently tiny TTLs make every visitor depend more on your DNS host being reachable and increase query load, with little benefit outside change windows.
What a low TTL cannot speed up
- Nameserver changes at the registrar. The NS records and any DS (DNSSEC) record for your domain live in the parent zone, run by the registry, with TTLs you do not control. Your own zone's NS TTL does not shorten that. Keep the old DNS host serving the same zone until the new delegation is visible everywhere.
- Caches outside DNS. Applications that hold long-lived connections or keep their own copy of an address may not look up the name again until they restart. Keeping the old server answering covers these cases too.
Pitfalls
- Lowering the TTL an hour before the change on a record that had a one-day TTL.
- Forgetting related records:
wwwversus the bare domain, AAAA records still pointing at the old IPv6 address, or the MX and SPF records in a mail move. - Testing a hostname before it exists and caching the negative answer.
- Shutting down the old server or old DNS host the moment the record changes.
- Leaving TTLs at 60 or 300 seconds for good after the migration.
What you should do
- Check current TTLs on your authoritative nameservers before planning a change.
- Lower the TTL of the records you will change at least one old TTL (plus margin) in advance, and verify it.
- Create new records before testing them, and know your SOA negative-caching value.
- Change the values, confirm with
digagainst your nameservers and a couple of public resolvers, and keep the old server running. - Restore normal TTLs once the move is complete.
Comments
0 total · 0 threads