What Is a DNS Error? Meaning, Causes, and How to Fix It

I run production monitoring on bare metal and spend a lot of time looking at DNS logs. “DNS error” is one of the most overloaded phrases in web support. It covers at least six different underlying failures, each with a different fix, and browsers do a mediocre job of telling you which one you just hit.

I wrote a companion piece on DNS server not responding which covers the specific case where your own resolver is unreachable. This guide is broader: everything the phrase “DNS error” can actually mean, how to read the error message you were given, and how to fix it from the right layer instead of blindly flushing a cache that was never the problem.

1. What a DNS Error Actually Is

Every time you type a domain name, your device has to translate it into an IP address before any bytes of HTTP can flow. That translation is the Domain Name System. A DNS error is any failure during that translation step. The request never reaches the website, because the device literally does not know where to send it yet.

Four servers are usually in the picture for a single lookup:

• The stub resolver on your device (the operating-system DNS client).
• A recursive resolver you are configured to use (your ISP, your router, or a public resolver like 1.1.1.1).
• The root and TLD servers, which point the resolver toward whoever is authoritative for a zone.
• The authoritative server for the domain itself, which actually holds the A, AAAA, MX, TXT, CNAME, and NS records.

A DNS error can originate at any of those layers. That is why the fix depends on which layer broke, and why “just flush your DNS cache” works one time in five. The browser collapses all of those failure modes into a single short string, so the first job when you hit a DNS error is to figure out which layer the message actually came from.

2. The Six DNS Response Codes You Actually See

RFC 1035 defines the DNS response codes (RCODEs) that every authoritative server uses to answer a query. There are sixteen in the registry, but only six are common in the wild. Everything browsers, consoles, and operating systems call a “DNS error” maps back to one of these.

Two of these do most of the damage in practice. NXDOMAIN means the domain’s authoritative answer was “this does not exist,” which is a content problem, not an infrastructure problem. SERVFAIL means the resolver could not get a useful answer back, which is an infrastructure problem, not a content problem. Treating them the same is how a five-minute incident becomes a three-hour one.

3. Chrome Error Messages and What They Really Mean

Chrome (and the rest of Chromium: Edge, Brave, Opera) dresses DNS failures with its own error names. The surface text does not always match the underlying RCODE cleanly. Here is how to translate the most common Chrome messages back to what the DNS layer actually said.

Firefox and Safari use different wording (“Server not found,” “Safari can’t find the server”) but sit on top of the same resolver APIs. The underlying DNS layer is the same regardless of browser. When Chrome says DNS_PROBE_FINISHED_NXDOMAIN and Firefox says “Server not found” on the same URL, you are looking at one DNS failure, not two.

4. DNS Errors That Look Like “Your Connection Is Not Private”

A huge category of “DNS errors” people report actually surface as SSL warnings. The browser says “your connection is not private” or shows NET::ERR_CERT_COMMON_NAME_INVALID, and the obvious instinct is to blame the certificate. In a large fraction of these cases the certificate is fine, and the DNS layer is pointing at the wrong server entirely.

The sequence goes like this. DNS resolves example.com to an IP. The browser connects to that IP. The server at that IP presents a TLS certificate. The browser checks whether the certificate matches the hostname the user typed. If it does not match, the browser aborts and surfaces a certificate warning. The DNS step “succeeded” in the sense that it returned an answer, but it returned the wrong answer, and the downstream damage is visible as an SSL problem.

Three patterns cause this:

• Stale A record. The site moved to a new host but the DNS still points at the old one. The old IP is now serving a different site entirely, with a certificate for a different hostname.
• DNS hijack at the network layer. A compromised router, a malicious ISP DNS, or a captive portal rewrites DNS answers. The browser gets pointed at an IP the attacker chose.
• Split-horizon mismatch. An internal DNS returns a private IP that resolves to something other than the real public origin, common on corporate networks using SSL-inspection proxies.

If the SSL warning goes away when you query a different DNS resolver, the root cause was DNS, not TLS. Worth checking before reissuing a certificate for a site whose cert was already valid. For the pure certificate cases, my SSL error guide covers the full matrix.

5. If You’re a Visitor: What You Can Actually Do

Most visitor-side DNS errors are local (your device, router, or resolver), not the site’s fault. Work through these in order. Each step either fixes it or narrows the cause.

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows (admin CMD)
ipconfig /flushdns

# Chrome internal cache
chrome://net-internals/#dns  ->  Clear host cache

