Skip to content
Website Rescue Rescue

DNS and Domain Problems

Domain Not Resolving

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

Browsers cannot turn your domain into an IP address because nameservers, A/AAAA records, or registration data are wrong or still propagating. Check ICANN Lookup for expiration and NS, verify A/AAAA (and www) at the authoritative DNS host, wait out TTL/propagation, and fix registrar glue—do not rebuild WordPress until DNS answers correctly.

A domain that will not resolve shows ERR_NAME_NOT_RESOLVED or similar before WordPress ever runs. This guide covers NS records, A/AAAA addresses, propagation delay, expired domains, and wrong registrar glue so you restore DNS first, then confirm the site loads at the correct host.

Intermediate

What the error means

DNS resolution walks from the domain’s registered nameservers (NS) to the zone that holds A (IPv4) and AAAA (IPv6) records for the apex and www. If the domain is expired, NS points at the wrong provider, glue at the registrar is stale, or A/AAAA still points at an old server, recursive resolvers return NXDOMAIN, SERVFAIL, or the wrong IP. Propagation is really resolver cache and TTL: some networks see the new answer sooner than others. WordPress, SSL, and hosting panels cannot fix a name that never resolves—fix the registry and DNS zone first.

Common symptoms

  • Browser shows ERR_NAME_NOT_RESOLVED, DNS_PROBE_FINISHED_NXDOMAIN, or “server IP address could not be found”
  • Site works by raw IP or temporary host URL but not by the custom domain
  • dig/nslookup returns NXDOMAIN, no A/AAAA answer, or an unexpected IP
  • www works but the apex (or the reverse) does not
  • Some networks or phones resolve the domain while others still fail hours after a DNS change
  • Email or other services on the same domain also fail after a nameserver move
  • ICANN Lookup shows clientHold, redemption, expired status, or unexpected nameservers

Most likely causes

  1. 01 Domain registration expired or in redemption / clientHold status
  2. 02 Nameservers (NS) still pointing at a previous DNS host after a migration
  3. 03 Missing or incorrect A/AAAA records for @ and www
  4. 04 Wrong or missing registrar glue records for custom nameservers
  5. 05 TTL and resolver cache still serving old NXDOMAIN or old IP answers
  6. 06 Typo in the hostname, wrong zone edited, or DNS changed at Cloudflare while NS still at the registrar’s default
  7. 07 IPv6-only (AAAA) misconfiguration when the client prefers IPv6 and AAAA is wrong

What changed before the problem started

  • Domain transferred, renewed late, or registrar account changed
  • Nameservers updated to Cloudflare, host DNS, or custom NS
  • Hosting migration that required a new A/AAAA IP
  • DNS records edited or deleted in the zone dashboard
  • Glue records updated (or not) after changing custom nameserver hostnames

Troubleshooting steps

  1. 01

    Confirm registration status in ICANN Lookup

    Look up the domain at lookup.icann.org. Note expiration date, status codes, and the listed nameservers. If the domain is expired, redempted, or on clientHold, renew or resolve the hold with the registrar before changing hosting or WordPress. Success signal: status is active/ok and NS match the DNS host you intend to use.

  2. 02

    Verify NS at the registrar matches your DNS host

    In the registrar panel, confirm NS records point to Cloudflare, your host, or your custom nameservers—exactly as that provider documents. Editing A records at Host A while NS still point at Host B has no effect on public resolution. Success signal: dig NS yourdomain.com matches the provider where you edit the zone.

  3. 03

    Check A and AAAA for apex and www

    In the authoritative DNS dashboard, ensure @ (apex) has an A (and AAAA if you use IPv6) pointing at the current web server or proxy IP, and www is either an A/AAAA or a CNAME as your host requires. Remove stale records pointing at old servers. Success signal: dig @authoritative-ns yourdomain.com A returns the expected IP.

  4. 04

    Test with public resolvers and authoritative dig

    Query 1.1.1.1 and 8.8.8.8 as well as the authoritative nameserver directly. Authoritative answers bypass local cache and show whether the zone is correct even if your ISP still serves old data. Success signal: authoritative dig is correct; public resolvers match within the record TTL window.

  5. 05

    Allow TTL/propagation time after corrections

    After fixing NS or A/AAAA, wait at least the previous TTL (often minutes to 48 hours in worst cases) before declaring failure. Flush local OS DNS cache if you must retest from the same machine. Success signal: multiple networks and phones resolve to the same correct IP.

  6. 06

    Only then verify the site and SSL on the resolved IP

    Once DNS resolves, open the site and confirm you hit the intended host. Fix SSL or WordPress URL issues separately if the name resolves but HTTPS or content fails. Success signal: domain resolves and the correct origin responds; remaining errors are application/SSL, not DNS.

When to stop troubleshooting

Stop DIY DNS edits if the domain is locked in a transfer or dispute, you lack registrar access, glue changes are unclear, DNSSEC SERVFAILs persist after careful checks, or business email is at risk from partial zone edits. Hand off with ICANN Lookup screenshots, dig output, intended NS provider, and the target hosting IP rather than repeatedly flipping NS on a live brand.

Information to collect before requesting help

  • 01 Exact browser or dig error (NXDOMAIN, SERVFAIL, wrong IP)
  • 02 ICANN Lookup status, expiration, and listed nameservers
  • 03 Where you edit DNS (Cloudflare, registrar, host) vs where NS actually point
  • 04 Current A/AAAA values for @ and www and the intended hosting IP
  • 05 When NS or A records were last changed and previous TTL if known
  • 06 Whether the site loads via temporary host URL or raw IP
  • 07 Whether email on the same domain is also affected

How a professional repairs the problem

We verify registration and NS at the registry, confirm the authoritative zone’s A/AAAA and glue, correct mismatches without orphaning MX/TXT records, and validate resolution from authoritative and public resolvers. After the name reliably points at the right host, we confirm HTTP/HTTPS and WordPress URLs, then document the DNS provider of record so the next migration does not edit the wrong panel.

Frequently asked questions

How long does DNS propagation take? +
Often minutes when TTL is low, but resolvers may cache old answers for the previous TTL—commonly up to 24–48 hours in stubborn cases. Authoritative dig shows the truth sooner than your home ISP.
Why does dig look fine but my phone still fails? +
Mobile carriers cache aggressively. Wait for TTL expiry, try another network or DNS (1.1.1.1 / 8.8.8.8), and confirm you did not mistype the hostname.
Is this a WordPress problem? +
Not until the domain resolves to your server. ERR_NAME_NOT_RESOLVED means DNS failed before WordPress or PHP ran. Fix NS and A/AAAA first.
What is registrar glue? +
Glue is A/AAAA data the registrar publishes for nameserver hostnames inside your own domain. Without correct glue, resolvers cannot find your NS IPs and the whole zone fails intermittently or completely.
Can an expired domain cause this? +
Yes. Expired or hold statuses stop normal resolution even if your hosting account is paid. Renew at the registrar and wait for status to clear before debugging A records.
Should I lower TTL before a planned move? +
Yes. Lower TTL a day before changing NS or A records so the cutover propagates faster, then raise TTL again after the new answers are stable.

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.

Written by Website Rescue

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.