DNS errors: common causes and how to fix them

DNS errors prevent your browser from connecting to a website. The browser needs to translate the domain name into an IP address, and when that translation fails, the site does not load. The error message you see depends on which step of the DNS resolution process failed and which browser you are using.

This guide covers the most common DNS errors, what each one means at the protocol level, how to diagnose which step is failing, and how to fix it from both the visitor side and the server side.

How DNS resolution fails#

A DNS query goes through multiple steps: your device checks its local cache, queries a recursive resolver, the resolver queries root servers, TLD servers, and finally the authoritative nameserver for the domain. A failure at any step produces a different error.

The errors below are ordered from most common to least common in practice.

DNS_PROBE_FINISHED_NXDOMAIN#

What it means: The domain does not exist in DNS. “NXDOMAIN” stands for Non-Existent Domain. The authoritative nameserver for the TLD (like .com) responded that no domain by that name is registered, or the domain’s nameservers responded that the requested record does not exist.

What you see in the browser:

• Chrome: “This site can’t be reached” with DNS_PROBE_FINISHED_NXDOMAIN
• Firefox: “Hmm. We’re having trouble finding that site.”
• Safari: “Safari can’t find the server.”

Common causes:

Typo in the domain name. The most frequent cause. gogle.com instead of google.com . Check the spelling in the address bar.

Domain has expired. The owner did not renew the registration. The registrar removed the domain from the DNS system. Check the domain’s status with a WHOIS lookup:

whois example.com | grep -i "expir\|status"

If the status shows “redemptionPeriod” or “pendingDelete,” the domain has expired. If you own the domain, renew it immediately at your registrar.

Nameservers are misconfigured. The domain is registered but its nameservers point to servers that do not have records for it. This happens after a hosting migration when nameservers were updated at the registrar but the new DNS provider does not have the zone configured yet.

dig NS example.com

Check that the nameservers listed match where your DNS records are actually managed.

DNS records were deleted. The zone exists at the nameserver but the specific record you are requesting (usually an A record for the website) was deleted or never created.

dig A example.com

If this returns NXDOMAIN or an empty answer, the A record is missing. Add it in your DNS management interface.

Fix from the visitor side: If the domain genuinely exists and works for other people, your local DNS cache may have a stale NXDOMAIN result. Flush your DNS cache and try again.

For a deeper walkthrough of this specific error, see dns_probe_finished_bad_config: what it means and how to fix it.

DNS server not responding#

What it means: Your device sent a DNS query to its configured resolver and received no response. The resolver is unreachable, overloaded, or not running.

What you see in the browser:

• Windows: “DNS server not responding”
• Chrome: DNS_PROBE_FINISHED_NO_INTERNET or DNS_PROBE_FINISHED_BAD_CONFIG
• macOS network diagnostics: “DNS server is not responding”

Common causes:

Your ISP’s DNS server is down. ISP-provided DNS servers go down more often than most people realize. The fix is to switch to a public DNS resolver:

Test whether it is your DNS server or your internet connection:

# Test DNS resolution with a specific server
nslookup example.com 1.1.1.1

# Test internet connectivity without DNS
ping 1.1.1.1

If ping 1.1.1.1 works but nslookup with your default DNS fails, the problem is your DNS resolver. Switch to a public resolver.

Your router is the DNS resolver and it is failing. Many home and office routers act as DNS forwarders. If the router’s DNS service crashes or the router is overloaded, all DNS queries from every device on the network fail.

Fix: Restart the router. If the problem recurs, configure your devices to use a public DNS resolver directly instead of the router’s IP.

Network connection is down. If you have no internet connectivity at all, DNS queries fail along with everything else. Check your physical connection, Wi-Fi status, and router.

For the complete diagnostic and fix guide, see DNS server not responding: what it means and how to fix it.

SERVFAIL#

What it means: The recursive resolver tried to resolve the domain but received an error from an upstream nameserver. SERVFAIL is a generic “something went wrong” response from the resolver. It does not tell you what went wrong, only that the resolution process failed.

Common causes:

DNSSEC validation failure. If the domain has DNSSEC enabled but the signatures are invalid (expired, misconfigured, or the zone was re-signed incorrectly), DNSSEC-validating resolvers return SERVFAIL rather than passing along an unverifiable answer.

Test by querying with and without DNSSEC validation:

# With DNSSEC validation (default for most resolvers)
dig example.com @1.1.1.1

# Without DNSSEC validation (bypasses signature checks)
dig example.com @1.1.1.1 +cd

If the +cd (checking disabled) query succeeds but the normal query returns SERVFAIL, the problem is DNSSEC. The domain owner needs to fix their DNSSEC configuration.

Authoritative nameserver is down. The resolver queried the domain’s authoritative nameserver and got no response or an error response. This is a server-side problem that the domain owner needs to fix.

# Check which nameservers are authoritative
dig NS example.com

# Query each one directly
dig example.com @ns1.example.com
dig example.com @ns2.example.com

