TTL, Caching, and the Propagation Myth

Every DNS record carries a **TTL** — a number of seconds. When a resolver learns an answer, it may cache and reuse that answer until the TTL expires. That's it. That's the whole 'propagation' mystery.

Why some users see the change and others don't

Different resolvers cached the old answer at different moments, so their countdowns expire at different times. The authoritative server already has the new value; the resolvers are simply obeying the TTL you set.

Negative caching

Resolvers also cache **failures**. If a name didn't exist and you then create it, resolvers may keep returning NXDOMAIN until the negative-cache TTL (governed by the zone's SOA minimum) expires. Creating a record and seeing it 'not work' for a few minutes is usually negative caching, not a broken zone.

The operator move: lower TTL before a change

• Days before a planned migration, drop the record's TTL (e.g. to 60s).
• Wait for the old (high) TTL to age out everywhere.
• Make the change — now it ages out fast.
• Raise the TTL back afterwards for efficiency.