Caching, and why "propagation" is the wrong word — Domain Security Fundamentals

"DNS propagation" is the most widely used incorrect term in the field. Nothing propagates. Understanding what is actually happening turns an unpredictable wait into an arithmetic problem.

What is actually happening

Your authoritative servers are updated the moment you publish. There is no distribution step and no queue. What takes time is that resolvers all over the world are holding previous answers they were entitled to keep, and they will keep them until those expire.

The correct mental model

You are not waiting for a change to spread. You are waiting for old copies to expire. The change is already everywhere it needs to be; the old answer is what is still in the way.

The practical consequence: the wait is bounded by the TTL that was on the old record when a resolver last fetched it. Not the new one. Lowering the TTL at the same time as making the change does nothing for that change.

Reading the TTL

$ dig +noall +answer A example.com

example.com.    69  IN  A  104.20.23.154
example.com.    69  IN  A  172.66.147.243

Checked 2026-09-12. The 69 is seconds remaining in this resolver's cache — counting down, not the configured value.

That number from a recursive resolver is the remaining lifetime. Ask the authoritative server and you get the configured value instead:

dig +noall +answer @ns1.example.com A example.com

Two different questions with two different answers, and confusing them is why people report that the TTL "keeps changing".

Negative caching, and its separate timer

The absence of a record is cached too. If a resolver asks for a name that does not exist, it caches the NXDOMAIN — using not the record’s TTL, since there is no record, but the last field of the zone’s SOA.

$ dig +short SOA certadns.com

ns1.certadns.com. hostmaster.certadns.com. 2026091002 10800 3600 604800 300

Checked 2026-09-12. The last field, 300, is the negative-caching TTL.

This catches people out regularly: you create a record that did not exist, and resolvers that asked for it in the meantime keep saying it does not exist for the negative TTL. The record is published, dig against the authoritative server confirms it, and a colleague still cannot see it. Nothing is wrong.

Planning a change

Well before the change — at least one current TTL in advance — lower the TTL on the records you are going to move. This is the step that has to happen early, and it is the step people skip.
Wait for the old TTL to expire everywhere, so resolvers are now holding the short one.
Make the change. Worst case exposure is now the short TTL.
Verify against the authoritative servers first, then against several public resolvers.
Raise the TTL again once you are confident.

The rollback is what the TTL really governs

A long TTL does not just slow your change down — it slows your undo down by the same amount. If a cutover goes wrong at a TTL of 86400, some resolvers will hold the broken answer for up to a day and there is nothing you can do about it. That is the real argument for lowering it beforehand.

Knowledge check

A record with a 24-hour TTL is changed. At the same moment, its TTL is lowered to 300 seconds. How long before every resolver has the new value?

Up to 300 seconds, because the TTL is now 300.
Up to 24 hours, because resolvers holding the old record were told to keep it that long.
Immediately, because authoritative servers are updated on publication.
It depends on the SOA refresh interval.

Not this — Up to 300 seconds, because the TTL is now 300. The new TTL only applies to answers fetched after the change. A resolver that cached the old record ten minutes ago was told to keep it for 24 hours, and it will.

Correct — Up to 24 hours, because resolvers holding the old record were told to keep it that long. The TTL that governs a cached answer is the one attached when it was fetched. Lowering the TTL at the moment of change is too late — it makes the next change fast, not this one. That is why the TTL reduction has to happen at least one full old-TTL period in advance.

Not this — Immediately, because authoritative servers are updated on publication. The authoritative servers are indeed updated immediately. Resolvers holding cached copies do not consult them again until their cached answer expires, so clients keep receiving the old value.

Not this — It depends on the SOA refresh interval. The SOA refresh interval governs how often secondary authoritative servers check the primary for zone updates. It has nothing to do with recursive resolver caching, which is governed by record TTLs.