You moved your store, souq-alataba.com, to a new server at 10 am Cairo time. A colleague in Alexandria sees the new site within minutes, while a customer in London is still reaching the old server at 3 pm. Nothing is broken, and nothing is actually “propagating”: your name server doesn’t push the change to anyone. Thousands of resolvers around the world hold on to the old answer until it expires, each on its own clock. Once you know who keeps the answer and for how long, you can plan any change without your visitors noticing.
Each resolver counts down your record’s TTL on its own clock, so the change reaches one city minutes after the edit and another hours later.
01Nothing propagates: caches expire
When a visitor types your domain, their device doesn’t ask your name server directly. It asks a , usually their ISP’s or a public one, which walks the chain from the DNS root to the TLD servers and on to your domain’s , then keeps the answer in its cache. Every answer carries a number called the : how many seconds the resolver may keep handing out that answer without asking again.
Your edit in the DNS panel reaches the authoritative server at once. But a resolver that cached the old answer an hour ago, with a TTL of 86400 seconds, will keep giving it to everyone who asks for another 23 hours. Another resolver that hasn’t looked up your domain in days will fetch the new answer on the first request. So the change doesn’t reach a country all at once; it reaches each resolver when its copy expires. And between your visitor and the resolver sit more caches: the operating system, the browser, and sometimes the home router.
Try it in the simulator: move time forward after an A record change, and watch the new answer reach each country according to how much TTL its resolver had left.
Try it yourself
Watch the change spread around the world
You changed your domain’s A record a moment ago.
Now12 h24 h36 h
4countries the new answer has reached, out of 6
GermanyFinlandUAEUS West CoastUS East CoastSingapore
GermanyNew answer arrived
FinlandNew answer arrived
UAEOld answer for 2 more hours
US West CoastNew answer arrived
US East CoastNew answer arrived
SingaporeOld answer for 26 more hours
02TTL: the number that sets the wait
The one thing to remember: the wait is set by the old TTL, the value the record had when resolvers cached it, not the value you type now. If your record’s TTL was a full day and you cut it to 300 seconds in the same edit that changed the address, resolvers holding the old copy will keep it until their day is up.
TTL in seconds
Duration
When to use it
60 to 300
1 to 5 minutes
Before a planned move, and for records you switch by hand during outages
3600
1 hour
The usual value for most A, MX and TXT records
14400 to 86400
4 hours to 1 day
Stable records such as NS: fewer queries, and less impact from a brief name server outage
Why not keep the TTL low all the time? Because every expiry means a fresh lookup through the whole chain, which adds tens of milliseconds to the first request after it, puts more load on your name servers, and makes your site more sensitive to any outage there. And resolvers don’t all follow the number to the letter: some raise very low values to a floor of their own, and some cap high ones at a day or a week. Treat the old TTL as the expected wait for most of your visitors, and leave a margin for the few that differ.
A very low TTL sends resolvers back to name servers like these far more often, adding load and exposure to any outage.
03Negative caching: when “doesn’t exist” is cached
Resolvers don’t only cache answers that exist. Ask for a name that doesn’t exist and the answer comes back NXDOMAIN, and the resolver caches that too, for a time set by your zone’s SOA record: the lower of the SOA record’s own TTL and its last field, called MINIMUM. That’s , and it’s behind a problem that comes up again and again.
An example: you’re launching shop.souq-alataba.com at 10:00. Five minutes earlier you open the link to try it before adding the record, and your ISP’s resolver caches “doesn’t exist”. You add the record at 10:00 and your colleagues see it right away, while you keep getting an error until the negative answer expires, which can take an hour. The rule is simple: add the record first, then test it. To find the duration for your domain, read the last field of the SOA:
Reading the negative-caching time from the SOA record
# The last field of the answer is the negative-caching time, in secondsdig souq-alataba.com SOA +nocmd +noall +answer# Sample output; the time here is 300 seconds:# souq-alataba.com. 3600 IN SOA ns1.souq-alataba.com. hostmaster.souq-alataba.com. 2026101101 7200 1800 1209600 300
Many resolver programs cap this time, at one to three hours in their default settings, but don’t build your plan on that.
04Why name server changes take longer
Changing a record inside your zone goes through one layer of caches. Changing the themselves, say to move your domain’s DNS from one provider to another, goes through a layer above it: the delegation records in the TLD’s own zone, such as .com or .net, whose TTL you don’t control. In many TLDs it’s 172800 seconds, or 48 hours, which is where the familiar figure comes from. The value varies by TLD, and some registries only publish changes in a periodic update cycle, which adds to the wait.
During that time some resolvers ask the old servers and some ask the new ones. So a safe move starts by copying the whole zone to the new provider before the switch, and keeps the old zone running with identical records for at least three days after it. Don’t delete it on the day of the change, and don’t edit a record in one without the other. To see the delegation TTL for your domain’s TLD, ask the TLD’s server directly:
Finding the TTL of the delegation records in the TLD’s zone
# Ask one of the TLD’s servers for your domain’s delegation, without recursion (replace com. with your TLD)dig @$(dig +short NS com. | head -n1) souq-alataba.com NS +norecurse +noall +authority# The number after the domain name on each line is the delegation TTL, in seconds
05A zero-downtime change plan
These steps work for moving a website or mail to a new server, and they turn the wait into a timeline you know in advance:
01Read the current TTL: Ask the authoritative server for the record you’ll change and note its TTL. If it’s 86400, you have a full day between lowering it and changing the record.
02Lower it in advance: Set the TTL to 300 seconds, and wait at least as long as its old value so every long-lived copy expires.
03Prepare and test the new server: Test it under your domain name before you touch DNS, with the last curl command in the checks below, which reaches the new address directly without asking any resolver.
04Change the record in a quiet hour: And keep the old server serving visitors, or forwarding them to the new one, because some will keep arriving for a while.
05Verify and watch: Ask the authoritative server, then public resolvers, and follow the old server’s access log until the requests stop.
06Restore the TTL: After a day or two of stability, set it back to 3600 or higher, then shut down the old server.
06Check it yourself: dig and the propagation check
Don’t judge from your browser: it’s the last link in a chain of caches. Ask each layer separately:
Checking each layer: the authoritative server, public resolvers, the chain from the root, and the new server
# 1. The authoritative server: what everyone should see (TTL here is the full value)dig @$(dig +short NS souq-alataba.com | head -n1) souq-alataba.com A +nocmd +noall +answer# 2. Public resolvers: TTL here is what’s left in their cache, counting down with each querydig @1.1.1.1 souq-alataba.com A +nocmd +noall +answerdig @8.8.8.8 souq-alataba.com A +nocmd +noall +answer# 3. The whole chain from the root, with no cache in betweendig +trace souq-alataba.com A# 4. Test the new server under your domain name before changing DNS, or during the waitcurl -sI --resolve souq-alataba.com:443:203.0.113.50 https://souq-alataba.com/
Read the second column of each answer. From a public resolver, it’s the seconds left before it asks again: if you see the old address with 41000, you know it will change in about 11 hours, so there’s no need to worry or to make another edit. Large public resolvers run on many servers, so the number may differ from one query to the next.
The seconds left in a resolver’s answer turn the wait into a known countdown, so there’s no reason to make another edit.
Then look at the global picture with Illevante’s DNS propagation check: it asks 19 points around the world, from Dubai, Riyadh and Cairo to Frankfurt and Singapore, for your domain’s records, and compares each answer with what its authoritative name servers say. Within a minute you see where the new answer has landed and where an old copy is still waiting to expire. And if the change shows up everywhere except your own machine, flush your system’s cache, then close and reopen the browser:
ProblemThe authoritative server itself returns the old value
FixYou edited a zone nobody reads, because your domain points to other name servers. Compare the output of dig NS with where you’re editing, and make the change in the live zone.
ProblemA day later, some resolvers still return the old address
FixThe old TTL was high, or some resolvers keep answers longer than it. Watch the remaining TTL in dig, and keep the old server serving visitors until it runs out.
ProblemA new subdomain says “doesn’t exist” for you alone
FixNegative caching from a test made before the record was added. Wait out the SOA’s last field or ask another resolver, and flush your machine’s cache.
ProblemAfter a name server change, check points return different answers
FixSome are still asking the old servers because of the delegation TTL. Make sure both zones match, and don’t delete the old one for three days.
ProblemThe website works but mail stopped after moving the zone
FixThe A record moved and MX or TXT was forgotten. Compare every record between the two zones, not just the website’s.
07Before you change a record tomorrow
Keep the usual TTL for your website and mail records at one hour, lower it to 300 seconds ahead of any planned change by at least its old value, then restore it two days later. Add new records before you test them, and keep the old server and the old zone alive until the last cached copy expires. And verify in order: the authoritative server first, then public resolvers, then the propagation check from 19 points.
If you manage your records in DNS Console, every save reaches Illevante’s name servers instantly, and what remains is the cache expiry explained here. Record types and the right TTL for each are covered in a separate article on the blog.
