Website Not Resolving? Fix DNS_PROBE_FINISHED_NXDOMAIN and Common DNS Errors Step‑by‑Step

Seeing DNS_PROBE_FINISHED_NXDOMAIN or another DNS error when you try to open a website can be confusing and frustrating. The site loads fine for some people, fails for others, or disappears just after you change hosting or move a domain. As a hosting team at dchost.com, we run into these situations every week during migrations, DNS clean‑ups, and security reviews. The good news: most DNS problems follow a few predictable patterns, and you can usually pinpoint the cause in a structured way.

This guide walks you through a practical, step‑by‑step checklist to fix DNS_PROBE_FINISHED_NXDOMAIN and other common DNS errors. We will start with quick checks on your own device and network, then move gradually towards your domain, nameservers, and DNS zone records. Along the way, we will explain key DNS concepts in simple terms and share the same debugging flow we use when helping our own hosting customers. Keep this page open, follow the steps in order, and you will either fix the issue yourself or at least know exactly what to ask your provider to change.

What DNS_PROBE_FINISHED_NXDOMAIN Actually Means

Before trying to fix the error, it helps to understand what it is telling you. Browsers and operating systems use DNS (Domain Name System) to convert a domain name like example.com into an IP address such as 203.0.113.10. When something goes wrong in that lookup, you see errors like:

• DNS_PROBE_FINISHED_NXDOMAIN (Chrome, Edge)
• ERR_NAME_NOT_RESOLVED (Chrome)
• DNS address could not be found (various browsers)

NXDOMAIN literally means “Non‑existent domain”. In plain language, the DNS resolver you are using tried to find DNS records for your domain and concluded that the domain does not exist in DNS. That can happen for several reasons:

• Your domain name is misspelled.
• The domain has expired or is not registered anywhere.
• Your nameservers are wrong or not reachable.
• Your DNS zone has no A/AAAA record for the hostname you are trying to open.
• There is a DNSSEC or glue record misconfiguration.

The same domain can work for one person and fail for another because DNS answers are cached at multiple levels (your browser, operating system, router, ISP, and public resolvers). So the first step is to check whether the problem is local to you or global.

Step 1: Quick Checks Before You Touch DNS

1. Check for typos and the exact hostname

It sounds trivial, but we regularly see tickets where the entire problem is a typo or the wrong hostname. Double‑check:

• Spelling of the domain (for example, mydoman.com vs mydomain.com).
• Whether you are using www.example.com or just example.com.
• Whether you added an extra subdomain like app.example.com that never had DNS records.

If only www.example.com works but example.com does not (or vice versa), this is almost always a DNS record issue that we will cover later.

2. Confirm whether the problem is just on your side

To avoid unnecessary DNS changes, first verify if others can reach the domain:

• Try on a different device using a different network (for example, mobile data instead of office Wi‑Fi).
• Use a public DNS lookup tool from multiple locations to see if the domain resolves.

If the site loads from another network but not from your current one, the problem is probably local DNS caching, your router, or a corporate/ISP DNS issue. If nobody can resolve it from anywhere, it is almost certainly a domain, nameserver, or DNS zone configuration problem.

3. Clear browser cache and local DNS cache

Modern browsers and operating systems keep their own DNS cache. A stale or corrupted entry there can cause DNS_PROBE_FINISHED_NXDOMAIN even after you fix the real problem at the DNS level.

Steps you can try:

• Close and reopen the browser, then try again in a private/incognito window.
• Try another browser (Chrome vs Firefox vs Edge) to see if the error persists.

Then clear your OS DNS cache:

• Windows: Open Command Prompt as Administrator and run:
  ipconfig /flushdns
• macOS (recent versions): Open Terminal and run:
  sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd‑resolved):
  sudo systemd-resolve --flush-caches

If flushing the DNS cache fixes the issue for you while others never had a problem, you were dealing with a local caching glitch, not a DNS zone problem.

Step 2: Check Your Local Network, Router and DNS Resolver

1. Restart your modem/router

Consumer routers often run their own small DNS forwarder and cache. If it misbehaves, you can see DNS_PROBE_FINISHED_NXDOMAIN even if the external DNS is fine. A simple restart often fixes this:

