'Propagation': why some people see it already and others don't

Module 6: Time, cache and transferring · Reading time: 8 minutes

Learning objective: After this lesson, you can explain why a DNS change isn't visible everywhere at the same time, estimate how long it takes, and solve the problem if you're the only one still seeing the old situation.

Key concepts: 'propagation', cache, negative cache (NXDOMAIN), SOA minimum, delegation TTL, nameserver change, clearing cache

A misunderstanding in one word

You've changed a record. Your colleague already sees the new website, but you still see the old one. Online, you'll read: "just wait, the DNS still needs to propagate." The word propagation (spreading) gives the impression that your change rolls across the internet like a wave, from server to server.

That's not how it works. Your change is immediately on the authoritative nameservers of your domain (or within a few minutes, if your DNS provider synchronises multiple nameservers). Nothing is being sent around. What you're seeing is caches expiring: each resolver gives the old answer until the TTL in its cache runs out (lesson 6.1). Because each resolver started counting at a different moment, some see the change sooner than others.

So "propagation" is really: waiting for all caches to empty. That insight helps you, because now you know exactly what you're waiting for, and the maximum time involved.

How long does it take?

That depends on what you're changing.

Existing records

Here it's simple: the old TTL is the maximum. If the record had a TTL of 3600, everyone sees the new answer within an hour of your change at the latest. If someone still sees the old answer after more than an hour, the problem lies elsewhere (see below).

New records and the negative cache

A new record usually works immediately, unless someone already queried the name before it existed. The resolver then got the answer NXDOMAIN ("this name doesn't exist") or "this name exists, but has no record of this type". That "no" is remembered too. This is called the negative cache.

How long a "no" is kept isn't stated in a record that doesn't exist. It comes from the SOA record of the zone: according to RFC 2308, it's the smaller of two numbers, the TTL of the SOA record itself and the last field of the SOA record (the "minimum"). An example:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; serial number
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; minimum

Here, a "no" is remembered for a maximum of 300 seconds (the smaller of 3600 and 300). For some zones, that's an hour or more.

So here's the golden rule: don't open a new subdomain in your browser before you've created it. Your computer and your resolver will then remember that it doesn't exist, and you're the only one who has to wait.

Changing nameservers

With a nameserver change, you're waiting for something else: the NS records at the registry of your extension. Those records tell resolvers where your domain's nameservers are (lesson 2.1), and those are remembered too. Each registry chooses its own TTL for this. Measured in November 2026:

On top of that, a registry sometimes doesn't publish your change immediately, and the nameservers of your old provider often still answer with the old zone in the meantime. So when switching nameservers, expect it to take a few hours, and up to two days for .com. Make sure both providers have the same, correct records during the switch (lesson 6.3).

Are you the only one still seeing the old version?

Does an online checker already show the new answer at almost all resolvers, but not for you? Then the old answer is cached somewhere close to you. Go through these steps, from quick to thorough:

1. Private window or a different browser. Your browser stores DNS answers and pages.
2. Phone on 4G or 5G, with wifi off. That way you use your mobile provider's resolver instead of your home network's.

3. Clear your computer's cache.

   • Windows (Command Prompt): ipconfig /flushdns
   • macOS (Terminal): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux with systemd-resolved: resolvectl flush-caches
4. Restart your router. Many routers work as a small resolver with their own cache.
5. Check the hosts file. Did you previously test a new server by putting its address in your hosts file (C:\Windows\System32\drivers\etc\hosts or /etc/hosts)? That line takes priority over DNS. Remove it. This is often forgotten.
6. Check directly at the source. Query the record at the authoritative nameserver (dig A example.com @ns1.hosting.example). If the old answer is still there too, the change wasn't saved properly, or you made it in the wrong place.

Still nothing after the waiting period?

If the TTL has long since passed and online tools also show the old answer, waiting is pointless. Something else is going on. The three most common causes:

• Changed in the wrong place. Your domain uses another provider's nameservers (for example Cloudflare or a website builder), and you changed the records at your hosting provider. Check which nameservers your domain uses (lesson 2.1) and make the change there.
• Typo or missing dot. mail.example.com without a trailing dot becomes mail.example.com.example.com in many panels (lesson 2.2).
• The nameservers don't agree with each other. A domain has at least two nameservers. If they don't synchronise properly, one gives the new answer and the other the old one. Compare the SOA serial number at each nameserver: it must be the same.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

In practice: what it looks like in a panel

If you want to see what resolvers in different parts of the world answer, use an online DNS checker that queries a resolver per country (for example dnschecker.org). In the example panel My WebOké, the Domain / Email health card checks your domain's nameservers and records against the authoritative nameservers, and the DNS diagnostics compare the nameservers' serial numbers. Other providers often have a similar check in their panel; if not, dig and the online tools from lesson 8.3 give you the same picture.

Summary

• Nothing is "spread": you're waiting for caches to expire.
• A changed record is visible everywhere within the old TTL at the latest; a new record is usually visible immediately, unless someone already queried the name earlier (negative cache, determined by the SOA record).
• A nameserver switch depends on the TTL at the registry: one hour for .nl, two days for .com.
• Are you the only one still seeing the old version? Try a private window, 4G, clearing your cache, restarting your router, and checking the hosts file.
• Still old at the authoritative nameserver? Then waiting is pointless: find the error.

Quiz

Exercise

Exercise Z6.2: Delegation TTL and negative cache. Two questions, both answerable with dig or an online dig tool:

1. According to the .com registry, how many seconds do resolvers remember the nameservers of google.com? Query a .com server: dig NS google.com @a.gtld-servers.net and look at the TTL in the AUTHORITY section.
2. How many seconds does a resolver remember that a name under sidn.nl doesn't exist? Query the SOA record of sidn.nl at ns1.sidn.nl and apply the rule from this lesson (the smaller of the SOA TTL and the SOA minimum).

Further reading

The steps in these articles refer to WebOké's panels; in other panels it works in a similar way.

• How long does a nameserver or DNS change take, and what if you don't see it?
• Website or email not working after a move or DNS change: check your domain
• DirectAdmin guide 5.11: When does a change take effect? Waiting time and TTL
• Creating a subdomain, and what to do if it doesn't work
• How can I test my domain before it has been transferred? (localhost)
• WebOké manual 5.17: Domain and email health: checking and fixing