Published: 11.10.2026
After you change a DNS record, it can seem that nothing happens. Some visitors see the new address while others still see the old one, and the change appears to spread slowly. This article explains why DNS works this way, how caches decide what people see and how to check the state of a change without guessing.

What propagation really means
People often say that DNS propagates, as if the change travels across the internet like a message. In fact, the authoritative name servers publish the new answer at once. Each resolver keeps a copy of the old answer until the stored time runs out, and the new answer appears for that resolver only when its copy expires. The spread is the sum of many caches expiring at different moments.
Where the caches are
- Your operating system, which keeps a short memory of recent lookups.
- The browser itself, which may keep a DNS result for a short time.
- Your router or home network device, which may forward requests with its own cache.
- Your internet service provider's resolver, which serves many customers at once.
- Public resolvers chosen by applications or devices, which follow their own rules.
How long the wait is
The wait depends on the TTL value of the old record, which is the number of seconds a resolver may keep the answer. A record with a TTL of one hour can be cached for up to an hour after the change. Some resolvers ignore TTL values or keep answers longer than requested, so a few visitors may see the old address for longer. The change is complete for most people once the old TTL has passed, but a small group may need more time.
How to check the change
Ask the authoritative name servers directly, because they hold the current answer for the zone. On Linux or macOS, the dig command with the short option, followed by the record type and the domain, shows the current answer. To ask one particular name server, put its name after an at sign directly after the dig command, then add the domain and the record type. The longer output also shows the remaining TTL. On Windows, the nslookup command with the domain shows what your resolver returns, and the ipconfig command with the flushdns option clears the local cache.
What to do while you wait
- Keep the old server or service running until the change has spread far enough.
- Check the new answer on the authoritative servers before blaming caches.
- Avoid repeated changes, because each one adds another waiting period.
- Test the new server through a hosts file entry on your own computer, which points the name to the new address on that machine only.
- Tell colleagues and clients that a short mixed period is normal.
Common causes of confusion
- Testing from a computer whose resolver still holds the old answer.
- Editing a record at the registrar while the zone is hosted at a different DNS service.
- Forgetting that a subdomain has its own record and its own TTL.
- Browser caches that keep an old redirect or certificate.
After the change is complete
Once the new answer is confirmed everywhere you test, remove leftover records that point to old servers. If you lowered the TTL before the move, restore a normal value afterwards. Note the change with the date, the records involved and the test results, so that the next change is easier to check.
Frequently asked questions
How long does DNS take to update? It depends mainly on the old TTL and on caches you cannot control. Some people see the change quickly and others later, so judge the progress by the TTL, not by a single test.
Can I speed up propagation? Lower the TTL well before the change, then make the change once. You cannot force caches elsewhere to clear.
Why does the site work for me but not for a friend? Your computer may have the new answer while your friend's resolver still has the old one. The authoritative answer shows the current truth.