• Power off the modem/router.
• Wait 20–30 seconds.
• Power it on and wait until the connection is stable, then test the site again.

2. Try a different DNS resolver on your device

If your ISP’s DNS resolver is slow, overloaded, or misconfigured, it may respond with NXDOMAIN or timeouts for domains that resolve perfectly elsewhere. You can temporarily change your DNS resolver to a known public resolver on your device:

• On your computer or phone, set the DNS servers manually to a reliable public service such as 1.1.1.1 / 1.0.0.1 (operated by Cloudflare) or 9.9.9.9 (Quad9).
• Reconnect to the network and try your website again.

If the problem disappears when using another resolver, the issue is probably with your ISP’s DNS or a corporate DNS policy, not with your domain configuration.

3. Check VPN, firewall, and hosts file

In office environments and on developer machines, we often find local overrides that cause NXDOMAIN or send traffic to the wrong server:

• VPN: Disconnect from VPN and test again. Some VPNs route DNS through the corporate resolver, which may not know public domains or may block certain zones.
• Firewall/endpoint security: Security software can block certain DNS queries or domains. Temporarily disable it (if safe and permitted) or whitelist the domain.
• hosts file override: Check your system’s hosts file for manual entries for your domain. On Windows it is at C:WindowsSystem32driversetchosts, on Linux/macOS at /etc/hosts. A wrong IP there overrides DNS.

If none of this helps, it is time to move on to domain, nameserver, and DNS zone checks.

Step 3: Verify domain registration and Nameservers

1. Make sure the domain is registered and not expired

It sounds obvious, but an expired domain is the root cause behind many DNS_PROBE_FINISHED_NXDOMAIN cases we see. When a domain expires, its DNS often stops working before the domain is fully deleted, which leads to intermittent resolution failures.

Use a WHOIS lookup to check:

• Whether the domain is actually registered.
• Its expiry date and current status (OK, clientHold, redemption, etc.).

If you want a deeper understanding of what happens after expiry, you can read our article about the domain lifecycle, grace periods and expired domain backorders. In short: if the domain is expired or in redemption, renew it with your registrar first. DNS troubleshooting will not help until the domain is active again.

2. Confirm nameservers are set correctly

Every domain must point to one or more nameservers, which hold the DNS records. If the nameserver information is missing, wrong, or inconsistent, resolvers may return NXDOMAIN or SERVFAIL.

Check via WHOIS and a DNS lookup:

• Which nameservers are configured at the registry level (for example, ns1.yourhost.com, ns2.yourhost.com).
• Whether those nameservers are actually reachable and authoritative for your domain.

Common mistakes that lead to DNS_PROBE_FINISHED_NXDOMAIN:

• You changed the nameservers but the new DNS provider does not yet have a zone for your domain.
• You mistyped the nameserver hostname at the registrar.
• You use private nameservers on your own domain (like ns1.example.com) but did not set up glue records.

If you plan to use your own branded nameservers, our guide to private nameservers and glue records explains how to register them correctly at the registrar and point them to your DNS server’s IP addresses.

3. Understand propagation and TTL

After changing nameservers or DNS records, caches across the internet need time to refresh. This delay is controlled by the TTL (Time To Live) value on your records. During that period, some users may still see the old DNS answers or even NXDOMAIN while others get the new ones.

For critical migrations, we recommend planning TTLs ahead of time, lowering them before the move, and then raising them again afterwards. For a deeper, migration‑oriented explanation, see our article on TTL strategies for zero‑downtime DNS changes.

Step 4: Inspect and Fix Your DNS Zone Records

If your domain is registered, active, and pointing to the correct nameservers, the next layer to inspect is the DNS zone itself. This is where most practical NXDOMAIN issues live.

1. Make sure the main A/AAAA record exists

For a basic website, you normally need at least:

• An A record for example.com pointing to your server’s IPv4 address.
• Optionally an AAAA record for the IPv6 address, if your server supports IPv6.
• Either an A/AAAA record for www.example.com or a CNAME that points www to example.com.

If you only have a record for www.example.com but not for the root domain, trying to open https://example.com may lead to NXDOMAIN on some resolvers. The reverse is also common: example.com works, but www.example.com returns NXDOMAIN because there is no record for www.

