Skip to content
Rescue 404
Rescue

DNS and Domain Problems

Domain nameservers incorrect

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

Incorrect nameservers mean the registrar still publishes NS that point at the wrong DNS host—so the A/AAAA edits you make elsewhere never go live. Set registrar NS to the provider that holds your real zone (and recreate records there first), then wait for NS TTL before chasing WordPress or SSL.

After a host move or Cloudflare signup, teams often edit DNS in one dashboard while the registry still lists old NS. Visitors keep resolving against the abandoned zone. This guide shows how to prove which nameservers are authoritative, align registrar NS with the correct provider, and avoid breaking email during the cutover.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • Cloudflare documents that using its DNS as the authoritative provider requires pointing the domain’s nameservers at the nameservers shown in the Cloudflare account. (Cloudflare update nameservers)
  • ICANN Lookup shows the nameservers currently associated with a registered domain at the registry level. (ICANN Lookup)
  • MDN defines DNS as the naming system clients use to find network addresses for hostnames before connecting. (MDN DNS glossary)

What the error means

Nameservers (NS) are the registry’s pointer to “who answers DNS for this domain.” Recursive resolvers follow those NS hostnames to fetch A/AAAA, MX, and TXT. If the registrar still lists Host A’s NS while you only update records at Host B, the public internet never sees Host B’s zone. Symptoms look like ERR_NAME_NOT_RESOLVED, NXDOMAIN, an old site, or parking—depending on what the wrong NS still publish. Fixing “A records” in a non-authoritative panel feels productive but changes nothing for visitors. Correct NS is a registrar-level setting; the zone content lives at whichever DNS host those NS name.

Common symptoms

  • DNS edits in the new host panel never appear in dig against 1.1.1.1 or 8.8.8.8
  • ICANN Lookup or dig NS lists nameservers that do not match your current DNS dashboard
  • Site still shows the old host, parking page, or ERR_NAME_NOT_RESOLVED after a migration
  • Cloudflare (or similar) is configured but registrar NS were never switched
  • www/apex answers differ from what the “new” zone file contains
  • Email broke or stayed on old MX because only partial records were copied before NS change
  • Support told you DNS is updated, but authoritative dig still hits the previous provider

Most likely causes

  1. 01 Registrar NS left on the previous host after files moved
  2. 02 New DNS provider onboarded without completing the NS change at the registrar
  3. 03 Typo or incomplete NS hostname list (missing one of four required servers)
  4. 04 Custom nameservers with wrong or missing registrar glue
  5. 05 Domain transfer completed and reset NS to registrar defaults
  6. 06 Someone edited the wrong registrar account or a secondary domain by mistake
  7. 07 DNSSEC/DS still tied to the old provider after NS moved

What changed before the problem started

  • Hosting migration or “move DNS to Cloudflare” project started
  • Domain transferred between registrars
  • Temporary NS values from a welcome email were never applied
  • Agency or previous developer retained DNS at their account after site files moved
  • Registrar “reset DNS” or “use our nameservers” button was clicked
  • Custom vanity NS hostnames changed IP without updating glue

Troubleshooting steps

  1. 01

    List the nameservers the registry actually publishes

    Use ICANN Lookup and `dig NS yourdomain.com` (or your OS equivalent). Write down the exact NS hostnames. Success signal: you have the live NS list, not just what a sales email said you should use.

  2. 02

    Confirm which panel is authoritative today

    Log into the DNS host those NS belong to and compare zone contents to what you expected. If you have been editing a different panel, stop—those edits are invisible. Success signal: the dashboard matches the NS brand/hostnames from dig.

  3. 03

    Build the full zone at the destination before switching NS

    At the intended DNS provider, create A/AAAA (or proxied equivalents), www, MX, and critical TXT (SPF/DKIM/verification) to match production needs. Success signal: the new zone is complete even though traffic still hits the old NS.

  4. 04

    Update registrar nameservers to the destination set

    In the registrar domain settings, replace NS with the exact hostnames the new provider documents—no extras, no omissions. Save and re-check dig NS over the next minutes/hours. Success signal: public dig NS matches the new provider.

  5. 05

    Verify A/AAAA from public resolvers after NS updates

    Once NS flipped, query 1.1.1.1 and 8.8.8.8 for apex and www. Allow prior NS TTL to expire on stubborn networks. Success signal: public answers match the new zone’s intended IPs or proxy addresses.

  6. 06

    Only then test the site and mail

    Open the site and send a test message if MX moved. Fix WordPress URLs or SSL only after DNS answers are correct. Success signal: hostname resolves to the new host and mail still flows if it should.

When to stop troubleshooting

Stop DIY NS flips if the domain is locked/transferring, you lack registrar access, glue/DNSSEC changes are unclear, or live email depends on records you cannot export. Hand off with ICANN NS screenshots, dig NS/A output, and a zone export rather than alternating providers every hour.

Information to collect before requesting help

  • 01 Registrar name and whether you can edit nameservers
  • 02 Current dig NS / ICANN nameserver list
  • 03 Intended DNS provider and its required NS hostnames
  • 04 Whether the destination zone already has A/AAAA, MX, and TXT
  • 05 When NS were last changed and previous TTL if known
  • 06 Whether email must stay up during the cutover
  • 07 DNSSEC enabled yes/no and who manages DS records

How a professional repairs the problem

We prove which NS the registry publishes, rebuild a complete zone at the destination (web plus mail records), switch registrar NS once, validate public resolution, and clean up DNSSEC/glue so validating resolvers and vanity NS keep working. WordPress and SSL checks come after the name reliably answers from the new host.

Frequently asked questions

Why did my new host say DNS is set but nothing changed? +
They configured a zone inside their panel, but the registrar may still publish someone else’s NS. Public resolvers only follow the registry NS list—fix that, not just the hosting DNS UI.
How long does a nameserver change take? +
Authoritative updates can appear within minutes, but resolvers may cache old NS for the previous TTL—often up to 24–48 hours in stubborn cases. Authoritative dig shows the truth sooner than home ISP caches.
Can incorrect NS cause ERR_NAME_NOT_RESOLVED? +
Yes. If the listed NS are dead, empty, or serve no zone for your name, browsers never get an IP and Chromium shows ERR_NAME_NOT_RESOLVED or NXDOMAIN.
Should I change NS and A records at the same time everywhere? +
No. Pick one authoritative DNS host, build the full zone there, then change registrar NS to that host only. Editing two providers in parallel guarantees confusion.
Will changing nameservers break email? +
It can, if MX/TXT are missing at the destination. Copy mail records before the NS cutover or keep DNS at the provider that already holds working MX until you are ready.
What is the difference between NS and A records? +
NS says which servers are allowed to answer DNS for the domain. A/AAAA say which IP the website hostname maps to inside that zone. Wrong NS means your A edits never go live.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.