NetEngToolkit

How to Troubleshoot DNS Resolution Problems

DNS and web · Last updated 12 October 2026 · 6 min read

A step-by-step method for diagnosing names that will not resolve, resolve to the wrong address, or work for some users and not others, using dig, nslookup, and public resolvers.

The problem, stated precisely

"DNS is broken" can mean several different things, and each has a different cause. Before running any command, decide which of these you are seeing:

  • The name does not exist (the resolver says NXDOMAIN).
  • The name exists but has no record of the type you need (NOERROR with an empty answer, often called NODATA).
  • The lookup fails (SERVFAIL, REFUSED, or a timeout).
  • The answer is wrong or stale (an old address, or a different address than expected).
  • It works for some users or networks but not others.

Write down the exact name, the record type, which network you tested from, and the error text. A reproducible description is half the diagnosis.

Step 1: Verify the name and the record type

Check spelling, and remember that example.com and www.example.com are two separate names that can have different records. Mail uses MX records, not the address of the web server. Services such as SIP or Microsoft 365 autodiscover use SRV or CNAME records at specific labels. Confirm you are asking for the record that the application actually uses.

Step 2: Ask a public resolver and compare

Query the name with the DNS Lookup tool (record type ALL gives a complete overview) and compare with what your own machine sees. This single comparison separates "the domain's DNS is broken everywhere" from "something is wrong on my network".

# Your configured resolver
nslookup www.example.com
dig www.example.com A

# A specific public resolver (for comparison)
nslookup www.example.com 1.1.1.1
dig @8.8.8.8 www.example.com A +noall +answer

If public resolvers return the right answer and yours does not, the fault is in your resolver, cache, or local configuration. If they all fail the same way, the problem lies with the domain's own DNS (steps 4 and 5).

Step 3: Read the response status

dig prints the status in its header line. This tells you more than whether an address appeared:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41932
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5120      <- but ANSWER: 0 means NODATA
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8830
;; connection timed out; no servers could be reached          <- no response at all
(illustrative header lines)
NXDOMAIN
The name does not exist according to the authoritative servers. Check for typos, a missing record, a domain that expired, or a record that was deleted. Resolvers cache this result (negative caching, RFC 2308) for a time governed by the zone's SOA record, so a name you have just created may keep failing for a while.
NOERROR with no answer (NODATA)
The name exists but not with that record type. Typical example: asking for AAAA on a name that only has an A record. This is normal and not an error.
SERVFAIL
The resolver could not obtain a valid answer. Common causes are authoritative servers that do not respond, broken delegation, or DNSSEC validation failure (step 6).
REFUSED
A server declined to answer, often because recursion is not allowed for your address, or because you queried an authoritative server for a zone it does not host.
Timeout
Nothing came back: a firewall blocking port 53, a down resolver, or a broken network path. Move to connectivity troubleshooting.

Step 4: Go to the authoritative servers

Public resolvers show what they have cached. To see what the domain actually publishes, find its name servers and ask them directly:

dig example.com NS +short
dig @ns1.example.net example.com A +norecurse
dig +short SOA example.com @ns1.example.net
dig +short SOA example.com @ns2.example.net

An authoritative answer carries the aa flag. If one authoritative server returns the new record and another still returns the old one, compare the SOA serial numbers (the third field of the SOA record): different serials mean the servers have not synchronized, which causes the intermittent "sometimes works, sometimes doesn't" symptom as resolvers pick between them.

Step 5: Check the delegation

The parent zone (for example the .com registry) must list the correct name servers for your domain. If the registry points to servers that are not authoritative for the zone (a lame delegation), resolvers get SERVFAIL or timeouts. Trace the chain from the root:

dig +trace www.example.com

Compare the NS records returned by the parent with the NS records published inside your zone, and confirm both sets match the servers you actually operate. The WHOIS / RDAP Lookup shows the name servers registered at the registry. A common mistake after changing DNS providers is updating records in the new provider but never changing the name servers at the registrar.

Step 6: Rule out DNSSEC failures

If a domain has DNSSEC records, validating resolvers return SERVFAIL when signatures do not verify (expired signatures, or a DS record at the registry that no longer matches the zone's key after a key change or provider move). A telling test is to ask with validation disabled:

dig example.com A            # SERVFAIL on a validating resolver
dig example.com A +cd        # +cd = checking disabled: returns an answer

If the +cd query succeeds, the data exists but validation is failing. Use the DNS Security Checker to see whether DS and DNSKEY records are present, then fix or remove the stale DS record at the registrar.

Step 7: Caching, TTL, and your own machine

If the authoritative answer is correct but you still see the old one, you are looking at a cache. A record is cached for up to its TTL, so after a change the old value can persist until the old TTL expires; lowering the TTL a day or more before a planned change shortens that window. Flush the cache on the machine under test:

# Windows
ipconfig /flushdns

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

# Linux (systemd-resolved)
resolvectl flush-caches

Also check the local hosts file, which overrides DNS entirely, and your DNS search suffixes: a short name such as fileserver is resolved by appending suffixes, so it can resolve on one network and fail on another.

Step 8: It works for some users but not others

  • Different resolvers, different caches. Users on different resolvers see changes at different times (compare Cloudflare, Google, and Quad9 in the DNS Lookup tool).
  • Split-horizon DNS. Internal resolvers may return different (often private) answers than the public DNS. A name that works inside a VPN and fails outside is a typical sign.
  • Geo or load-balanced DNS that deliberately returns different addresses by location.
  • A broken AAAA record. If a name has an IPv6 address that is unreachable, applications may stall before falling back to IPv4. Test with dig AAAA and with IPv6 disabled.
  • Email only: an MX record must point to a hostname that has an address record, not directly to an IP address, and the target should not be a CNAME.

Quick reference: symptom to likely cause

Symptom                                 Likely cause / next check
NXDOMAIN everywhere                     Record missing, typo, expired domain (Step 1, WHOIS)
NXDOMAIN only on your network          Local/split-horizon DNS or cached negative answer (Steps 2, 7)
SERVFAIL everywhere                     Lame delegation or DNSSEC failure (Steps 5, 6)
Old address after a change              TTL/cache; flush, wait out the TTL (Step 7)
Different answers per resolver          Propagation, or geo-DNS (Step 8)
Timeouts                                Firewall, down resolver, no connectivity
Name works but site doesn't             DNS is fine; test HTTP and TLS next

Security and privacy considerations

  • If resolution suddenly returns unexpected addresses for well-known sites, suspect a changed resolver setting, a compromised router, or malware modifying DNS or the hosts file; check the configured resolver addresses.
  • Names you type into any online DNS tool, including this one, are sent to that tool's server and to the DNS provider it uses. Avoid entering confidential internal hostnames; use dig or nslookup from your own network for those.
  • Encrypted DNS (DNS over HTTPS or TLS) protects queries from on-path observers but not from the resolver itself.

Tools used in this guide

  • DNS Lookup — Query A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, and SRV records for a domain.
  • Reverse DNS Lookup — Look up the PTR hostname associated with an IPv4 or IPv6 address.
  • DNS Security Checker — Analyze SPF, DMARC, DKIM, DNSSEC, and CAA configuration for a domain, with each finding explained.
  • WHOIS / RDAP Lookup — Look up domain registration details — registrar, registration/expiration dates, name servers — via RDAP.

References and further reading

References are primary sources (standards and official documentation). Commands and sample output are illustrative; behavior can vary by operating system and software version.

Keep reading