Skip to content

Getting started

TTL and why DNS changes lag

Learn how DNS TTL sets the cache clock and why record changes can lag after you edit them.

Updated Aug 29, 20263 min read14 reads
TTL and why DNS changes lag
How DNS TTL controls how long old answers stick around

DNS TTL is the time limit you put on a record so resolvers may cache it. When you change an A record, the internet does not update all at once. Recursive resolvers keep the old answer until that cached copy is older than the TTL they last saw. Some ISPs hold on even longer. The lag you feel is a cache clock, not random propagation weather.

Authoritative TTL versus remaining TTL

Authoritative TTL is the value you set on the record in your zone. Public resolvers show remaining TTL, which is how much of that permission is left on their copy. NS records also carry their own TTL at the TLD level. People often lower the A TTL and forget the NS set may still be forty-eight hours. Nameserver changes therefore move more slowly than simple A changes, which is why you usually move files and point the A record first.

A practical schedule works like this. About a day before the cutover, set the record TTL to three hundred seconds. Wait out the previous TTL so caches can refresh. Then change the record and check it from more than one resolver. The next day, raise the TTL again to a normal value. Leaving a one-second TTL forever does not help much, and it makes every small resolver blip look like an outage.

bash
dig example.com A +ttlunits @1.1.1.1
dig example.com A +ttlunits @ns1.logicweb.com

The first command asks a public recursive resolver. The second asks the authoritative nameserver. If ns1.logicweb.com already shows the new address and 1.1.1.1 still shows the old one with hours remaining, you simply wait. If the two disagree on the address itself and remaining TTL is not the issue, you may have edited the wrong zone. Do not toggle nameservers to try to flush the world. You cannot flush an ISP cache. You can flush your own laptop. TTL is the contract everyone else is following.

Mail, maps, and what to send in a ticket

Mail adds greylisting on top of MX TTL, so keep both sides accepting mail during the overlap when you can. Global checker maps are a mosaic of many caches. They are useful, but they are not more useful than one authoritative dig plus one public dig. Paste both outputs in a support ticket. We can then see remaining TTL versus a wrong zone without guessing.

Once the cut is finished, put a sane TTL back on the record. Leaving three hundred seconds forever turns every brief blip into a worldwide scavenger hunt for the right answer.

Share

Send this article

Need someone else to do this? Send them the link — the commands are in the article.

Was this article helpful?

Be the first to rate this article.