TTL, Propagation, and Why DNS Changes Are Not Instant

DNS does not push. Your registrar save is not a broadcast. A recursive resolver that already looked up example.com will keep serving that answer until the time to live on the record expires. That is why a change that looks instant on your laptop is still old on a mobile network, a coffee shop, or Let's Encrypt's validators. TTL, negative caching, and glue are the actual levers. "Propagation" is a marketing word for caches draining at different speeds.

If you treat TTL as a decoration in the DNS panel, you will plan a Friday cutover and spend Saturday explaining why some users still see the old VPS.

TTL is a promise to caches, not a refresh button

Time to live is the maximum number of seconds a resolver may reuse an answer without asking the authoritative servers again. A 300 second TTL means up to five minutes of old data after you edit. A 86400 TTL means up to a day. Resolvers are allowed to serve the record for less time, not more, though a few broken caches ignore that.

The important operational fact: changing TTL from 86400 to 300 does not shorten the copies already cached. Those copies still have whatever remaining lifetime they were given. If you need a fast cutover, set a low TTL at least one old-TTL interval before the change. For a one-day TTL, start 24 to 36 hours early.

dig example.com A +noall +answer
dig example.com A @1.1.1.1
dig example.com A @8.8.8.8
dig example.com A @9.9.9.9

Compare the IP and the TTL column. A TTL of 58 versus 280 on different resolvers is normal: each started its countdown at a different lookup time. When every public resolver you try shows the new IP, issuance and user traffic are aligned enough to proceed.

Negative caching makes missing records sticky

If you delete a record or query a name that does not exist, resolvers cache that absence too. The SOA minimum field (and related negative-TTL knobs) controls how long NXDOMAIN and empty answers stick. People add www, refresh immediately, and still see NXDOMAIN because the "no such name" answer is cached.

The fix is the same discipline as a positive change: do not rely on a single lookup, wait out the negative TTL, or query the authoritative nameserver directly with dig @ns1.provider.net www.example.com. Querying authority bypasses recursive caches and tells you whether the zone is actually updated.

Glue and NS records follow a slower clock

If ns1.example.com is both a nameserver for example.com and a name inside that zone, the parent TLD holds glue A/AAAA records. Changing the VPS IP that hosts ns1 does not update glue. Resolvers that only have glue will keep sending queries to the old IP. This is why running your own nameservers on the same VPS you are migrating is painful. For a typical site, use the registrar or a dedicated DNS host, and keep the VPS as an A record target only.

NS record TTLs are often longer than A TTLs. Switching DNS providers is a two-TTL problem: lower NS TTL first, wait, then change NS at the registrar, then wait again before you drop the old provider.

A cutover timeline that respects caches

A practical sequence for moving a site to a new VPS:

1. Inventory current TTLs for A, AAAA, CNAME, and MX. Write them down.
2. Lower web record TTLs to 300. Do not touch MX if mail is not moving.
3. Wait at least the previous TTL (often 24 hours).
4. Change A and AAAA to the new IP. Keep the old VPS answering until caches drain.
5. Watch public resolvers until they agree. Then run certbot against the new host.
6. After a few days of stability, raise TTL again to 1800 or 3600 so you are not depending on a tiny cache window forever.

OLD=203.0.113.10
NEW=203.0.113.40
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "== $r"
  dig +short A example.com @$r
done
ip addr show

If any resolver still returns $OLD, wait. Serving both machines during the drain is the cheap insurance: keep nginx on the old VPS until the last major resolver flips. Certificates should be issued on the new host only after Let's Encrypt would also see $NEW.

TTL is the only honest estimate of how long a DNS lie can live. Propagation is not a mysterious CDN of DNS; it is caches honouring the number you published last time. Plan the number first, change the IP second. You can keep the old and new Ubuntu VPS side by side on Netbay in Lucknow (DC01) while those caches drain — netbayhosts.in.