You changed a DNS record and nothing happened

You edited a record, saved it, reloaded, and the old site is still there. Meanwhile a colleague says it works fine for them. Nothing is broken — you are looking at a cache, and the rules for how long it lasts are more specific than “wait 48 hours”.

There is no such thing as “DNS propagation”

The phrase is everywhere and it is misleading. It suggests your change spreads outward from your provider like a wave, and that you must wait for it to arrive.

That is not what happens. The change is live at your authoritative nameserver the moment you save it. There is no queue and nothing in flight.

What actually delays things is that nobody asks your nameserver. Resolvers all over the internet already asked, got an answer, and were told how long they were allowed to keep it. Until that permission expires, they will keep answering from memory without contacting you at all.

So the question is never “has it propagated”. It is “whose cache am I looking at, and when does it expire”.

TTL is the permission slip

Every DNS record carries a TTL — time to live — in seconds. It is the record’s own statement of how long a resolver may reuse the answer.

example.net.   3600   IN   A   203.0.113.10

That 3600 means one hour. A resolver that fetched this record 50 minutes ago will keep serving 203.0.113.10 for another 10 minutes no matter what you change.

The important and counter-intuitive part: the TTL that governs your change is the old one, not the new one. Resolvers cached the previous record under the previous TTL. Lowering the TTL now only affects resolvers that ask after their current copy expires.

This is why the advice is to lower the TTL before a migration. Drop it to 300 a day ahead, wait for the old long TTL to age out, and then the actual switch clears in five minutes instead of a day.

Why it works for your colleague and not for you

Different resolvers, different caches, different expiry moments. Your colleague’s resolver happened to have no copy, or an older one that already expired.

Three separate caches can hold the stale answer, and you have to clear them in order:

1. The browser. Chrome and Firefox keep their own short DNS cache, independent of the operating system. A hard reload does not clear it. Test in a private window or another browser to take it out of the picture.

2. The operating system. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Windows: ipconfig /flushdns. Most Linux desktops using systemd: sudo resolvectl flush-caches.

3. The resolver you use. This is your ISP’s, your router’s, or a public one like 1.1.1.1. You cannot clear it. It expires when the old TTL says it does. This is the one that keeps you waiting.

Checking what is actually being served

Stop testing in a browser. A browser adds its own cache, its own DNS-over-HTTPS setting, and HTTP-level caching on top, so a stale page tells you nothing about DNS.

Ask a resolver directly and watch the TTL count down:

dig example.net A

Run it twice a few seconds apart and look at the number in the TTL column. If it is decreasing, you are being served from a cache and that figure is the seconds remaining. If it resets to the full value, the cache just expired and refetched.

To bypass caching entirely and ask your own nameserver what it truly holds:

dig @ns1.yourprovider.example example.net A

If that returns the new value and public resolvers return the old one, your change is correct and you are simply waiting. If it returns the old value, the change did not save where you think it did — check that you edited the zone the domain actually uses.

The DNS lookup tool does the same query from a server rather than from your machine, which is a useful second opinion when you suspect something local. Better still, the propagation check asks four resolvers in different regions at once, which answers “whose cache is stale” rather than “what does one cache say”.

The genuinely common mistakes

Waiting is the usual answer, but not always. Before blaming cache, rule these out:

• Editing at the registrar while the domain uses different nameservers. If the nameservers point at a DNS provider, the registrar’s own records are ignored entirely. Check with dig example.net NS.
• A leftover record you forgot. Two A records means round-robin: half of requests get the old server. Deleting is a separate action from adding.
• The wrong record type. A change to A does nothing for a client reaching you over IPv6 via AAAA.
• A CNAME above it. If www is a CNAME to somewhere else, the A record at www is not consulted.
• A trailing dot, or a missing one. In a raw zone file example.net without the final dot is interpreted relative to the zone, giving you example.net.example.net.
• Your VPN. A corporate VPN often forces its own DNS and may resolve internal names differently. Disconnect and retest.

How long to actually wait

Look up the old TTL if you can still find it; the maximum wait is that value from the moment you saved. If the old TTL was 3600, everyone is current within an hour. If it was 86400, a full day.

The “48 hours” figure in support articles is padding for the case where a nameserver change is involved, since those carry their own TTL at the parent zone and are often set long. For an ordinary record change on a domain whose nameservers are not moving, hours is the right expectation.

If it has been longer than the old TTL and you are still seeing the old answer from a public resolver, stop waiting. Something is wrong with the record, not the cache.