If you want a friendly and complete overview of record types (A, AAAA, CNAME, MX, TXT, etc.), you can read our guide “DNS records explained like a friend”. It also covers small mistakes that frequently cause lookup failures.

2. Watch out for CNAME loops and apex CNAME issues

A CNAME record says “this name is an alias of that name, ask there for the real IP”. Two common problems:

• CNAME loop: www.example.com CNAME → app.example.com, and app.example.com CNAME → www.example.com. Resolvers cannot find a final A/AAAA record and may end up returning an error.
• CNAME at the zone apex: Many traditional DNS setups do not allow a CNAME for the bare domain example.com because it must also hold NS and SOA records. Some providers emulate this with ALIAS/ANAME or CNAME flattening.

If you want to understand why putting a CNAME at the root of your domain can be tricky, our article on CNAME at the apex and ALIAS/ANAME records explains the scenarios and safer alternatives.

3. Check for DNSSEC misconfiguration

DNSSEC adds a layer of cryptographic validation to DNS, making it harder for attackers to spoof responses. However, if keys or DS records are misconfigured, resolvers may start responding with SERVFAIL or appear as NXDOMAIN to end users, even though the zone itself looks correct.

If you recently enabled or changed DNSSEC:

• Verify that the DS record at your registrar matches the DNSSEC keys on your authoritative DNS servers.
• Regenerate and replace DS records carefully when rotating keys.
• Temporarily disable DNSSEC if you suspect a broken setup and need a quick fix.

For background on how DNSSEC works and how it protects your domain, see our article on what DNSSEC is and how it makes your website more secure.

4. Make sure your DNS zone exists on all nameservers

If you are using multiple authoritative nameservers (which you should for redundancy), all of them must have a consistent copy of the zone. NXDOMAIN or SERVFAIL can appear when:

• One nameserver has the zone but another does not.
• Zone transfers (AXFR/IXFR) between primary and secondary are not working.
• You changed the zone on one DNS panel but forgot about the other provider.

Some organizations mix hosting‑provider DNS with a third‑party DNS service. If you are in that situation, it is worth reading our piece on Cloudflare DNS vs hosting DNS and how to choose a nameserver strategy. The key idea: pick one place as the true source of DNS records and keep others in sync methodically.

Step 5: Understanding Other Common DNS Errors

While DNS_PROBE_FINISHED_NXDOMAIN is very common in browsers, you may also encounter other DNS errors when testing your domain with diagnostic tools. Understanding the difference helps you troubleshoot faster.

1. SERVFAIL

SERVFAIL means the resolver tried to get an answer but ran into a problem on the way — for example, it could not reach an authoritative nameserver, DNSSEC validation failed, or there was an internal error in the resolver. Typical causes include:

• Unreachable or misconfigured authoritative nameservers.
• Broken DNSSEC signatures or mismatched DS records.
• Too many chained CNAMEs or indirection loops.

If you see SERVFAIL in public tools while NXDOMAIN appears in the browser, focus on nameserver reachability, DNSSEC, and potential CNAME loops.

2. REFUSED

REFUSED tells you that the DNS server was reached but refused to answer, typically due to configuration or access policy:

• The DNS server is configured as “recursion only” and will not serve authoritative data to the public.
• Queries from your IP or network are blocked.
• A firewall or DNS firewall product is actively filtering.

If the authoritative server is under your control, check its ACLs and query‑policy configuration. If it is managed by your DNS or hosting provider, open a ticket with them including the exact error output.

3. Query timed out

A timeout means the resolver sent a query but did not receive a response within the expected time window. This is usually a connectivity problem, not a data problem:

• Firewall blocking UDP/TCP on port 53.
• Nameserver down, overloaded, or rate‑limiting.
• Anycast or load‑balancing issues in front of the DNS servers.

In such cases, check if your nameserver IPs respond to ping and DNS queries from multiple locations. At dchost.com, we use redundant DNS infrastructure and monitor latency so that our customers’ zones respond consistently across regions.

4. DNS_PROBE_FINISHED_BAD_CONFIG and similar browser errors

Browsers may also show messages like DNS_PROBE_FINISHED_BAD_CONFIG. While the naming differs between browsers, these often indicate:

