You changed the nameservers, or you changed a record, and you still see the old place. This is almost never a fault: it is an answer kept somewhere. This article shows you where it is kept, why each place lies in its own way, and how to get through each layer.
|
The TTL that rules is the OLD one. Everybody changes the record and then drops the TTL to five minutes, expecting it to go faster. It does not. Whoever cached the old answer cached it with the old TTL, and will only ask again when that time runs out. The new TTL only starts counting at the next change. Lowering the TTL does work, but it has to be done before the change, as far ahead as the TTL that is in place today.
|
The four places, and how each one lies
| Where |
Why it lies |
How to get through it |
| 1. The browser |
It keeps the page, the images and, in some cases, the DNS answer itself. And if the site has ever been on https, the browser may refuse to go over http even when you type it that way. |
Private window, another browser, another device. Force a reload, and clear the recent history. Never use your own browser as proof. |
| 2. The computer’s cache |
The operating system keeps answers of its own, and does not always honour the TTL to the letter. This is the layer that makes a site open on the phone and not on the laptop. |
On Windows: ipconfig /flushdns. On Linux with systemd: resolvectl flush-caches. On macOS: sudo dscacheutil -flushcache then sudo killall -HUP mDNSResponder. |
| 3. Your internet provider’s resolver |
This is the one that sets your real waiting time. It cached the old answer and will only ask again when the old TTL expires. No button anywhere forces it. |
Wait, or ask someone else. A phone on mobile data uses a different resolver and makes a good second opinion. By command, ask any public resolver, for instance dig @1.1.1.1 A yourcompany.com or dig @8.8.8.8 A yourcompany.com. |
| 4. The authoritative zone |
It does not lie. It is the source. If it is right here, the change is made and the rest is time. If it is wrong here, waiting will not help: it was not saved, or it was saved in the wrong place. |
Ask it directly: dig @dns1.mozout.com A yourcompany.com. Swap the record type for MX or TXT depending on what you changed. |
|
There is a fifth layer, and it is the slowest of all: the delegation held at the registry for the extension, that is, the nameserver list. It has a TTL of its own, usually longer than the records’, and that is why a nameserver change takes longer to show than an A record change. If you only changed a record inside the zone, this layer does not come into it.
|
The right order to check: from the inside out
Go in this order. As soon as a step fails, stop: you have found the problem, and the later steps would only give you wrong information.
| 1 |
Ask the source. dig @dns1.mozout.com A yourcompany.com. Right? Then the change exists and only time is missing. Wrong? The change was not saved where it should have been; go back to the panel.
|
|
| 2 |
Ask about the delegation. dig NS yourcompany.com. The nameservers that come back are the ones actually in charge. If they are still the old ones, it is the delegation that is pending and nothing else matters yet.
|
|
| 3 |
Ask a resolver outside your network. dig @1.1.1.1 A yourcompany.com. If it is already right there and still wrong in your office, the problem is local and the next two steps fix it.
|
|
| 4 |
Flush your computer’s cache, with the command from the table for your system.
|
|
| 5 |
Open it in a private window, or on another device, or on mobile data. If it now looks right, you are done: what was left was your own machine.
|
|
How long you wait
We do not give a number, because there is not one: the time is whatever TTL the old answer declared, and that was decided by whoever held the zone before. It may be short, it may be long. How long DNS changes take to propagate explains the mechanics, and how to check a domain DNS gives the lookups step by step.
|
The only thing that genuinely shortens the wait is lowering the record’s TTL before you change it, and waiting out the old TTL before making the real change. On a planned server move, that is the difference between a window of minutes and a window of days. We can set this up with you.
|
When it has stopped being propagation
Once the old TTL has run out, if you still see the old one everywhere, stop waiting. At that point the causes are different.
| Symptom |
What it almost always is |
| The source answers with the old value |
The change was not saved, or it was saved in a zone nobody reads any more (the classic: editing at the registrar after the nameservers are already ours). |
| The site opens but shows a security warning |
Not DNS: the certificate, which is only issued once the domain points here. See domain validation. |
| A list of files appears instead of the site |
DNS is right and content is missing. See seeing the site before the domain points here. |
| The old provider’s page appears |
A record is still pointing there, or the registrar’s parking is still switched on. |
| The site is visible and the e-mail stopped |
The MX records followed the nameservers. This is urgent. See why your e-mail is not sending or receiving. |
| The domain resolves for nobody, not even at the source |
It may be DNSSEC left active at the registrar after the zone moved, or the domain may have expired. See expired domain. |
And if the site really is down and none of this is it, the checklist is in your site is down.
|
Tell us the domain and what you changed. We will query all four layers from our side and tell you whether you need to wait or to fix.
Open a support ticket
|
RECOMMENDED PRODUCT Register your .com domain Secure your company name before someone else registers it. from ₦25.500,00/yr Search a domain |
Angola
Brasil
Kenya
Moçambique
Nigeria
Portugal
South Africa
United Kingdom
United States
International
