How to Fix DNS_PROBE_FINISHED_NXDOMAIN Error

What Does DNS_PROBE_FINISHED_NXDOMAIN Mean?

DNS_PROBE_FINISHED_NXDOMAIN means the resolver was told that the requested DNS name does not exist. That is different from a web server returning an error: the browser may never have obtained an IP address, so the request did not reach Apache, nginx, PHP, or your application.

Check the spelling first. Then inspect the domain’s A, AAAA, and NS records, nameserver delegation, registration status, and local resolver settings. The web server may be perfectly healthy while DNS is pointing nowhere.

I treat this as a DNS-layer problem before touching the server. Restarting nginx cannot create a missing DNS record (I have seen that diagnosis suggested more than once).

Why Does DNS_PROBE_FINISHED_NXDOMAIN Happen?

DNS maps names to information such as IP addresses. An A record can return an IPv4 address for example.com, while an AAAA record can return an IPv6 address. If a resolver receives an authoritative response saying that the requested name does not exist, it can return NXDOMAIN.

A timeout or an authoritative server failure is not the same thing. Those cases may produce SERVFAIL or a timeout instead. The browser’s message is useful, but it is not a complete incident report.

ICANN separates domain registration, DNS records, and DNS hosting in its explanation of the domain name system. You can register a domain with one company and host its DNS zone with another. That flexibility is useful, but it also makes an incorrect nameserver delegation surprisingly easy to miss.

• Typo: The domain may contain a missing letter, an extra letter, or the wrong extension.
• Missing DNS record: A newly created subdomain may not have an A or CNAME record.
• Wrong nameserver: The domain may be delegated to nameservers that do not contain the records you edited.
• Expired domain: An unrenewed domain can be suspended, and its DNS response can change.
• Local cache: Your computer, router, or recursive resolver may still have an earlier negative answer cached.
• DNSSEC mismatch: An inconsistent delegation or stale DS record can make validating resolvers reject the zone. Browsers do not always display this as a clear DNSSEC error.

How Can You Tell Whether the Problem Is the Domain or Your Computer?

I start in a terminal rather than in the browser. A browser may use its own cache, the operating system resolver, and sometimes DNS-over-HTTPS at the same time. A terminal query makes it easier to see which resolver answered and what it returned.

dig +short A example.com
dig +short AAAA example.com
dig +short NS example.com

dig +short prints only the short answer. If the first two commands return no address, we have not reached the web server yet. The NS query shows which authoritative DNS servers are responsible for the domain. Replace example.com with your own domain.

For a more detailed response, run:

dig example.com A
dig example.com NS
dig example.com +trace

+trace follows the delegation path from the root DNS servers down to the domain’s authoritative servers. If the final part of the output does not contain a useful answer from those servers, I inspect the DNS panel and nameserver delegation next.

Comparing different recursive resolvers is useful too:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @9.9.9.9 example.com A

If one command returns an IP address while another returns NXDOMAIN, investigate resolver-specific caching or split DNS. If all of them return NXDOMAIN, I treat the record as genuinely missing until the authoritative server proves otherwise. This comparison has saved me from several unnecessary modem reboots.

Basic Checks on Windows, macOS, and Linux

On Windows, inspect and clear the DNS cache with:

ipconfig /displaydns
ipconfig /flushdns
nslookup example.com

ipconfig /flushdns clears the local DNS cache. It does not change the record in your DNS control panel; it only removes answers stored on that computer.

On Linux, the command depends on the resolver service in use. If systemd-resolved is active:

resolvectl status
resolvectl query example.com
sudo resolvectl flush-caches

I look at resolvectl status first. There is little point in flushing a cache without knowing which DNS servers the system is actually using. Some of my Debian servers do not run systemd-resolved at all, so an ineffective command there is normal.

On macOS, check the configured resolvers and query the domain like this:

scutil --dns
dig example.com A

scutil --dns shows the DNS resolvers configured on the system. If the addresses point to an unexpected VPN, security product, or local network device, test from another connection before changing anything permanently.

How Do You Check DNS Records and Nameserver Settings?

A common cause of DNS_PROBE_FINISHED_NXDOMAIN is adding a record in one panel while the domain uses nameservers belonging to another provider. The record may be correct, but public queries never reach the DNS service where you created it.

Start by finding the authoritative nameservers:

dig +short NS example.com

Do those servers belong to the provider where you edited the DNS records? If the panel shows the record but the query returns a different provider’s nameservers, changes made in the first panel will not affect public DNS.

Check A, AAAA, and CNAME Records

For a subdomain, these queries are a useful starting point:

dig +short A app.example.com
dig +short CNAME app.example.com
dig +short NS example.com

If a name has an unexpected CNAME as well as an A record, check the provider’s rules for conflicting records. DNS does not permit a CNAME to coexist with other data at the same name, even if a control panel makes the configuration look acceptable.

The distinction between the root domain and a subdomain is also covered in What Is a Subdomain? Uses, Setup, and Best Practices. www.example.com and app.example.com are separate names, so one working does not prove that the other is configured correctly.

Could the Domain Registration or Delegation Be the Problem?

If the domain has expired or the registrar is waiting for required verification, correcting a DNS record alone may not be enough. Check the domain’s status, nameserver list, renewal notices, and any registrar-side hold.