• Local resolver misconfiguration (for example, invalid DNS server IP in your network settings).
• Broken or inconsistent entries in your OS resolver cache.
• Router DNS issues or captive portals on public Wi‑Fi.

The steps from earlier — flushing DNS cache, changing resolver, and restarting your router — are usually effective in resolving these.

Step 6: Preventing Future DNS Headaches

Once your site is resolving again, it is worth spending a bit of time to make sure you do not repeat the same painful DNS incident during your next migration or domain change.

1. Use clear DNS documentation and a single source of truth

DNS problems often arise when different people edit records in different control panels without a shared plan. We strongly recommend:

• Keeping a simple internal document that lists your domains, nameservers, and critical records (A/AAAA, MX, TXT for SPF/DKIM/DMARC, etc.).
• Choosing one DNS provider as the “source of truth” and avoiding ad‑hoc edits on secondary systems.
• Reviewing DNS whenever you move hosting, email, or CDNs to avoid leftover or conflicting records.

2. Plan DNS changes with smart TTLs

If you are preparing a migration — for example moving from one hosting environment to another — DNS is a key part of your cut‑over plan. Lower TTLs ahead of time so changes propagate quickly, then increase them again to reduce load and improve caching afterwards. Our detailed guide on TTL strategies for zero‑downtime migrations shows how we approach this in real projects.

3. Choose a robust DNS setup aligned with your hosting

Whether you run a single business site or a multi‑tenant SaaS, DNS should match your hosting architecture. Some setups rely on your hosting provider’s DNS, others use a specialized DNS platform, and some use a hybrid. Our article on Cloudflare DNS vs hosting DNS and nameserver strategy discusses trade‑offs like latency, advanced features, and operational simplicity.

At dchost.com we provide DNS management integrated with our shared hosting, VPS, dedicated servers and colocation services, so you can keep domains, DNS and servers under one roof and reduce the chance of configuration drift.

4. Protect your domain and DNS against hijacking

DNS errors are sometimes a symptom of security issues rather than simple misconfigurations. Protect your domain by:

• Enabling registrar lock and two‑factor authentication on your domain account.
• Restricting who can edit DNS and using role‑based access.
• Considering DNSSEC once you are comfortable managing DNS, to prevent spoofing.

For a broader view on keeping your domains safe, check our guide to domain security best practices including registrar lock, DNSSEC and 2FA.

When to Ask for Help (And What to Send)

Sometimes you can follow all the steps above and still feel stuck, especially with complex DNS setups, multi‑provider email, or aggressive security policies. At that point, contacting support is the right move — but the quality of information you send matters a lot.

Prepare the following details before opening a ticket with your DNS or hosting provider (including us at dchost.com):

• The exact domain and subdomain that is failing.
• A screenshot or copy of the browser error (DNS_PROBE_FINISHED_NXDOMAIN, ERR_NAME_NOT_RESOLVED, etc.).
• Results from at least one external DNS lookup tool for that hostname.
• A note on recent changes: new hosting, nameserver change, new SSL, DNSSEC enablement, or email provider switch.
• Whether the issue appears on multiple devices and networks.

With this information, support teams can quickly trace the problem to the correct layer — local cache, domain, nameserver, DNS zone, or network — and propose a precise fix instead of guessing.

Wrapping Up: DNS Errors Don’t Have to Be Mysterious

DNS_PROBE_FINISHED_NXDOMAIN and related DNS errors look intimidating on the surface, but they almost always come down to a handful of root causes: a missing or expired domain, wrong nameservers, missing A/AAAA/CNAME records, or caching issues between your browser and the authoritative DNS server. By working layer by layer — starting with typos and local DNS cache, then moving through router, resolver, domain registration, nameservers and finally the DNS zone — you can methodically narrow down where the problem lives.

As the dchost.com team, we follow the same structured playbook when we migrate websites, consolidate domains, or clean up legacy DNS after years of quick fixes. If you prefer not to wrestle with NS, A, AAAA, CNAME and DNSSEC on your own, you can host your sites, VPS, dedicated servers or colocated hardware with us and lean on our experience when you need it. Combine this article with our deep dives on DNS record types and common pitfalls and TTL strategies for zero‑downtime DNS changes, and you will be well‑equipped to keep your websites resolving reliably — without waiting for the next DNS error to surprise you.