DNS is the backbone of nearly every internet service. When it breaks, websites become unreachable, emails bounce, and APIs fail — often without an obvious error message. This guide gives you a repeatable, systematic process for diagnosing and resolving DNS problems, whether you're a developer, sysadmin, or site owner.
Recognising DNS Symptoms
DNS problems manifest differently depending on where in the DNS resolution chain the failure occurs. Common symptoms include:
| Symptom | Likely DNS Cause |
|---|---|
| Browser shows "DNS_PROBE_FINISHED_NXDOMAIN" | Record does not exist or domain is not registered |
| Site loads for some users but not others | Propagation in progress or resolver-specific cache issue |
| Site resolves to wrong IP address | Stale cache, misconfigured A record, or DNS hijacking |
| Email delivery failures after DNS change | MX record missing, incorrect, or not yet propagated |
| Intermittent resolution failures | Nameserver downtime, SERVFAIL, or TTL/negative caching |
| Subdomain not resolving | CNAME or A record missing for the subdomain |
Before running any DNS commands, test from two different devices and two different network connections (e.g. your office and your phone on mobile data). This quickly tells you whether the problem is local to your device/network or global.
Step 1 — Confirm the Domain Resolves at All
Start with the simplest possible check: does the domain resolve to any IP address at all? Use nslookup (available on all platforms) or dig:
# Basic resolution check
nslookup example.com
# With dig — shows more detail including TTL
dig example.com A
# If no answer is returned, try against a public resolver to rule out local issues
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1If neither 8.8.8.8 nor 1.1.1.1 returns an answer, the problem is on the authoritative side: the record may not exist, the zone may be broken, or the domain may have expired.
Step 2 — Check That the DNS Records Exist
Use the ShowDNS DNS Lookup tool ordig to verify the specific records that should exist for your domain:
# Check A record (website)
dig example.com A @8.8.8.8
# Check MX records (email)
dig example.com MX @8.8.8.8
# Check CNAME for a subdomain
dig www.example.com CNAME @8.8.8.8
# Check all standard records at once
dig example.com ANY @8.8.8.8
# Check TXT records (SPF, DKIM, domain verification)
dig example.com TXT @8.8.8.8If a record that should exist is missing from the answer section, log in to your DNS control panel and verify it was created correctly. Check for typos in the hostname, incorrect record type, or a missing trailing dot if you are editing a raw zone file.
Step 3 — Verify Nameservers Are Correct
Even if your DNS records are correct, they will not be served if the nameservers are wrong at the registrar level. Check what nameservers are delegated for the domain from the TLD registry:
# Check nameservers at the TLD level (not your authoritative server)
dig example.com NS @a.gtld-servers.net
# Check nameservers as reported by common resolvers
dig example.com NS @8.8.8.8
# Trace the full delegation chain from root to authoritative
dig example.com A +traceCompare the NS records returned by the TLD root servers with what your registrar account shows for the domain. If they differ, the registrar update has not yet propagated or was not saved correctly.
You can also use the DNS Lookup tool to check NS records with a visual interface, or the DNS Propagation Checker to see nameserver propagation status globally.
Step 4 — Test From Multiple Resolvers
If the domain resolves correctly on some resolvers but not others, the issue is resolver-specific — most likely a cache or TTL problem rather than a zone error. Test at least three resolvers:
# Google Public DNS
dig example.com A @8.8.8.8
# Cloudflare DNS
dig example.com A @1.1.1.1
# OpenDNS
dig example.com A @208.67.222.222
# Your local resolver (no @ = uses system default)
dig example.com AIf only your system resolver returns the wrong answer, flush your local DNS cache. If only one public resolver is wrong, wait for its cached TTL to expire — this is a normal propagation situation and not a configuration error.
Step 5 — Inspect the Authoritative Answer Directly
To separate "propagation still in progress" from "zone is misconfigured," query the authoritative nameserver directly. The +trace flag walks the full delegation chain and ends at the authoritative server:
# Full delegation trace — ends at the authoritative nameserver
dig example.com A +trace
# Query the authoritative nameserver directly (replace ns1.example.com)
dig example.com A @ns1.example.com
# Check SOA record — confirms which server is authoritative and shows serial
dig example.com SOA @8.8.8.8A SERVFAIL response indicates that the resolver attempted to query the authoritative nameserver but received an error. Common causes are: the authoritative server is down, the zone file has a syntax error, DNSSEC validation failed, or the nameserver is not authoritative for the zone it was asked about. Check your hosting provider's status page and zone configuration.
Step 6 — Check for Negative Caching (NXDOMAIN)
If a domain or record previously did not exist and a resolver cached an NXDOMAIN (negative) response, it will continue to return NXDOMAIN for the duration of the SOA record's negative TTL — even after the record is created. Check the SOA for the negative TTL:
# The last number in the SOA record is the negative cache TTL (in seconds)
dig example.com SOA @8.8.8.8 +short
# Example output:
# ns1.example.com. hostmaster.example.com. 2024010101 3600 900 604800 300
# The negative TTL here is 300 seconds (5 minutes)The final number in the SOA record is the negative caching TTL. If a resolver returned NXDOMAIN recently, it will cache that negative result for up to this many seconds. There is no way to force a third-party resolver to flush its negative cache — you must wait.
Step 7 — Common Fixes by Symptom
Domain resolves to the wrong IP
- Flush your local DNS cache.
- Test against 8.8.8.8 and 1.1.1.1 to rule out a local cache issue.
- Verify the A record in your DNS panel shows the correct IP.
- Check whether the old IP still answers — if the old server is still running, traffic may be reaching it during propagation.
Subdomain not resolving
- Confirm a CNAME or A record exists for the exact subdomain hostname.
- Check for a wildcard record (
*.example.com) that might conflict or that the subdomain is meant to inherit. - Verify the record was saved in the correct zone (not a subdomain zone).
Email not delivering after DNS change
- Verify MX records exist and point to the correct mail server hostname.
- Confirm the MX target (e.g.
mail.example.com) has an A record. - Check that SPF TXT records are present and correct.
- Wait for MX propagation — the Propagation Checker can verify global MX record status.
# Full email DNS check
dig example.com MX @8.8.8.8
dig example.com TXT @8.8.8.8 # SPF record
dig mail.example.com A @8.8.8.8 # MX target must resolveStep 8 — Escalation Path
If the steps above do not resolve the issue, escalate in the following order:
- Hosting provider DNS support — if the problem is with records managed through their control panel or their nameservers are returning errors.
- Domain registrar support — if the nameserver delegation at the TLD registry is incorrect or not updating.
- TLD registry — in rare cases where the registry has an error in their database for your domain (e.g. domain lock preventing NS changes).
When opening a support ticket, include the output of dig example.com A +trace and dig example.com NS @8.8.8.8. This gives the support team the information they need without back-and-forth questions.
Frequently Asked Questions
How do I know if my DNS problem is local or global?
Test from a device on a different network (e.g. mobile data) and query public resolvers like 8.8.8.8 and 1.1.1.1 directly. If they return the correct answer but your device does not, the problem is local — flush your DNS cache and check your network settings. If public resolvers also fail, the problem is global.
What does "dig +trace" tell me that a regular dig query does not?
dig +trace starts from the DNS root servers and follows the delegation chain step by step: root → TLD → authoritative nameserver. This reveals exactly where the resolution fails — whether the TLD has wrong nameservers, the nameserver is unreachable, or the zone is misconfigured. A regular dig query shows only what a single resolver returns, which may be a cached (potentially stale) answer.
Why does nslookup return a different result than my browser?
Browsers use the operating system resolver, which checks the local DNS cache first.nslookup also uses the system resolver by default, but if you specify a server (e.g. nslookup example.com 8.8.8.8) it bypasses the local cache. If the browser still shows a different result after flushing the OS cache, flush the browser's own DNS cache at chrome://net-internals/#dns.
My site is down but dig returns the correct IP — what else could be wrong?
If DNS resolves correctly but the site is unreachable, the issue is likely not DNS at all. Check that the web server is running, the firewall allows traffic on port 80/443, and the SSL certificate is valid. Use curl -v https://example.comto see the full connection and TLS handshake details.
How long do I need to wait after fixing a DNS error?
After correcting the error on the authoritative server, you need to wait for the TTL of the incorrect record to expire on all resolvers that cached it. Check the current TTL with dig example.com A @8.8.8.8 +noall +answer. For negative cache (NXDOMAIN) propagation, wait for the SOA negative TTL.