A recent registrar or DNS provider transfer can also leave delegation in transition. I try not to use “DNS propagation takes 24 hours” as an automatic answer. The actual delay depends on TTL values, resolver caches, and whether the delegation was changed at all. Waiting does not repair an incorrect nameserver; it only preserves the wrong setting for longer.

How Do DNS Caches and TTL Affect the Error?

DNS responses remain cached for a period determined by their TTL. After you change a record, not every resolver will obtain the new answer at the same moment. Positive responses can be cached, and under the rules described by RFC 2308, negative responses can be cached as well.

RFC 8020 also describes how an NXDOMAIN response can apply to names beneath a domain that does not exist. In practical terms, a record added a minute ago may still look absent from your computer because an earlier “this name does not exist” response is still cached.

To inspect the TTL, run:

dig example.com A

Look at the number in the ANSWER SECTION. It is the remaining cache lifetime in seconds. A low TTL does not guarantee an instant change, because different resolvers may already hold older positive or negative answers.

What If the Domain Works Elsewhere but the Browser Still Shows the Error?

If the domain opens on another network, the likely cause is local DNS, a router, a VPN, or a resolver-specific cache. I work through these checks:

1. Test the domain on another device, preferably over mobile data.
2. Temporarily bypass a VPN, private DNS setting, or corporate security product.
3. Clear the local DNS cache.
4. Check the router’s DNS forwarding, or test briefly with another trusted resolver.
5. Compare the output from dig, nslookup, or resolvectl.

A browser’s “use secure DNS” setting can change where queries go. Turning it off is not a permanent fix, but it can help separate the operating system’s resolver from the browser’s DNS-over-HTTPS resolver.

If you changed DNS for a VPS, query from the server itself as well. A server being reachable from the outside does not mean it is using the resolver you expect:

cat /etc/resolv.conf
getent ahosts example.com
curl -I https://example.com

getent ahosts tests the resolution path used by applications on the system. curl -I moves on to HTTP after DNS succeeds. If the first command fails, it is too early to inspect nginx. Once DNS works, use curl to check the HTTP status, redirects, and certificate name.

A 502 Bad Gateway response is a different layer: DNS has already resolved and the request has reached a proxy or gateway, which then failed to obtain a valid upstream response. For that case, see How to Fix a 502 Bad Gateway Error.

Can DNSSEC or the Hosts File Cause the Problem?

With DNSSEC enabled, the DS record at the parent and the DNSKEY records in the zone must match the active signatures. If you change nameservers and leave an old DS record behind, validating resolvers may reject the domain. A browser does not always present that failure as an obvious DNSSEC message.

If DNSSEC is suspected, compare the DS record at the registrar with the DNSSEC configuration at the DNS provider. Do not disable DNSSEC at random. First check which key is signing the zone and whether the nameserver change has completed. This query can help:

dig +dnssec example.com

The local hosts file can bypass DNS entirely. Check /etc/hosts on Linux and macOS, and C:WindowsSystem32driversetchosts on Windows. If an old line sends the hostname to the wrong address, the browser will not use the current DNS record.

I once left a hosts entry from a test in place for several weeks. Everyone else was reaching the new server while my laptop kept visiting the old one. It was not an NXDOMAIN error, but checking local overrides has been part of my DNS routine ever since. Test entries need an expiry plan, even if that plan is just a note in the ticket.

DNS_PROBE_FINISHED_NXDOMAIN Quick Checklist

• Check the domain name and extension character by character.
• Find the authoritative nameservers with dig +short NS your-domain.tld.
• Query the authoritative server directly: dig @nameserver your-domain.tld A.
• Query the root domain and the affected subdomain separately.
• Compare A, AAAA, and CNAME records with the targets your application expects.
• Check the domain’s renewal, lock, and delegation status at the registrar.
• Compare answers from multiple recursive resolvers.
• Inspect the local DNS cache and hosts file.
• If DNSSEC is enabled, verify that DS and DNSKEY records match.
• Only after DNS works, move on to the web server, TLS, and application layers.

The most useful habit I have built around DNS is refusing to stop at the browser’s error text. I check the authoritative answer with dig, then check which resolver the client is using. If those answers disagree, nginx and the application are usually innocent bystanders.

Frequently Asked Questions

Is DNS_PROBE_FINISHED_NXDOMAIN a virus or a modem failure?

Usually not. It means the requested name was reported as nonexistent through DNS. Test from different devices and networks to separate a local computer or router problem from an issue with the domain’s DNS configuration.

How long does DNS_PROBE_FINISHED_NXDOMAIN take to clear?

After the correct record is added, the timing depends on TTL, negative caching, and nameserver delegation. Waiting will not fix a wrong nameserver or an expired domain.

Will clearing the DNS cache always fix the error?

It can help when an old negative answer on your computer is the cause. It will not create a missing authoritative record, repair incorrect delegation, or reactivate a suspended domain.

What is the difference between DNS_PROBE_FINISHED_NXDOMAIN and a 502 error?

NXDOMAIN means the hostname was reported as nonexistent at the DNS layer, so the request may never reach the web server. A 502 error occurs after DNS resolution, when a proxy or gateway cannot obtain a valid response from its upstream server.

Sources

• ICANN – Domain Name System — icann.org
• RFC 2308 – Negative Caching of DNS Queries — rfc-editor.org
• RFC 8020 – NXDOMAIN: DNSSEC and Negative Answers — rfc-editor.org