Problem
I changed the DNS and nothing happened
The change is almost always already live. What has not moved is one of the caches between you and the zone — unless you edited a zone that nothing queries any more.
Ask the name servers that are authoritative for the zone, directly. If they already answer the new value, your work is done and only waiting remains. If they answer the old one, you wrote in the wrong place — and that is the real fault, the one that will never resolve itself.
Do this right now
Three moves. The first one separates “wait” from “start again somewhere else” in two minutes.
Ask the authoritative server, not your resolver
2 minA public resolver answers from its cache; the authoritative server answers from the zone. With dig, target the zone’s name server directly by putting it after an at sign. As long as you are querying a resolver you are measuring its cache, not your change — and that is the mistake that wastes the most time on this particular fault.
If the authoritative server still answers the old value, you edited the wrong zone
10 minLook at which name servers the registry lists for this domain. The classic case: the domain is delegated to one operator, and you just edited the zone still sitting at the legacy host, which nobody queries. The zone you edited exists, it is correct, and it is simply never consulted.
If the authoritative server answers correctly, flush your caches and test elsewhere
5 min, then waitFlush your operating system’s DNS cache, close the browser, and test from a network you have never used for this domain — a phone hotspot does the job. If the new network sees the right value, everything is in order: what remains is waiting, and it has a known duration.
Three possible answers, three very different futures
Put the question to the authoritative server, then read the branch that matches. The other two do not concern you.
Does the zone’s authoritative server already answer the new value?
- Yes
The work is done. What is left is waiting.
Flush your caches, test from another network, and be patient. The wait is governed by the old time to live, not the new one.
- No, it answers the old value
You edited a zone that is no longer used.
Read the name servers the registry lists: the domain is delegated somewhere other than where you just wrote. Make the change again, in the right zone.
- It answers “no such record”
A negative cache is holding you up.
An absence is cached just like an answer. Create the record, then wait out the duration declared in the zone’s
SOArecord — not the one on the new record.
The caches between you and the zone, and how long each holds
“Propagation” is a misleading word: nothing propagates. Caches expire, each on its own schedule. Here they are, from the closest to you to the furthest away.
Your browser’s cache
variesChrome and Firefox keep their own resolutions, separate from the operating system. A private window does not share them, which makes it the fastest test available and it costs nothing.
Your operating system’s cache
until flushedmacOS, Windows and Linux keep a local table. One command clears it and the effect is immediate. It is the only cache on this list you truly control.
Your network’s resolver
the old time to liveThis is what makes you wait. It holds the answer for the time to live declared before your change. Lowering the
TTLafterwards shortens nothing: resolvers that already hold the answer keep it for the old duration.The negative cache
set by the SOA recordA “this name does not exist” answer is cached too. Its duration is the smaller of two values: the MINIMUM field of the
SOArecord and the time to live of the SOA itself. It is why a name created after being tested too early takes so long to appear.Every other resolver in the world
their own ceilingEach resolver applies its own ceiling on top. RFC 2308 recommends one to three hours as a sensible default for negative caching and notes that values beyond one day have been found problematic. This is the part you have no grip on at all.
Source: RFC 2308, “Negative Caching of DNS Queries”, § 4 to § 6. Remember the rule that changes everything: the wait is governed by the old value, not the new one.
The four things that make you think it is broken
None of the four is a malfunction. All four have already cost somebody an evening.
The
TTLlowered too lateLowering the time to live helps before a change, never after. Do it twenty-four hours ahead of the migration, and raise it again once the switch is confirmed.
The forgotten line in the hosts file
Added during testing, it means you alone see the right site — or the wrong one. Look at that file before drawing any conclusion about a resolution that “will not move”.
The proxy answering in your place
Behind a proxying service, the record visible from outside is not your server’s address, and that is normal. You will never see the address you just typed: it is not a fault, it is the design.
The bare domain and www treated separately
You changed one and not the other. Half your tests pass, half do not, and the diagnosis goes off the rails. Check both entry points every time.
Why it happened
Because DNS is not built to answer fast: it is built to answer often, to billions of questions, while bothering the origin servers as little as possible. Caching is not a side effect, it is the mechanism. What you experience as a delay is the system working exactly as designed.
And because a domain rarely has just one zone. The same name often has a zone at the legacy host, another at the operator it was delegated to, sometimes a third at a mail provider. Only the one the registry’s name servers point at is ever queried. The others exist, they are editable, and they serve nothing at all.
That is what makes the first question so useful: in two minutes it separates a waiting problem, which resolves itself, from a zone problem, which never will.
How to avoid it next time
Get into the habit of starting with the name servers. Before any change, look at where the registry delegates the domain, and open only that interface. Five seconds of checking prevents half the incidents of this kind.
Lower the time to live the day before a planned migration, and raise it once the switch is confirmed. A permanently low TTL costs performance; a high TTL on migration day costs a working day.
And monitor the delegation itself. A domain’s name servers rarely change, but when they change without you — a client moving their site to another provider, a host reconfiguring — everything else follows silently: the site, the mail, the automatic certificates.
See where the domain is really delegated
The tool reads the name servers declared for the domain. It is the first thing to look at: they point to the only zone that counts.
When the delegation moves, everything follows.
DomainVigil rereads name servers, MX records and the site’s records every day, and warns you when they change — including when the change did not come from you. Five domains free, no card required.
Five domains free, forever. No card required.