HowToCodePage

How name resolution works

Stub, recursive and authoritative servers, the path a lookup takes, and how to read dig output without guessing.

The lookup path

When you open https://www.example.com, the browser asks the operating system, which asks a stub resolver. That resolver forwards the question to a recursive resolver - your ISP, your router, or a public service. If the recursive resolver has no cached answer, it walks the hierarchy itself: root servers, then the .com name servers, then the name servers that hold the zone.

# who answers here, and what did they say?
dig www.example.com +short

# walk the whole delegation chain yourself
dig +trace www.example.com

# ask a specific resolver, bypassing local cache
dig @1.1.1.1 www.example.com A +noall +answer

# what are the name servers for the zone?
dig example.com NS +short
  • Authoritative servers hold the zone file - the source of truth for your records.
  • Recursive resolvers do the walking and cache the result for the record's TTL.
  • Your local OS cache is the last hop: a wrong entry there looks exactly like a wrong record.
  • The answer is a chain of trust in names, not a single lookup.

Reading an answer

An A query answer contains four things worth looking at: the status code, the answer section, the TTL remaining on each record, and the AUTHORITY section that shows which servers are responsible. Two failure modes cover most confusion: NXDOMAIN (the name does not exist) and SERVFAIL (the name exists but the lookup broke, commonly DNSSEC or an unreachable name server).

$ dig www.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47112
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0

;; ANSWER SECTION:
www.example.com.  3600  IN  CNAME  example.com.
example.com.      300   IN  A      203.0.113.10

;; SERVER: 1.1.1.1#53(1.1.1.1)
StatusMeaningWhere to look
NOERRORAnswer returned (may be empty)Answer and authority sections
NXDOMAINThis name does not existTypo, or the record was deleted
SERVFAILThe server could not answerDNSSEC, lame delegation, unreachable NS
REFUSEDThis server will not answer youAccess control on the name server

Debugging a broken name

  1. Query the authoritative servers directly (dig @ns1.example.com). If they answer correctly, the zone is fine and the problem is caching.
  2. If the authoritative servers are wrong, fix the zone and check the serial number increased so secondaries transfer.
  3. Compare answers from two independent resolvers; a difference means stale cache rather than a broken record.
  4. Check the delegation matches: dig +trace should show the same name servers the registrar lists.
  5. Flush the local cache last, not first.
💡
Always test the record type you actually depend on. A domain can resolve perfectly for HTTP and still have broken MX or CAA records - those are queried by different systems at different times.

FAQ

Why does it work for me but not for a colleague?
Different resolvers hold different cached answers. Query both resolvers directly with dig @ to see which one is stale.
Can I skip the recursive resolver?
Rarely useful. For a definitive answer query the authoritative name server, which is the only copy that is never cached.

Record types that matter HTTP and DNS in practice

Last refreshed 2026-09-18.