Skip to content
Rescue 404
Rescue

DNS and Domain Problems

ERR_NAME_NOT_RESOLVED

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

ERR_NAME_NOT_RESOLVED

ERR_NAME_NOT_RESOLVED means the browser asked DNS for your hostname and never got a usable IP—usually an expired domain, wrong or empty nameservers, a missing A/AAAA/CNAME, or a typo in the URL. Confirm registration and public DNS answers first; WordPress, SSL, and hosting panels cannot help until the name resolves.

Chromium browsers show ERR_NAME_NOT_RESOLVED when DNS lookup fails before any HTTP connection starts. The site never reaches your server, so plugin toggles and certificate renewals waste time. This guide separates registration failures, bad nameservers, missing records, and sticky local cache so you restore resolution in the right order.

Intermediate

Key facts

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

  • Cloudflare’s DNS troubleshooting docs cover failures where a hostname does not resolve because records or zone configuration are wrong or missing. (Cloudflare DNS troubleshooting)
  • ICANN Lookup is the official public tool to check registration status, registrar, and published nameservers before blaming hosting alone. (ICANN Lookup)
  • MDN defines DNS as the system that maps human-readable hostnames to the network addresses clients need before they can connect. (MDN DNS glossary)

What the error means

Name resolution is the first step of every visit: the client asks a recursive resolver for A/AAAA (or follows a CNAME chain) and only then opens TCP/TLS to an IP. ERR_NAME_NOT_RESOLVED is Chromium’s way of saying that step failed—no answer, NXDOMAIN, or a broken lookup path. Closely related Chrome text is DNS_PROBE_FINISHED_NXDOMAIN; other browsers may say the server IP could not be found. None of those messages mean PHP crashed or WordPress is offline—they mean the hostname never became an address. Typical roots are expired or held registration, NS still pointing at a cancelled DNS host, deleted apex/www records, a mistyped TLD, or OS/ISP cache still holding a failed answer after you already fixed the live zone.

Common symptoms

  • Chrome or Edge shows ERR_NAME_NOT_RESOLVED and no HTML loads
  • Phone cellular and office Wi‑Fi both fail on the same hostname
  • dig/nslookup against a public resolver returns NXDOMAIN or no A/AAAA
  • Temporary host URL or raw IP works, but the custom domain does not
  • www and apex disagree—one resolves, the other fails
  • Email on the same domain broke at the same time as the website
  • ICANN Lookup shows expired, clientHold, or unexpected nameservers

Most likely causes

  1. 01 Domain registration expired, suspended, or stuck in transfer/redemption
  2. 02 Nameservers left on a cancelled host or set to the wrong provider
  3. 03 Missing or deleted A/AAAA/CNAME for the hostname visitors type
  4. 04 Typo in the URL, wrong TLD, or a retired subdomain still advertised
  5. 05 Stale OS or ISP DNS cache after a recent zone fix
  6. 06 DNSSEC mismatch (broken DS) that validating resolvers treat as failure
  7. 07 Editing DNS in a panel that is not authoritative because NS point elsewhere

What changed before the problem started

  • Domain auto-renew failed or the registrar card expired
  • Nameservers moved during hosting migration or Cloudflare setup
  • Someone deleted or overwrote apex/www records while “cleaning” DNS
  • Domain transfer completed without rebuilding the zone at the new side
  • A marketing link or QR code still points at an abandoned hostname
  • Router, VPN, or custom DNS on the laptop started caching aggressively

Troubleshooting steps

  1. 01

    Confirm the exact hostname on another network

    Copy the full URL (www vs apex, TLD spelling). Retest on phone cellular or a second location. If every network fails the same way, treat it as registration/DNS—not a single PC glitch. Success signal: you know whether the failure is universal or device-local.

  2. 02

    Check registration status in ICANN Lookup

    Look up the domain at ICANN Lookup and note registrar, expiry, and status codes. Expired, pendingDelete, or clientHold must be fixed at the registrar before any hosting DNS edit matters. Success signal: status is active/ok and the listed NS match your intended DNS host.

  3. 03

    Verify nameservers match where you edit DNS

    Registrar NS fields must point at the provider whose zone editor you use (host DNS, Cloudflare, or registrar DNS). Changing A records in the wrong panel never updates public answers. Success signal: dig NS yourdomain.com matches the dashboard you are editing.

  4. 04

    Restore apex and www records at the authoritative host

    Publish A/AAAA (or ALIAS/ANAME where supported) for the apex and a matching A/AAAA or CNAME for www aimed at the current web/proxy IP. Remove stale duplicates. Success signal: dig against a public resolver returns the intended IP for both names you care about.

  5. 05

    Flush local DNS after the live zone looks correct

    On Windows run `ipconfig /flushdns`; on macOS flush the DNS cache with the current OS command. Retry in a private window. Avoid flipping nameservers again while waiting—each change resets the clock. Success signal: the same machine that failed now resolves like dig @1.1.1.1.

  6. 06

    Rule out typos and abandoned hostnames

    Compare email signatures, ads, and bookmarks to the registered domain. Retire or redirect old subdomains instead of leaving them NXDOMAIN. Success signal: every public link uses a hostname that has live records.

When to stop troubleshooting

Escalate if the registrar account is locked, the domain is in redemption or dispute, DNSSEC repair needs registry access you lack, or a vendor changed NS without documenting the new zone. Bring ICANN screenshots, current NS list, and dig output from two public resolvers plus the authoritative NS.

Information to collect before requesting help

  • 01 Exact hostname that shows ERR_NAME_NOT_RESOLVED
  • 02 Whether www, apex, and key subdomains behave differently
  • 03 ICANN Lookup status, expiry, and registrar name
  • 04 Nameserver hostnames currently published at the registrar
  • 05 dig/nslookup output from 1.1.1.1 or 8.8.8.8
  • 06 Recent renewals, transfers, or NS/A record edits
  • 07 Whether email failed at the same time as the website

How a professional repairs the problem

We confirm whether the failure is registration, nameservers, missing records, DNSSEC, or sticky cache. Then we restore a valid zone at the true authoritative host, verify public resolution, coordinate MX/TXT if NS moved, and only after the hostname resolves do we validate hosting document root and WordPress URLs.

Frequently asked questions

Is ERR_NAME_NOT_RESOLVED a WordPress error? +
No. The browser never reached WordPress or PHP. Fix domain registration and DNS first; admin, plugins, and themes are irrelevant until the name resolves to an IP.
How is this different from DNS_PROBE_FINISHED_NXDOMAIN? +
Both mean DNS did not give a usable answer. NXDOMAIN is the explicit “name does not exist” answer; ERR_NAME_NOT_RESOLVED is Chromium’s broader “could not resolve” label. The repair order—registration, NS, records—is the same class of work.
Why does dig work but Chrome still fails? +
Often local or browser DNS cache, or Chrome still querying a resolver that has not expired the old failure. Flush OS DNS, try a private window, and compare dig @1.1.1.1 to your machine’s default resolver.
Can a typo cause this exact message? +
Yes. A wrong TLD or misspelled host returns the same Chromium error as an expired domain. Verify the registered spelling before changing production DNS.
Will renewing SSL or changing PHP fix it? +
No. Certificates and PHP run after DNS succeeds. Spend effort on registrar status, nameservers, and A/AAAA records.
How long after fixing DNS should the error clear? +
Often minutes with low TTLs; stubborn ISP caches can take up to the previous TTL (commonly hours, sometimes toward a day or two). Public resolvers usually catch up sooner than residential ISPs.

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.