Português
English
The short answer: when you save a DNS record, the change takes effect at once on the servers that hold the zone (the authoritative ones). Nothing “travels” across the internet from there. What people call propagation is something else: many servers around the world stored the old answer in a cache, each from the moment it asked, and they only ask again when the TTL that came with that answer runs out. Nobody pushes the change; every cache forgets the old answer when its own time is up.
The links in the chain, and who controls the time of each
| Link | What it keeps | How long, and who decides |
| The registry for the extension (the delegation) | The list of nameservers for the domain. | A TTL of its own, set by the registry, not by you. It only matters when you change nameservers. |
| The authoritative nameservers | The zone itself: this is the source, and it keeps no copies of anyone else’s answers. | They change when you save. If the zone has secondary servers, they copy it when the SOA serial number goes up. |
| The recursive resolver (your internet provider’s, your company’s, or a public one) | Answers it has already given to someone. | The record’s TTL, counted from the moment it asked. Some resolvers apply limits of their own, up or down. |
| The operating system and the router | Their own copy of names already looked up. | Usually the TTL, though not always to the letter. |
| The browser and the apps | A name cache of their own, and connections already open to the old address. | Until the program closes or the connection drops. This is the layer ipconfig does not reach. |
Why one person sees the new site and another the old one: each resolver stored the answer at a different moment, so each forgets it at a different moment. A phone on mobile data uses the carrier’s resolver; the office computer uses the company’s or the internet provider’s. They are separate caches with separate clocks, and none of them is “broken”.
How to think after a change
|
|
|
|
|
| There is no button that speeds up propagation for the world. A service promising to “force propagation” can only clear the caches it controls. And lowering the TTL after the change shortens nothing: whoever stored the old answer stored it with the old TTL. |
| The only way to shorten the wait is to prepare beforehand: lower the TTL on the records that will change, wait for the old TTL to pass, and only then make the change. The step by step is in lowering the TTL before a migration. |
|
Not sure whether what you see is still a cache or already a mistake? Tell us the domain, what you changed and when. Open a support ticket |
RECOMMENDED PRODUCT Register your .ao domain Secure your company name before someone else registers it. from $33.30/yr Search a domain |