If one nameserver responds and the other does not, there is an availability problem with the failing nameserver.

Lame delegation. The nameservers listed in the domain’s NS records do not actually serve DNS for that domain. The resolver gets directed to a nameserver that has no zone file for the domain and returns SERVFAIL or REFUSED.

Fix from the visitor side: SERVFAIL is usually a server-side problem. Try a different DNS resolver (1.1.1.1 vs 8.8.8.8) in case the issue is specific to one resolver’s cache. If it fails everywhere, the problem is with the domain’s DNS configuration.

REFUSED#

What it means: The DNS server explicitly refused to answer the query. Unlike SERVFAIL (which means “I tried and failed”), REFUSED means “I will not process this query.”

Common causes:

Querying the wrong nameserver. You sent a query to a nameserver that is not authoritative for the domain and does not offer recursive resolution. Most authoritative nameservers refuse queries for domains they do not host.

Access control. The nameserver has ACLs (access control lists) that restrict which IPs can query it. If your IP is not in the allowed list, the server returns REFUSED.

Recursive queries disabled. You queried a nameserver expecting it to perform recursive resolution, but the server only answers authoritatively for its own zones.

Fix: Make sure you are querying the correct nameserver. For general resolution, use a public recursive resolver (1.1.1.1, 8.8.8.8). For checking a specific domain’s records, query its authoritative nameservers directly:

# Find authoritative nameservers
dig NS example.com @1.1.1.1

# Query authoritatively
dig example.com @ns1.example-dns-provider.com

DNS_PROBE_FINISHED_BAD_CONFIG#

What it means: Chrome-specific error indicating that your device’s DNS configuration is broken. Either no DNS server is configured, the configured server is unreachable, or the network stack is in a corrupted state.

Common causes:

• VPN or proxy software changed DNS settings and did not restore them
• Network adapter was manually configured with an invalid DNS server
• The system’s resolver configuration file is corrupt

Fix:

On Windows:

ipconfig /flushdns
netsh winsock reset
netsh int ip reset

Then restart. If the problem persists, manually set DNS to 1.1.1.1 and 1.0.0.1 in your network adapter settings.

On macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

On Linux:

sudo systemd-resolve --flush-caches
sudo systemctl restart systemd-resolved

For the full walkthrough, see dns_probe_finished_bad_config: what it means and how to fix it.

Diagnosing DNS errors#

Step 1: Is it all sites or one site?

If every site fails to load, the problem is your DNS resolver or your internet connection. If only one site fails, the problem is that site’s DNS configuration.

Step 2: Can you resolve the domain from the command line?

nslookup example.com

or:

dig example.com

If the command line query succeeds but the browser fails, clear your browser’s DNS cache. In Chrome, go to chrome://net-internals/#dns and click “Clear host cache.”

Step 3: Try a different resolver

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

If one resolver works and another does not, the failing resolver has a stale cache or is experiencing issues. Switch to the working one.

Step 4: Check the authoritative answer

dig example.com +trace

The +trace flag follows the entire resolution chain from the root servers down to the authoritative nameserver. This shows you exactly where the lookup fails.

Step 5: Check from an external perspective

Use SiteProbe’s DNS lookup tool to check the domain’s records from an authoritative source. This bypasses your local cache, your resolver, and any network-specific issues. If SiteProbe shows valid records but you cannot resolve the domain locally, the problem is on your end.

DNS propagation issues#

DNS propagation is not an error, but it causes symptoms that look like DNS errors. When you change a DNS record, the old record remains cached by resolvers around the world until the TTL (Time to Live) expires. During this window, some visitors see the old record and some see the new one.

Symptoms:

• Site works for some people but not others after a DNS change
• Site loads on mobile data but not on Wi-Fi (different DNS resolvers)
• dig  shows the new IP but the browser loads the old site

How to check propagation:

# Check what different resolvers return
dig example.com @1.1.1.1 +short
dig example.com @8.8.8.8 +short
dig example.com @9.9.9.9 +short

If different resolvers return different IP addresses, propagation is still in progress. Wait for the TTL to expire. You can check the TTL on the current record:

dig example.com +noall +answer

The number in the TTL column shows how many seconds remain before the cache expires.

How to speed it up:

• Flush your local DNS cache to see the new record immediately on your device
• Before making DNS changes, reduce the TTL to 300 seconds (5 minutes) a day in advance
• After the change propagates, increase the TTL back to 3600 or higher

Quick reference#

# Quick diagnostic sequence
nslookup example.com              # Does it resolve at all?
nslookup example.com 1.1.1.1     # Does it resolve with a public DNS?
dig example.com +trace            # Where does the chain break?
dig example.com @ns1.provider.com # Does the authoritative NS respond?
whois example.com | grep -i expir # Is the domain expired?

For browser-specific connection errors that may or may not be DNS related, see “This site can’t be reached”. For email delivery issues caused by missing DNS records, see MX records explained.