Find where the DNS answer goes wrong
To troubleshoot DNS, look up the name yourself and read the response code, then ask different servers until you find where the answers diverge. Compare your own resolver, a few public resolvers and the domain's authoritative nameservers. The response code tells you what kind of problem you have.
In dig output, the status field in the header holds the code: NOERROR, NXDOMAIN, SERVFAIL or REFUSED. NOERROR with an empty answer section means the name exists but has no record of that type. Asking an authoritative server with +norecurse shows what the zone itself says, without any cache in between.
# Ask your configured resolver
dig example.com A
# Ask public resolvers directly
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig @9.9.9.9 example.com A +short
# Find the authoritative nameservers, then ask one without recursion
dig example.com NS +short
dig @ns1.example.net example.com A +norecurse
# The same checks with nslookup (record type first, server last)
nslookup example.com
nslookup -type=MX example.com 8.8.8.8NXDOMAIN: the name does not exist
NXDOMAIN means the authoritative servers say the name does not exist at all. Check the spelling first, then work through the usual causes.
- The record was never created, or it was created at a DNS host that is not in the domain's delegation.
- The domain expired or was put on hold, so the registry stopped publishing its nameservers. Check the registration status with your registrar or a WHOIS or RDAP lookup.
- The nameservers set at the registrar are wrong or no longer host the zone.
- A resolver cached an NXDOMAIN from before the record existed, and keeps returning it until the negative TTL set by the SOA record runs out.
SERVFAIL: the resolver could not get a valid answer
SERVFAIL comes from the recursive resolver. It means the resolver tried and failed, so the cause is usually on the authoritative side or in DNSSEC.
- DNSSEC validation failed, often because a DNS host change left a stale DS record at the registrar, or because signatures expired. If dig +cd returns an answer where the normal query fails, DNSSEC is the likely cause.
- None of the authoritative nameservers responded in time, because they are down, overloaded or blocked by a firewall.
- The delegation is lame: the listed nameservers exist but do not answer authoritatively for the zone.
- Glue records at the registry still hold old addresses for nameservers inside the domain.
REFUSED: the server will not answer you
REFUSED means the server you asked declined the query by policy. You usually see it when you query a server directly instead of through your own resolver.
An authoritative server returns it for a zone it does not host, which happens when the registrar still lists an old DNS host that has deleted the zone. A recursive resolver returns it to clients outside the network it serves, such as an ISP or company resolver queried from elsewhere.
Recent versions of dig print an EDE line (Extended DNS Errors) when the server gives a reason. Codes such as DNSSEC Bogus, No Reachable Authority or Prohibited narrow down both SERVFAIL and REFUSED.
Wrong, stale or inconsistent DNS answers
When the code is NOERROR but the data is wrong, compare the authoritative answer with what resolvers return. Where the difference starts tells you the cause.
- If the authoritative servers are right and a resolver is not, it is serving a cached copy. Wait for the old TTL to expire, or flush the caches you control.
- If the authoritative servers disagree with each other, a secondary has not picked up the latest zone. Compare their SOA serial numbers with dig +nssearch example.com.
- If the authoritative servers return the old value, the change was not saved or was made at a provider that is not in the delegation.
- If only one device or network is wrong, check its hosts file and any VPN or company resolver. Also check whether the browser uses DoH to a different resolver than the operating system.
- If the domain suddenly shows a parking page, the registration may have expired and the registrar may have replaced its nameservers.
- Answers that differ by location can be intentional, since CDNs and geographic routing return different addresses to different resolvers.
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
# Linux with systemd-resolved
resolvectl flush-caches
# Chrome: open chrome://net-internals/#dns and select "Clear host cache"When to compare public resolvers
Compare Cloudflare, Google and Quad9 after any DNS change, and whenever a site works for some people but not others. All three validate DNSSEC and sit outside your own network, so they show what visitors using large public resolvers get.
When all three agree with the authoritative servers but your machine does not, the problem is local. Disagreement between them usually means one still holds an older cached value. If all three fail, look at the delegation and the authoritative servers.
DNS Lookup queries the resolver you pick and repeats the lookup when you switch. Its Domain tab shows the registrar, expiry date and status from RDAP.