dig @1.1.1.1 example.com
nslookup example.com 8.8.8.8

6. If You Run the Site: Where to Look First

If visitors are hitting DNS errors, the diagnosis tree looks different. You need to know whether the authoritative DNS is answering correctly, and if it is, whether the answer has reached the resolvers users actually hit.

Start with the authoritative layer. Query the nameservers listed for your zone directly, not through a recursive resolver:

# Get the NS records for your zone
dig NS example.com +short

# Ask each NS directly for the A record
dig @ns1.example.com A example.com
dig @ns2.example.com A example.com

# Check SERVFAIL signals (DNSSEC, delegation)
dig example.com +dnssec
dig example.com +trace

A few concrete patterns account for most site-owner DNS errors:

• Expired domain. Nothing fixes this except renewing at the registrar. NXDOMAIN across every resolver, everywhere.
• Broken DNSSEC. A signing mistake, a rolled key not picked up by the parent, or a mismatched DS record produces SERVFAIL on validating resolvers (1.1.1.1, 8.8.8.8) but may still work on non-validating ones. Users on major resolvers see the error; you on your workstation might not.
• Missing or mistyped record. Someone edited the zone and removed the A record for the apex, or pointed a CNAME at a name that no longer exists. Verify with dig A example.com directly against the authoritative NS.
• TTL timebomb. A record was changed, but the old TTL was a day long. Users with fresh lookups see the new answer; users with cached old answers see the old IP (now dead) and get errors until the TTL expires.
• NS delegation drift. The registrar’s glue records point at different NS hostnames than your provider actually uses. Lookups chase the bad delegation and time out.
• Single NS provider outage. All your authoritative NS are at one provider, and that provider is having a day. This is why “use two NS providers” is standard advice for anyone past hobby scale.

Once the authoritative answer is right, verify propagation. A tool like dnschecker.org queries recursive resolvers around the world. If 90% of regions return the new record and 10% still return the old one, you are mid-propagation and the answer is simply “wait out the TTL.”

7. PS5, Xbox, Smart TVs: DNS Errors on Consoles

Consoles and smart TVs fail at DNS more often than laptops do, for a simple reason: the device usually inherits whatever DNS the router handed out, and a lot of consumer routers hand out their own IP as the DNS server (a built-in DNS proxy that is often worse than the ISP’s upstream). Fix it by overriding DNS on the device.

Wired Ethernet instead of WiFi also helps on consoles. Many “DNS error” reports on PS5 or Xbox turn out to be WiFi packet loss interacting badly with UDP DNS retries, not a real name resolution issue.

8. Diagnosing a DNS Error with dig and nslookup

Browser errors hide the useful data. dig shows you the actual RCODE, which resolver answered, the TTL, whether DNSSEC validated, and the full path of the lookup. If you only learn one diagnosis tool, learn this one.

# Basic A-record lookup against a specific resolver
dig @1.1.1.1 example.com

# Force a +trace to walk root -> TLD -> authoritative
dig example.com +trace

# Check if DNSSEC validation is the problem
dig example.com +dnssec +cd    # +cd disables validation
dig example.com +dnssec        # with validation; compare RCODEs

# Look up every record type at once
dig example.com ANY

# MX records (often broken independently of A records)
dig example.com MX

# Reverse DNS (sanity-check an IP belongs to the hostname)
dig -x 93.184.216.34

Read the output’s status: field. That is the RCODE. NOERROR means DNS succeeded, and any error you see is downstream. NXDOMAIN, SERVFAIL, and REFUSED each point at a different fix.

For Windows users without dig, nslookupships with the OS and gives you the essentials. PowerShell’s Resolve-DnsName example.com -Server 1.1.1.1is a closer match to dig’s output if you want structured detail.

9. How to See DNS Errors Before Your Users Do

The thing that makes DNS errors painful is not the error itself, it is the lag between the first user hitting one and someone on your team finding out. A broken DNS record can stay broken for hours before a human types the URL and notices. Continuous DNS monitoring closes that gap.

Structurally, the practices that cut DNS-error incidents over time: keep registrar auto-renew on, use two authoritative DNS providers on different infrastructure, lower TTLs 24 hours before planned record changes and raise them back afterwards, sign your zone with DNSSEC but test the signing chain before publishing DS records, and monitor NS reachability along with the records themselves. Most outages attributed to “DNS error” in a post-mortem trace back to one of those five missing.

10. Frequently Asked Questions

Related Guides