/guides · /guides/editing-the-wrong-dns-zone

You moved your nameservers — and kept editing the old DNS panel

An edit that saves cleanly and changes nothing usually means you are editing a zone nobody is being asked about. This is not propagation, and waiting will not fix it.

First, rule out the boring answer

If the change is minutes old, it may simply be cached — resolvers keep serving the old answer until its TTL runs out, and your own browser caches on top of that. Check from a different network rather than just a different device — a fresh laptop on the same wifi asks the same recursive resolver, and that is the cache that matters. Mobile data on a phone is the quickest second opinion. Or read the section on browser caching in connecting a domain to a website. What you are waiting out is the TTL on the record you changed — an hour on most default settings, a full day if it was set high. And if what you moved was the nameservers themselves, allow two days: .com and .net hand out the delegation with a 48-hour TTL, so resolvers can go on asking your old nameservers for that long. Once the edit has outlived that and nothing has moved, it is not cache. Carry on down this page.

The failure nobody warns you about

Your domain has two separate places that look like "DNS settings". The registrar where you bought the name has a DNS panel. So does your host, or Cloudflare, or wherever else you pointed the domain. Both are fully editable, both save without complaint, and only one of them is being asked.

Which one is decided by the nameservers on record at the registry. That delegation is the switch. When you moved it — to a host, to Cloudflare, to a new provider — the registrar's own DNS panel did not become read-only. It kept its old copy of your zone, kept accepting edits, and kept being ignored. So you change an A record, the panel confirms it, and the internet never finds out.

This is why the symptom is so confusing. Nothing errors. Nothing warns you. The record is really there, in a file nobody opens.

Two lookups that settle it

Start with the registry's own answer. A WHOIS / RDAP lookup lists the nameservers the registry hands out for your domain. That list is the authority: whoever is named there answers for your zone, and nobody else does.

Now compare it with the panel you have been editing. If the WHOIS lookup names ns1.example-host.com and you have been editing records at your registrar, you have your answer and you have it in one step. The edits are real, they are just in the wrong zone.

A DNS lookup on the same name is the second half. It returns the NS set as public resolvers see it, alongside the A, MX and TXT records they are currently being given. Where the NS set matches the registry and the A record still shows the old address, the delegation is fine and the problem is in the zone itself.

WHOIS nameserversDNS lookup showsWhat it means
Not the panel you editOld recordYou are editing a zone nobody queries. Move the edit.
Matches the panelOld recordRight zone, wrong record — or still inside its TTL.
Matches the panelNew recordIt worked. What you are seeing is a cache on your side.
Empty or unexpectedNothing resolvesThe delegation itself is broken.

Two honest limits on those lookups

Our DNS lookup asks a public resolver rather than querying your authoritative nameserver directly: 1.1.1.1, falling back to 8.8.8.8 only if that does not answer. It is deliberate — it shows what the internet is being told rather than what your provider intends — but it means a very recent change can still be sitting in that resolver's cache here too.

And registry data has its own lag, though it is the quicker of the two: gTLD registries are required to publish a change within sixty minutes, so a WHOIS answer naming the old nameservers is only misleading very briefly. The resolver cache is the slow half, and for a delegation change that is the two days above. Neither explains an edit that has done nothing for a week.

Fixing it

Once you know which zone is live, the repair is clerical rather than clever. Make the edits in the panel belonging to the nameservers the registry names, and check that every record you need exists there — not just the one you were changing. A zone that has been ignored for months is usually missing more than you think.

That last point is where this goes from annoying to expensive: the zone you abandoned probably still holds your MX records. If mail stopped at the same time as the website changed, read what happens to email when nameservers move before you change anything else.

And resist the urge to delete the stale zone immediately. Keep it until the live one is confirmed working — it is the only copy of what your records used to say.