You create a new DNS record, hit save, and nothing happens. The site is down, your monitoring reports an outage, ping says the name does not exist. Half an hour later everything suddenly works, even though you changed nothing. Where did that half hour come from when the record has a 5 minute TTL? The answer lies in one of the most commonly overlooked properties of DNS, and it is behind the vast majority of “why hasn’t my change propagated yet” questions. Let’s break it down from the beginning.
What TTL is and why it exists
DNS is a distributed database, and its performance is built on caching. If every query for every domain name had to reach the authoritative servers every single time, the internet would drown in DNS traffic and page loads would be noticeably slower. That is why intermediate servers, called recursive resolvers, remember answers.
TTL (Time To Live) is a value attached to every DNS record that says: “you may remember this answer for at most this long.” It is expressed in seconds. A record with a TTL of 300 may be kept in a resolver’s cache for 5 minutes, after which the resolver has to ask again. Our default TTL is set to exactly 300 seconds, a sensible compromise between the speed of changes and query load: changes propagate within 5 minutes while resolvers do not have to ask unnecessarily often.
The important thing to understand is who actually “consumes” the TTL. It is not your DNS server. It is the resolver on the other side: Google DNS (8.8.8.8), Cloudflare (1.1.1.1), your ISP’s resolver, or a corporate DNS server. Each of them keeps its own independent cache. And this is exactly where the part begins that no DNS provider has any control over.
How “propagation” really works
The word propagation suggests that a change is actively pushed out into the world, gradually reaching more distant servers. In reality, nothing is pushed anywhere. The process is the opposite, and it is passive.
When you save a change, your provider publishes it on its authoritative servers. That is the only part fully under the provider’s control, and it usually takes a few minutes, often just seconds. From that moment on, the authoritative servers answer with the new value to anyone who asks.
The catch is that resolvers do not ask. As long as they have an old answer in their cache with an unexpired TTL, they serve it to their clients and never touch the authoritative servers. Only when the TTL runs out do they issue a fresh query on the next request and pick up the current value. “Propagation” is therefore nothing more than waiting for caches to expire independently at resolvers all over the world. That is why a change already works for your friend on mobile data but not for you at home: each of you uses a different resolver with a differently aged cache.
For a modification of an existing record, the math is simple: publication on the authoritative servers plus at most the TTL. With a TTL of 300, that means roughly 5 minutes. No surprises lurking here.
New records: a trap called negative caching
The surprise lurks with newly created records. And this brings us to the half hour from the beginning of the article.
Resolvers do not only remember answers of the type “this name exists and has this value.” They also remember answers saying “this name does not exist” (NXDOMAIN in DNS terminology). It makes sense: queries for non-existent names make up a surprisingly large share of DNS traffic (typos, stale links, bot probes), and without caching, authoritative servers would have to answer them over and over.
The catch is what governs how long a negative answer is remembered. It is not the TTL of your new record; at the moment of the query, the record did not exist yet, so it could not hand any TTL to the resolver. It is governed by a value from the zone’s SOA record, specifically its last field (defined in RFC 2308 as the negative TTL). Providers typically set it to 3600 seconds, one hour.
Now the scenario familiar to anyone who has ever impatiently waited for a new record. You are preparing a deployment, so you first check whether the name resolves: ping new-service.mydomain.com. It does not exist, of course, you have not created it yet. But with that single query you have just told the resolver to remember the “does not exist” answer. Then you create the record, it is live on the authoritative servers within minutes, but your resolver no longer asks. It holds the NXDOMAIN and will keep holding it for up to an hour from that curious ping of yours. Monitoring started before the record exists does the same thing: the first check “manufactures” the negative cache entry and every following check runs into it.
The result: a new record may show up within a few minutes, or it may take an hour. One single thing decides: whether anyone queried the name before the record was created, and when. The countdown runs from the moment of that first query, not from the moment the record was created.
What a DNS provider can influence, and what it cannot
A provider controls the publication of changes on its own authoritative servers, the default TTL of records, and the negative TTL value in the zone’s SOA. That is all.
What it cannot influence: the caches of thousands of resolvers around the world. There is no way to tell them remotely “drop that old answer.” Some large resolvers offer a web form for manually flushing a specific name (both Google and Cloudflare have one), but that is an emergency measure for individual cases, not a mechanism you can rely on. On top of that, resolvers may treat TTLs their own way: some artificially raise very low values to an internal minimum, others cap long values. Behavior differs from resolver to resolver, and a DNS provider can neither see into it nor intervene.
So it is only fair to say it plainly: once a change leaves the authoritative servers, its fate is in the hands of other people’s caches. Promises like “changes propagate instantly worldwide” cannot be kept by anyone who is telling the truth.
Best practices that save you the waiting
The most valuable rule follows directly from the mechanics of negative caching: create the record first, and only then test it or enable monitoring. The order “let me check if it exists, then I’ll create it” is exactly what triggers the hour-long wait. The order “create, wait a few minutes, then test” avoids it entirely. If you are setting up monitoring for a name that is just being created, add it only after you have verified that the name resolves.
Before a planned change to an existing record, it pays off to lower the TTL in advance. A day ahead, drop the TTL to, say, 300, wait until the old (longer) TTL has expired everywhere, make the change, and once verified, raise the TTL back to its operational value. The change then propagates within minutes instead of hours.
When migrating to a new IP address, keep the old server running alongside the new one for at least one original TTL, ideally longer. Part of the world will keep visiting the old address for a while, and it is better if they find something functional there.
When debugging, query the authoritative servers directly and bypass all caches: dig record.mydomain.com @ns.yourprovider.com. If the authoritative server returns the correct value, the change is published and the rest is just waiting for caches. If it does not, the problem is at the provider or in the zone. This single command reliably settles whose side the hiccup is on. You can check the propagation status at major resolvers by querying them directly (dig record.mydomain.com @8.8.8.8) or with one of the public propagation checking tools.
And one final, lesser known tip: watch out for the cache on your own device. Both the operating system and the browser keep their own small DNS caches on top of the resolver. When everything else checks out and only your computer stubbornly sees the old value, flushing the local cache helps, or simply a moment of patience.
Summary
TTL determines how long resolvers may remember an answer, and therefore how quickly changes propagate. A modification of an existing record takes effect within roughly the TTL, so within a few minutes at the default 300 seconds. A new record is trickier: if anyone queried the name before it was created, the resolver holds the “does not exist” answer according to the zone’s negative TTL, typically up to an hour from the first query. A DNS provider only controls publication on its own servers and the TTL settings; nobody controls the caches scattered around the world. The best defense is knowing the right order: create first, test after.