Why your DNS change has not taken effect yet

31 August 2026 · Alex

You changed a record. You checked. It is still the old value. Somebody tells you DNS "takes 24 to 48 hours to propagate", and you wait.

That explanation is wrong, and believing it costs people real downtime — because the thing you should have done had to happen before the change, not after.

Nothing propagates

There is no distribution process. Your authoritative nameservers hold the new record the instant you save it, and any resolver that asks them gets the new answer immediately.

What you are seeing is caching. A resolver that asked an hour ago kept the answer it got, and it will keep using that copy until it expires. It is not waiting for anything to arrive. It simply has no reason to ask again.

You can prove this to yourself in a few seconds. Query your authoritative nameserver directly and you get the new value; query a public resolver and you may still get the old one. Same record, same moment, two answers.

TTL is a promise you already made

Every record carries a TTL — time to live — in seconds. It tells resolvers how long they may cache the answer.

A record with a TTL of 86400 tells the world: this answer is good for 24 hours. When you change that record, resolvers holding a copy are not misbehaving by continuing to serve it. They are doing exactly what you asked, using the promise you made before you decided to change anything.

This is the part worth sitting with: the delay you experience today was set by the TTL that was in place yesterday. Lowering the TTL at the same time as you change the record does nothing for anyone already holding a copy.

How to make a change that takes effect quickly

1. Lower the TTL first, and wait out the old one. If the record is at 86400, set it to 300 and wait a full 24 hours. Every cached copy expires during that window and gets replaced with one carrying the short TTL.
2. Make the real change. Now the worst case is five minutes, not a day.
3. Put the TTL back up once you are confident. Low TTLs mean more queries and a slower first visit for anyone whose resolver has nothing cached.

That is the whole technique. It is unglamorous and it works every time, and it is entirely useless once you have already made the change.

Why different people see different things

Two colleagues checking the same domain get different answers, and it looks like chaos. It is not:

• Different resolvers cached at different moments. One asked five minutes before the change, one five minutes after. Their copies expire at different times.
• Your operating system caches too. So does your browser, independently and often for longer than you would guess.
• Some resolvers ignore small TTLs. A minimum of 30 to 60 seconds is common, and a few enforce far more.
• Negative answers are cached as well. If a name did not exist when somebody asked, the absence is cached too — governed by the SOA's minimum field, not by any TTL you set on the record you later created. This is why a brand new subdomain can be stubbornly missing for someone who checked it too early.

That last one catches people constantly. Check a name before you create it, and you have taught your resolver it does not exist.

Checking properly

Ask the authoritative server directly, and separately ask a public resolver. The difference tells you which problem you have:

dig +short www.example.com @ns01.example-dns.com
dig +short www.example.com @1.1.1.1

• Authoritative right, resolver wrong — it is cache. Wait out the TTL.
• Authoritative wrong — the change did not save, or you edited a different zone.
• Authoritative returns nothing — the zone may not be delegated to that server at all.

To see the remaining cache time rather than just the value, drop +short and read the TTL in the answer. It counts down. When it reaches zero, the next query fetches your new record.

When it really is 24 to 48 hours

There is one case where the old advice is roughly right: changing which nameservers your domain is delegated to. That delegation lives in the parent zone — at the registry — and the NS records there commonly carry a TTL of a day or two. You cannot lower it, because it is not yours.

So when you migrate DNS providers, plan for the delegation to overlap. Keep the old provider answering with correct records until you are certain nothing is still asking it. Switching off the old zone the moment the new one goes live is the single most common way a migration causes an outage.

The short version

Nothing propagates. Resolvers cache, TTL is how long you told them to, and the fix has to happen before the change. Lower the TTL, wait out the old one, then move.

KumoDNS shows the TTL on every record and lets you set it per record. If you want to see what a zone looked like before a change, Time Machine keeps versions you can roll back to.