Every DNS answer carries a TTL, the number of seconds a resolver may keep it. A resolver that fetched your A record a minute before you changed it goes on handing out the old address until that TTL runs out. With a TTL of 86400, that’s up to 24 hours of visitors arriving at the old server.
The fix is to make the TTL short before the move, so that the answers in caches at the moment of the change expire within minutes. The catch is that the short TTL only takes effect once the long one has run out.
The arithmetic
| Old TTL | Lower it to 300 at least | Old address served at most after the change |
|---|---|---|
| 86400 (24 hours) | 24 hours before the move | 300 seconds |
| 14400 (4 hours) | 4 hours before the move | 300 seconds |
| 3600 (1 hour) | 1 hour before the move | 300 seconds |
| 300 (5 minutes) | No change needed | 300 seconds |
A resolver that cached the record a minute before you lowered the TTL still holds the old TTL. Only when that has expired everywhere does every cache carry the short one. Add an hour of margin to the times in the middle column.
Plan the move
Read the current TTL at the source
Ask the authoritative server, not a resolver, whose value would already be counting down.
shell$ dig +short example.com NSns1.example.net.$ dig @ns1.example.net www.example.com A +norecurse +noall +answerwww.example.com. 86400 IN A 192.0.2.10
Lower it to 300, one old TTL ahead
Change the TTL of the records that will move, and nothing else yet. For 86400, do it at least 24 hours before the move. Check that the authoritative server has it:
shell$ dig @ns1.example.net www.example.com A +norecurse +noall +answerwww.example.com. 300 IN A 192.0.2.10
Wait out the old TTL
Once the old TTL has passed, public resolvers return 300 or less. Check two or three of them before you go on.
shell$ for r in 1.1.1.1 9.9.9.9 8.8.8.8; do dig @$r www.example.com A +noall +answer; doneChange the record
Point the A record at the new server, and the AAAA record too if there is one. A record left behind sends IPv6 visitors to the old machine, which is easy to miss when you test over IPv4.
Check the source, then the caches
shell$ dig @ns1.example.net www.example.com A +norecurse +short198.51.100.20$ for r in 1.1.1.1 9.9.9.9 8.8.8.8; do dig @$r www.example.com A +short; done
Within five minutes every resolver should return the new address.
Keep the old server running
Leave it up, serving the same content or forwarding to the new one, for at least the old TTL: 24 hours in this example. Some ISP resolvers keep answers longer than the TTL, and long-running clients, such as a JVM or a connection pool that doesn’t reconnect, keep the address they resolved. Watch the old server’s access log until requests stop.
Raise the TTL again
Once the new server has run for a day without problems, set the TTL back to 3600 or more. A short TTL sends more queries to the authoritative servers, and if those can’t be reached, the name fails once the caches run out after five minutes instead of after an hour.
Names that don’t exist yet
A resolver also caches the answer that a name doesn’t exist. If someone looked up shop.example.com before you created it, their resolver keeps answering NXDOMAIN for the negative TTL, which RFC 2308 sets as the lower of the SOA record’s own TTL and its last field.
$ dig +short example.com SOAns1.example.net. hostmaster.example.com. 2026102401 7200 3600 1209600 3600
The last number, 3600 here, is the minimum. Create a record before you announce it, or lower that value first if a new name has to work the moment you add it.
Changing name servers
Moving the zone to other name servers works differently. The NS records that send resolvers to you live in the parent zone, .com or .de, and their TTL is set by the registry. For .com it’s 172800, two days:
$ dig @a.gtld-servers.net example.com NS +norecurse# trimmed to the referral;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1;; AUTHORITY SECTION:example.com. 172800 IN NS ns1.example.net.example.com. 172800 IN NS ns2.example.net.
For another TLD, find its servers with dig +short de NS and ask one of them the same way. Then run the old and the new name servers with identical zones for at least that TTL after the registrar change, so it doesn’t matter which set a resolver reaches. dig +trace shows which set the parent hands out. The dig article explains its output.
Last checked on 24 October 2026 against Any authoritative DNS, RFC 1035 and RFC 2308 caching, and BIND 9.18 dig. If a step doesn’t match what you see, contact us with the command and what it printed.