You have changed a DNS record or the nameservers of your domain – but the change is not yet visible everywhere? Then it is often referred to as DNS Propagation the speech.
Simply put, the term describes the transition phase after a DNS change during which different DNS resolvers may still use different information. This is primarily caused by the decentralized DNS system with its numerous caches.
Therefore, a DNS change is not distributed to all devices and DNS servers on the internet simultaneously like a file. Instead, already cached DNS responses continue to be used according to their respective cache rules and are queried anew later.
Briefly explained: When you change a DNS record, some users may already receive the new value while others temporarily still use a previously cached value. This behavior is commonly referred to as DNS propagation.
What does DNS propagation mean exactly? #
The term „propagation“ can easily give the impression that a DNS change must be actively distributed from a central server to all DNS servers worldwide.
That is not how DNS works, however.
DNS is a hierarchical and distributed system. Recursive DNS resolvers query needed information and are allowed to cache answers for a certain period of time.
For example, if a resolver the IP address of:
meine-firma.ch
already queried and saved, it does not need to contact the responsible DNS servers again with every new request.
As long as the stored entry is still valid, the resolver can deliver the answer from its cache.
If the DNS record is changed during this time, this resolver may therefore not yet be aware of the change.
A simple example #
Assuming the A-record of your domain currently points to:
192.0.2.10
You change it to:
192.0.2.20
Following the correctly applied change, the authoritative nameserver is already returning:
192.0.2.20
However, a recursive resolver previously still has:
192.0.2.10
queried and is still allowed to use this value from its cache.
This allows two users to receive different DNS responses at the same time.
Important: Different DNS results immediately after a change therefore do not automatically mean that the new DNS configuration is faulty.
What is the TTL? #
plays a central role in DNS caching TTL.
TTL stands for:
Time to Live
The value is usually given in seconds and determines how long a DNS response may be cached.
A TTL of:
3600
corresponds, for example, to one hour.
If a resolver has just queried a DNS record and cached it with this TTL, it can generally continue to use the response until this cache expiration time is reached.
Does the TTL only start when I change a DNS record? #
No. That is an important point.
The TTL of a DNS record that is already in the cache expires independently of when you change the configuration on the authoritative nameserver.
Assuming a resolver queried an entry just before your change, that resolver can still use the old value according to its remaining cache validity.
Another resolver might not have had the entry in its cache at all and queries the current information directly after your change.
Therefore, the new configuration can be immediately visible for one user and only later for another.
Why can't I just update an existing DNS cache? #
When you change a DNS record on the authoritative nameserver, you typically have no control over the existing caches of all recursive resolvers on the internet.
These resolvers use DNS information and their cache logic to decide when a new query is required.
A change in your DNS management therefore does not mean that all previously saved responses worldwide are deleted immediately.
How long does DNS propagation take? #
There is no universal answer to that.
A DNS change can be visible very quickly for some queries. Other resolvers may temporarily still return an older value.
How long a transition phase lasts depends, among other things, on:
- of the previous TTL
- the time of the last query by a resolver
- the type of DNS change
- of the DNS infrastructure used
- during nameserver changes, additionally from the delegation and its caching
Therefore, a statement like „DNS always takes 24 hours“ is technically too generalized.
Note: There is no central clock after which a DNS change suddenly becomes active worldwide. Different resolvers can update their stored information at different times.
Why do you still often read about 24 or 48 hours? #
Such time specifications are frequently used as simplified safety or empirical values, especially when changing name servers.
However, they do not mean that every DNS change actually takes that long.
A single A-record with a comparatively short TTL can be queried with the new value much earlier. When changing the authoritative nameservers, on the other hand, additional DNS levels and cached delegation information play a role.
It is therefore more sensible to check the specific DNS situation rather than solely waiting a flat number of hours.
What is the difference between a DNS change and a nameserver change? #
During a normal DNS change, for example, an A, AAAA, CNAME, MX, or TXT record within the existing DNS zone is modified.
The authoritative name servers remain the same.
At a Nameserver change changes, on the other hand, which DNS infrastructure is authoritative for the domain.
This is a more fundamental change.
If a domain in the future uses the CURIAWEB nameservers:
ns1.curiaweb.ch
ns2.curiaweb.chshould be used, the corresponding nameserver delegation is changed.
We explain how this change works and what should be checked beforehand at Finding and correctly using CURIAWEB nameservers.
Why is changing a nameserver particularly critical? #
When changing a nameserver, not only the transition period should be taken into account.
Above all, it is crucial that the new DNS zone is prepared completely and correctly.
If, on the previous name servers, for example, entries for:
- Website
- SPF
- DKIM
- DMARC
- Subdomains
- external services
- Domain Verifications
are available, the information that is still needed must continue to be provided correctly even after the change.
Otherwise, a disruption can occur that has nothing to do with DNS propagation: the new DNS zone is simply incomplete.
Attention: Don't just wait 24 or 48 hours in the event of a faulty new DNS zone. Missing or incorrect DNS records do not automatically correct themselves by waiting.
How do I know if it's really just DNS propagation? #
This is precisely where a DNS check is helpful.
With the CURIAWEB DNS-Check Can you check the currently publicly visible DNS information of a domain.
For example, if you have changed an A record, you compare the returned value with the expected new IP address.
When changing nameservers, you also check which nameservers are visible for the domain.
You can find a detailed guide on systematic testing at Check DNS records: View current DNS configuration of a domain.
Why am I still seeing the old IP address? #
If an A or AAAA record has been changed and the previous IP address still appears, there are several possible causes.
A DNS resolver may still have the old value in its cache. It is also possible that the change was made in the wrong DNS zone or that the old value is still configured on the actual authoritative nameservers.
Therefore, it should be examined:
- Which nameservers are responsible for the domain?
- What value do authoritative DNS data provide?
- What value do different resolvers provide?
- What TTL does or did the relevant entry have?
Only after that can it be meaningfully assessed whether it is merely necessary to wait for a cache to clear or whether the configuration itself should be corrected.
Why does the website work on my smartphone, but not on the computer? #
This can also happen after a DNS change.
Computers and smartphones can use different networks and therefore different DNS resolvers.
For example, your computer might use your internet service provider's DNS resolver, while your smartphone uses a different resolver over the cellular network.
If one of them still has the old DNS value in its cache and the other does not, different results may temporarily occur.
The same phenomenon can occur between two different internet service providers.
Why does the domain work for me, but not for a customer? #
Here too, a different resolver cache can be a possible explanation.
However, this should not be assumed automatically.
Further possible causes include, for example:
- local DNS cache
- Browser or application cache
- IPv4 and IPv6 differences
- Network problems
- Firewall or security rules
- a faulty server configuration
DNS propagation is therefore a possible cause – but not the explanation for every problem that occurs after a DNS change.
Can my computer store old DNS data itself? #
Yes. In addition to recursive DNS resolvers, operating systems and applications can also temporarily cache DNS information.
This is why it can happen that an external DNS check already shows the new value while a specific device is still working with older information.
In such situations, it can be useful to examine the DNS resolution on the affected device or in the network being used in more detail.
Does restarting the router help? #
Not necessarily.
If the old DNS value is stored in an external recursive resolver, restarting your router will not clear its cache.
Depending on the network setup, a router can cache DNS information itself or have different local states after a reboot. However, a router reboot is not a general method to accelerate worldwide DNS propagation.
Does it help to clear the browser cache? #
A browser cache and a DNS cache are not the same thing.
Clearing the browser cache can help with certain website issues, but it does not automatically remove a DNS record stored on a recursive resolver.
When troubleshooting, a distinction should therefore be made between:
- DNS resolution
- local DNS cache
- browser cache
- web server
- Website or application
Can I speed up DNS propagation? #
You normally cannot centrally delete an already existing cache response on third-party resolvers.
However, with proper preparation, this can be managed during planned DNS changes.
One possibility is to already [the TTL of the relevant DNS record] before to controllably reduce the planned change.
As a result, resolvers are only allowed to cache newly queried responses for a correspondingly shorter duration.
Important: Reducing the TTL only immediately at the time of the actual switch does not eliminate existing caches with the previous longer TTL. A planned TTL reduction must therefore be done well in advance of the changeover so that the old cache entries can expire.
Should I permanently set the TTL as low as possible? #
Not necessarily.
A low TTL causes DNS information to be queried more frequently. This can be practical for planned migrations, but is not automatically the optimal permanent configuration.
Following a successful migration, an appropriate TTL for the respective infrastructure can therefore be used again.
Which values are sensible depends on the respective service and the DNS configuration.
What should I do before a planned hosting change? #
When planning a change of hosting, preparation is much better than subsequent troubleshooting.
First, you should document the existing DNS configuration. The CURIAWEB DNS-Check can help control publicly visible DNS information.
Afterwards, the new hosting environment should be fully prepared before the decisive DNS records are changed.
If a shorter TTL makes sense for the planned switchover, it should be set well in advance.
After the switch, you check the new DNS values again.
What should I do before changing nameservers? #
Special care is required when performing a complete nameserver change.
Before the delegation is changed, the new DNS zone should be prepared as completely as possible.
Therefore, compare in particular:
- A and AAAA records
- CNAME Records
- MX records
- TXT Records
- SPF, DKIM, and DMARC
- Subdomains
- Verification records
- other required special records
We explain the meaning of the various record types under DNS Records Explained: A, AAAA, CNAME, MX, TXT, and CAA.
What happens to email during DNS propagation? #
When changing MX records or nameservers, the transition phase can also affect email traffic.
Different sending mail servers may temporarily use different DNS information.
Therefore, during a planned migration, it is particularly important to sensibly consider the old and new email infrastructure during the transition phase and to fully prepare the DNS zone.
If only the website is being migrated and the email configuration is to remain unchanged, the MX, SPF, DKIM, and DMARC records required for this must not be accidentally lost.
Why shouldn't I constantly change a DNS record? #
If a change is not immediately visible everywhere, the temptation quickly arises to edit the DNS record again.
This can make troubleshooting considerably more difficult.
Instead of a clear old and new state, there are then multiple changes at different points in time. Furthermore, resolvers can still have values from different cache states.
Basic rule: If the new value is correctly configured on the authoritative name servers, do not change it again simply because individual resolvers are still returning older information.
DNS propagation or incorrect DNS record? #
This distinction is crucial.
If the authoritative nameserver is already returning the correct new value and only individual resolvers are still using an old value, it strongly points to a caching effect.
On the other hand, if the authoritative DNS infrastructure already returns an incorrect value, waiting will not fix the problem.
The same applies if a required record is completely missing.
Then the DNS configuration must be corrected.
Where can I edit DNS records at CURIAWEB? #
If your domain's DNS zone is managed via your CURIAWEB hosting, you can view and edit the corresponding DNS records in cPanel using the Zone Editor.
We explain how to use it at Using the DNS Zone Editor in cPanel.
After a change, you can then via the CURIAWEB DNS-Check control which DNS information is publicly visible.
A sensible procedure after a DNS change #
- Check whether the desired new value has been entered correctly in the responsible DNS zone.
- Check which nameservers are authoritative for the domain.
- Perform a DNS query for the modified record.
- Compare the result with the expected new value.
- Take the TTL and potential resolver caches into account.
- Do not make any further changes on suspicion.
This makes it much easier to determine whether there is merely a cache transition phase or if there is actually a configuration error.
Summary #
As DNS Propagation is often referred to as the transition phase in which a DNS change is not yet seen by all queries with the same result.
However, DNS changes are not actively distributed to all DNS servers worldwide at the same time. Recursive resolvers store DNS responses according to their TTL and query them again after the cache expires.
Therefore, one resolver can already deliver the new value, while another temporarily still uses an older response.
How long this condition lasts cannot be answered generally with „24 hours“ or „48 hours“. Decisive factors include TTL, cache state, and the type of change, among others.
When changing nameservers, it is also important that the new DNS zone has been fully prepared. Missing or incorrect DNS records will not be fixed by waiting.
Therefore, after a DNS change, first check the actually published DNS data. If the authoritative configuration is correct, you should not make further changes on a hunch based on individual cached old values.
