Fixing DNS Errors: A Troubleshooting Guide

DNS errors disrupt everything that depends on domain name resolution: websites, email delivery, API calls, and authentication checks. When DNS fails, the symptoms range from a browser error page to silently bounced email. This guide covers the most common DNS errors, their root causes, and how to fix them.

Understanding DNS Error Types

DNS errors fall into a few broad categories:

• Resolution failures -- The DNS resolver cannot find a record for the queried domain.
• Server errors -- The authoritative DNS server or the resolver itself is malfunctioning.
• Configuration errors -- DNS records exist but are incorrect, conflicting, or incomplete.
• Propagation issues -- Changes have been made but have not yet reached all resolvers worldwide.

The first step in troubleshooting is identifying which category the error falls into. Use the InboxTooling DNS lookup tool to query your domain's records and compare the results against what you expect.

DNS_PROBE_FINISHED_NXDOMAIN

This is the most common DNS error users encounter in web browsers, particularly Chrome. NXDOMAIN stands for "Non-Existent Domain" and means the DNS resolver could not find any records for the queried hostname.

Common Causes

• The domain does not exist. The domain was never registered, has expired, or was deleted.
• Typo in the URL. A misspelled domain will naturally return NXDOMAIN.
• Missing DNS record. The domain exists but the specific hostname (e.g., www.example.com) has no A or AAAA record.
• Nameserver misconfiguration. The domain's registrar points to nameservers that do not have a zone file for the domain.
• Local DNS cache corruption. Your device or browser cached a negative response.

Fixes

1. Verify the domain is registered and not expired using a WHOIS lookup.
2. Check that the domain's nameservers at the registrar match the DNS hosting provider's nameservers.
3. Confirm the specific record exists using the DNS lookup tool.
4. Flush your local DNS cache:
5. Windows: ipconfig /flushdns
6. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
7. Linux: sudo systemd-resolve --flush-caches
8. Try resolving from a different DNS server (e.g., dig example.com @8.8.8.8) to rule out resolver-specific issues.

DNS Server Not Responding

This error means your device cannot communicate with its configured DNS resolver at all. It is a connectivity issue, not a record issue.

Common Causes

• Network connectivity loss. Wi-Fi disconnected, cable unplugged, or ISP outage.
• DNS server is down. ISP DNS resolvers are less reliable than public alternatives.
• Firewall blocking DNS. A firewall rule may be blocking UDP port 53 (standard DNS) or TCP port 853 (DNS-over-TLS).
• Incorrect DNS configuration. The DNS server address in your network settings is wrong.

Fixes

1. Test basic connectivity: can you ping an IP address directly (e.g., ping 1.1.1.1)? If yes, the problem is DNS-specific. If no, the problem is network connectivity.
2. Switch to a known-good public DNS resolver like Google (8.8.8.8) or Cloudflare (1.1.1.1) to rule out a resolver outage.
3. Check your firewall and security software for rules that block outbound DNS queries.
4. Restart your router and modem to clear any transient network state.
5. On Windows, run the network troubleshooter: Settings > Network & Internet > Status > Network troubleshooter.

SERVFAIL

A SERVFAIL response means the DNS resolver attempted to process the query but encountered an error. This is different from NXDOMAIN (which is a definitive "this domain does not exist" answer). SERVFAIL indicates something went wrong during resolution.

Common Causes

• DNSSEC validation failure. If the domain has DNSSEC enabled but the signatures are expired, invalid, or misconfigured, validating resolvers return SERVFAIL.
• Authoritative server unreachable. The resolver could not contact the domain's authoritative nameservers.
• Broken delegation. The parent zone (e.g., .com) points to nameservers that do not respond or do not have the zone configured.
• Misconfigured zone file. Syntax errors in the zone file on the authoritative server.

Fixes

1. Query the domain using a non-validating resolver to determine if DNSSEC is the issue. If the query succeeds without DNSSEC validation, the problem is with DNSSEC signatures.
2. Check that all nameservers listed for the domain are responding: dig NS example.com then query each nameserver individually.
3. If you manage the authoritative server, check the zone file for syntax errors and verify the zone is loaded correctly.
4. For DNSSEC issues, check that DS records at the registrar match the DNSKEY records on the authoritative server.

DNS Propagation Delays

After changing DNS records, the new values may not be visible from all locations immediately. This is not technically an error but is a frequent source of confusion.

How Propagation Works

DNS records have a Time-to-Live (TTL) value measured in seconds. When a resolver caches a record, it serves the cached version until the TTL expires. If your record had a TTL of 86400 (24 hours), some resolvers may serve the old value for up to 24 hours after you make a change.

Best Practices

• Lower TTL before making changes. Set the TTL to 300 seconds (5 minutes) at least 24 hours before a planned change. After the change propagates, raise the TTL back to a normal value (3600-86400).
• Wait for the old TTL to expire. If the previous TTL was 86400, expect up to 24 hours for full propagation.
• Test from multiple locations. Use the DNS lookup tool and query from different resolvers to see which ones have picked up the new record.
• Do not panic. Propagation is not instantaneous. If the record is correct at your authoritative nameserver, it will eventually propagate.

Misconfigured DNS Records

Record-level misconfigurations cause subtle problems that can be difficult to diagnose.

Multiple SPF Records

A domain must have exactly one SPF TXT record. Publishing two or more causes a PermError, and all SPF checks fail. This is the single most common email-related DNS error. Use the full domain analysis to detect duplicate SPF records.

CNAME at the Zone Apex

RFC 1035 prohibits CNAME records at the zone apex (e.g., example.com without a subdomain). Some providers offer proprietary workarounds (Cloudflare's CNAME flattening, Route 53's ALIAS records), but a standard CNAME at the apex breaks MX and TXT record resolution, disrupting email delivery.

Missing or Incorrect MX Records

If MX records are missing, some senders fall back to the A record, but many do not. Missing MX records cause email delivery to fail silently. Verify your MX configuration with the MX lookup tool.

TTL Set Too Low or Too High

Extremely low TTLs (under 60 seconds) increase DNS query volume and can cause rate limiting at some resolvers. Extremely high TTLs (over 86400 seconds) make it difficult to make timely changes. A TTL of 3600 (one hour) is a reasonable default for most records.

A Systematic Troubleshooting Approach

When DNS is not working as expected, follow this sequence:

1. Identify the error type. Is it NXDOMAIN, SERVFAIL, timeout, or a wrong value?
2. Query from multiple resolvers. Use Google (8.8.8.8), Cloudflare (1.1.1.1), and your ISP to compare results.
3. Query the authoritative nameserver directly. Use dig example.com @ns1.yourprovider.com to see what the authoritative server returns, bypassing all caching.
4. Check the registrar. Verify nameserver delegation is correct.
5. Check the zone. Verify the record exists and has the correct value in your DNS hosting provider's dashboard.
6. Run a full analysis. The InboxTooling full report checks DNS, MX, SPF, DKIM, and DMARC in one pass, catching issues across all layers.

Stay on top of your email infrastructure. Sign up for the InboxTooling newsletter for deliverability tips, tool updates, and best practices.