What “propagation” really means
The term is misleading. DNS changes are not distributed around the world step by step. As soon as you save a record, your DNS provider’s authoritative name servers serve it, usually on all servers within seconds to a few minutes.
What takes time is caches expiring. Recursive resolvers (at your internet provider, on your company network, or public ones such as 1.1.1.1 and 8.8.8.8) cache answers, and so do the operating system and the browser. As long as a cache entry is valid, the name server is not even asked. So “cache expiry” would be a more accurate term than “propagation”.
TTL and resolver caches
Every DNS record has a TTL (time to live) in seconds. It tells resolvers how long they may use the answer.
An example: the A record of www.example.ch has a TTL of 86400 seconds (24 hours). A resolver looked it up one minute before your change. It will keep serving the old IP address for almost 24 hours. Another resolver that never looked up the name gets the new address immediately. That is why some people see the new website and others still see the old one.
Other factors:
- Multiple cache layers: The operating system, browser and some applications have their own caches.
- Anycast resolvers: Public resolvers consist of many locations, each with its own cache. Two queries to 1.1.1.1 can return different answers depending on the location.
- Custom rules: Some resolvers cap very high TTLs or enforce minimum values. The basic rule still applies, though: the old TTL is the maximum waiting time.
Learn more about TTL and record types in our guide DNS records explained.
Negative caching: when a name doesn’t exist yet
Resolvers also cache the answer “this name does not exist” (NXDOMAIN). This becomes a trap if you test a new subdomain such as shop.example.ch before the record has been created. The resolver remembers the negative result, and the subdomain stays unreachable for you even though it has long existed.
How long negative answers are cached is defined in the SOA record: the lower of the SOA record’s TTL and its last field (minimum) applies.
example.ch. 3600 IN SOA ns1.example.com. hostmaster.example.ch. (
2026100201 7200 3600 1209600 3600 )Here it is 3600 seconds. Tip: create records before you access them, and keep the minimum value moderate (300–3600 seconds).
Changing a record vs. switching name servers
Changing a record
If you change a record within the same zone, only its previous TTL counts. With good preparation, this is a matter of minutes.
Switching name servers
When you move to a different DNS provider, the delegation changes. Your registrar reports the new name servers to the registry of the extension (SWITCH for .ch, Verisign for .com). The registry publishes the NS records in the parent zone with its own TTL, which you cannot influence. For .com it is 172800 seconds, or two days, which has contributed a lot to the 48-hour myth.
In addition, resolvers may have cached the old NS records from your previous zone. During the transition period, some resolvers therefore still query the old name servers. This means:
- Leave the old zone in place, complete and unchanged, for a few days.
- Keep the content of the old and new zones identical until the switch is complete.
- If DNSSEC is active, remove the DS record before the switch or transfer the keys in an orderly way. Otherwise, validating resolvers can no longer resolve the domain at all.
The WHOIS lookup shows which name servers are registered at the registry.
How to speed up DNS changes
- Lower the TTL early: Set the TTL of the affected records to 300 seconds 24–48 hours in advance. The lead time must be at least as long as the previous TTL.
- Make the change: Enter and save the new values.
- Verify: Check directly at the authoritative name server and at public resolvers (see below).
- Raise the TTL again: Once everything runs smoothly, set the TTL back to 3600 seconds or more.
To flush your own caches:
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux with systemd-resolved
resolvectl flush-cachesIn Chrome, chrome://net-internals/#dns also helps. Cloudflare (1.1.1.1) and Google Public DNS offer web pages where you can have the cache purged for a single name. You have no control over other internet providers’ caches, however.
How to check the current state
Compare two views:
# What is published? Directly at the authoritative name server
dig @ns1.example.com www.example.ch A
# What does a public resolver see? Including the remaining TTL
dig @1.1.1.1 www.example.ch AIf the authoritative server returns the new value but the resolver still returns the old one, your change is correct and only the cache expiry is pending. The remaining TTL in the answer shows how much longer it will take.
Without a command line, use NetScanner’s DNS lookup: every time you run it, it queries the resolver 1.1.1.1 live via DNS over HTTPS and shows A, AAAA, CNAME, MX, NS, TXT, SOA and CAA. This lets you see what Cloudflare’s resolver is serving right now.
DNS propagation myths
“DNS changes always take 48 hours”
No. The duration depends on the TTL. With 300 seconds, a change is visible to most users after a few minutes. The 48 hours date back to a time of high default TTLs and to the delegation TTL of .com.
“If I lower the TTL now, the change takes effect immediately”
No. Answers that are already cached keep their old TTL. The lower value only takes effect after that has expired.
“You can force propagation”
Only partially. You can flush your own caches and those of individual public resolvers, but not the caches of every internet provider worldwide.
“A propagation checker shows the worldwide status”
Such tools provide a snapshot of selected resolvers. That is useful, but every resolver and every anycast location has its own cache. For planning, the TTL is what counts.
If you are planning a complete provider switch, the domain and website migration checklist will help.