DNS

DNS is a distributed, cached database for names. The protocol looks simple until caching, delegation, CNAME chains, split-horizon zones, DNSSEC, search paths, response codes, EDNS, UDP/TCP transport, and resolver behavior interact. Ops people need to understand the full path from application lookup to authoritative answer.

Authoritative zone snippets and resolver-debugging commands are embedded in the DNS topic pages: use Resolution and Caching for resolver paths and intermittent lookups, Authoritative DNS and Zones for zone-file patterns, and Records, Responses, and Transport for response-code and UDP/TCP behavior.

The Actors

Most clients do not talk to root or authoritative servers directly. They ask a recursive resolver, often from DHCP, systemd-resolved, a corporate DNS service, or a public resolver.

Critical Subtopics

Walkthrough: Resolving www.example.com

1. The application calls resolver APIs such as getaddrinfo.
2. The OS checks local sources: hosts file, local cache, resolver daemon, and configured name service order.
3. The stub resolver asks its configured recursive resolver for A and/or AAAA records.
4. If not cached, the recursive resolver asks a root server where to find .com.
5. The root server returns a referral to .com TLD nameservers.
6. The resolver asks a .com server where to find example.com.
7. The TLD server returns the domain’s authoritative NS records, often with glue A/AAAA records when needed.
8. The resolver asks an authoritative server for www.example.com.
9. The authoritative server returns an answer, CNAME, NXDOMAIN, NODATA, or referral.
10. The recursive resolver caches the result for the TTL and returns it to the client.

DNS “propagation” is usually cache expiration. There is no global push of new records to every resolver.

Browser Enter-to-Answer Walkthrough

When a user types https://www.example.com/products in the address bar and presses Enter, DNS is only one part of the page load, but it is the part that turns the hostname into one or more IP addresses the browser can connect to.

sequenceDiagram
  participant Browser
  participant OS as OS / Stub Resolver
  participant Recursor as Recursive Resolver
  participant Root as Root Server
  participant TLD as TLD Server
  participant Auth as Authoritative Server
  participant Server as Web Server / CDN

  Browser->>Browser: Parse URL and check browser DNS/cache state
  Browser->>OS: Resolve www.example.com A and AAAA
  OS->>OS: Check hosts file, NSS, local resolver cache
  OS->>Recursor: Query A/AAAA for www.example.com
  Recursor->>Recursor: Check recursive cache
  Recursor->>Root: Where is .com?
  Root-->>Recursor: Referral to .com TLD nameservers
  Recursor->>TLD: Where is example.com?
  TLD-->>Recursor: Referral to example.com authoritative NS plus glue if needed
  Recursor->>Auth: What are A/AAAA for www.example.com?
  Auth-->>Recursor: Answer, CNAME chain, NXDOMAIN, NODATA, or SERVFAIL
  Recursor-->>OS: Cache and return final DNS response
  OS-->>Browser: Return address list and metadata
  Browser->>Server: TCP or QUIC connection, TLS, HTTP request
  Server-->>Browser: HTTP response bytes rendered into the page

The path in detail:

OS and Stub Resolver Details

The browser does not always emit a raw DNS packet itself. On a normal Linux desktop or server, it usually asks an application resolver API to resolve the hostname. That path may involve libc getaddrinfo, browser-internal DNS code, systemd-resolved, NetworkManager, a VPN client, or a configured DNS-over-HTTPS mode. The important operational point is that the resolver path is policy, not just protocol.

Before DNS leaves the machine, local layers can answer or rewrite the lookup:

The stub resolver usually does not walk root, TLD, and authoritative servers itself. It prepares a DNS question, applies local policy, and sends the question to a recursive resolver with recursion requested. On Linux, the exact behavior depends on the application and name-service stack:

Stub resolver behavior checklist:

The return value can be less direct than “name to one IP.” A successful lookup may return multiple IPv4 and IPv6 addresses, a canonical name after CNAME processing, or an ordered candidate list that the application races or retries. A failed lookup may be reported as a name-not-known error, temporary failure, no address for that family, timeout, or a generic application connection failure. Translate the application error back into resolver evidence before assuming the zone is wrong.

Common resolver-file clues:

Useful checks:

getent hosts www.example.com
getent ahosts www.example.com
cat /etc/nsswitch.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status
resolvectl query www.example.com
tcpdump -nn -i any 'port 53'

getent hosts follows the local application-style path better than dig. dig is better for asking a specific DNS server a specific DNS question. If getent and dig disagree, focus on local resolver policy before blaming authoritative DNS.

Interpret mismatches this way:

Recursive Resolver Cache-Miss Traversal

The recursive resolver is the worker that turns “I need www.example.com” into one or more records. The client normally sends one question to the recursive resolver, and the recursive resolver performs the hierarchy walk on the client’s behalf.

On a cache miss, a recursive resolver usually does this:

1. Check whether it already has usable cached data for the exact name, CNAME target, NS set, glue, negative answer, or DNSSEC validation material.
2. Start from a priming root-hints view of the root nameservers if it has no closer cached delegation.
3. Ask a root server for the TLD delegation, such as .com.
4. Cache the root referral and TLD nameserver data according to TTLs.
5. Ask a TLD server for the domain delegation, such as example.com.
6. Cache the domain NS set and any in-bailiwick glue records.
7. Ask one authoritative server for the requested record type, commonly A and AAAA for browser connection setup.
8. Follow CNAMEs if the answer aliases to another name, possibly crossing into another zone with another delegation path.
9. Validate DNSSEC if validation is enabled and the zone is signed.
10. Cache the positive answer, CNAME chain, NODATA, NXDOMAIN, or failure metadata according to protocol and resolver policy.
11. Return the answer, partial answer, or failure to the client stub.

The resolver does not ask every root server or every TLD server. It selects one or more candidates, retries if needed, marks bad servers temporarily, and prefers servers that respond quickly. Modern resolvers also use EDNS, may minimize query names for privacy through query name minimization, may validate DNSSEC, and may serve stale cached answers during upstream trouble if configured.

Cache misses are not only about final A/AAAA records. The resolver can have cached the .com delegation but not example.com, or cached the example.com NS set but not www.example.com. That is why repeated queries can get faster even before the final record is cached.

The traversal starts from the closest cached delegation, not always from the root. If the resolver already knows the NS set for example.com, a cache miss for api.example.com can go straight to an example.com authoritative server. If it only knows .com, it asks a .com TLD server. If it has no usable delegation data, it falls back to root hints and root priming.

Detailed cache-miss path:

Record type matters. A cached A answer does not necessarily satisfy an AAAA query, an MX query, or a DNSKEY query. A cached CNAME can help multiple query types because the alias is reusable, but the final target records still have their own TTLs and failure modes.

Cache state is layered:

The DNS response sections explain where the resolver is in the walk:

Flags matter too. A stub usually sets RD to request recursion. A recursive resolver answering the client usually sets RA if recursion is available. Authoritative responses set AA when the server is authoritative for the answer. Referrals from root and TLD servers are normally non-recursive responses with authority data pointing closer to the target.

When a CNAME crosses a zone boundary, the recursive resolver may finish one authoritative lookup and then start another traversal for the CNAME target. For example, www.example.com CNAME example.cdn-provider.net can require the resolver to walk or use cached delegation for cdn-provider.net before it can return final A/AAAA records.

Operationally, a cache miss is healthy when each step gets either a closer referral or an authoritative terminal response. A timeout, referral loop, lame delegation, bogus DNSSEC proof, or unusable glue stops forward progress and usually surfaces to the client as timeout or SERVFAIL.

Root, TLD, and Authoritative Referrals

DNS hierarchy traversal is referral based. A parent usually does not give the final web-server address. It tells the resolver which nameservers are closer to the answer.

Referral anatomy:

Glue matters when a delegated nameserver is in-bailiwick. If example.com is served by ns1.example.com, the resolver needs an address for ns1.example.com before it can ask it anything. The parent can include glue A/AAAA records to break that loop. If the nameserver is out-of-bailiwick, such as ns1.dns-provider.net, the resolver resolves that nameserver name through its own normal path.

Parent-child delegation consistency is the audit target. The parent delegation is what public recursive resolvers follow first, while the child apex NS records are what the zone itself says about its nameservers. They do not have to be byte-for-byte identical in every advanced setup, but unexplained drift is an incident clue during DNS provider migrations.

Additional-section glue is useful but limited. It is only trusted when it is in bailiwick for the delegation being returned; the additional section is not a source of arbitrary truth. If a .com response includes unrelated addresses for another domain, a resolver should ignore them for cache purposes.

Important referral failure modes:

Referral troubleshooting should compare four views: the registrar or parent-zone delegation, direct TLD responses, each authoritative server’s SOA and NS answers, and the recursive resolver’s cached view. If those do not line up, fix the layer that is wrong instead of repeatedly flushing client caches.

Use these commands to separate referral layers:

dig +trace www.example.com
dig NS com.
dig NS example.com
dig @<tld-server> example.com NS +norecurse
dig @<authoritative-ns> www.example.com A +norecurse
dig @<authoritative-ns> www.example.com SOA +norecurse

To inspect the layers without relying only on +trace, query each hop explicitly:

dig @a.root-servers.net com. NS +norecurse
dig @<com-tld-server> example.com NS +norecurse
dig @<authoritative-ns> example.com SOA +norecurse
dig @<authoritative-ns> www.example.com A +norecurse
dig @<authoritative-ns> www.example.com AAAA +norecurse

Read the output by section:

Lame delegation checks:

for ns in $(dig +short NS example.com); do
  dig @"$ns" example.com SOA +norecurse +time=2 +tries=1
done

A healthy authoritative server should return an SOA for its zone with the authoritative-answer flag. A server that times out, refuses, or answers without authority is not a reliable target for the parent delegation.

If the TLD delegation is wrong, editing only the authoritative zone will not fix the public path. If the authoritative zone is wrong, changing resolver settings will only hide the problem for one resolver view.

For a cached answer, steps 7 through 9 may not happen at all. For a reused browser connection, no DNS query may happen for that Enter press. For split-horizon DNS, the answer depends on which resolver view the client used. For DNS over HTTPS, the DNS query may appear as HTTPS traffic to the DoH resolver rather than visible UDP/TCP 53 traffic.

Return path matters too. The authoritative answer returns from authoritative server to recursive resolver, then from recursive resolver to the client stub, then into the browser. Only after the browser has a usable address does the web request leave for the origin, CDN, proxy, or load balancer. A DNS success therefore means “the browser got address data”; it does not prove the TCP, TLS, HTTP, CDN, or application path is healthy.

Operational checks for this exact path:

date -Is
getent hosts www.example.com
dig www.example.com A
dig www.example.com AAAA
dig +trace www.example.com
dig NS example.com
dig @<authoritative-ns> www.example.com A +norecurse
curl -vk --resolve www.example.com:443:<address> https://www.example.com/products

Use getent to test the local application-style resolver path, dig +trace to see delegation, authoritative queries to test zone truth, and curl --resolve to reuse the browser’s intended hostname while forcing a specific address for TCP/TLS/HTTP validation.

Records Operators Should Know

TTL and Caching

TTL is how long a resolver may cache a record. Lowering a TTL after clients have already cached the old higher TTL does not make those clients forget early. Lower TTL before a planned migration, wait out the old TTL, then change the record.

Negative answers are cached too. RFC 2308 defines negative caching behavior. If you query a name before it exists, recursive resolvers can cache that negative result, so creating the record afterward may still appear broken until the negative TTL expires.

CNAME Chains

CNAMEs are common for SaaS, CDNs, and cloud load balancers. Each link in a chain can have a separate TTL and failure mode. A query for A records can return a CNAME and then require more lookups to reach final A/AAAA records.

Operational advice:

• Keep chains short.
• Avoid CNAMEs at zone apex unless your provider implements flattening or ALIAS-style behavior.
• Remember that the authoritative server for the original name and the target name may be different.

Delegation and Glue

Delegation happens at a zone boundary. The parent publishes NS records for the child zone. If a nameserver is inside the zone it serves, the parent also needs glue address records so resolvers can reach it.

Example: if example.com is served by ns1.example.com, the .com zone needs glue for ns1.example.com. Without glue, resolution can become circular.

Split-Horizon DNS

Split-horizon DNS returns different answers depending on the client, network, or resolver path. It is common for private services and hybrid cloud. It also creates confusion:

• dig from a laptop and from a Pod may get different answers.
• Public resolvers may see public data while corporate resolvers see private data.
• Conditional forwarding must be tested from the actual network path that applications use.

DNSSEC

DNSSEC signs DNS data so validating resolvers can detect tampering. It does not encrypt DNS. Common failure modes are expired signatures, DS/DNSKEY mismatch during migration, and forgetting to update DS records at the registrar.

Kubernetes DNS Tie-In

Kubernetes Service discovery is DNS-heavy. CoreDNS watches Services and EndpointSlices and serves names such as:

service.namespace.svc.cluster.local

If Pods use a search list and ndots, a lookup for an external name may first try several cluster-local suffixes. This can add latency and load to CoreDNS.

Debugging Method

1. Query the same resolver the application uses.
2. Query authoritative servers directly.
3. Check A and AAAA.
4. Check CNAME chains.
5. Check TTLs and negative cache possibilities.
6. Check delegation from the parent.
7. Check DNSSEC validation if only validating resolvers fail.
8. Check search paths and /etc/resolv.conf in containers.
9. Check response code, EDNS size, and UDP versus TCP behavior for large or signed answers.

Commands

dig example.com A
dig example.com AAAA
dig +trace example.com
dig @1.1.1.1 example.com
dig NS example.com
dig SOA example.com
dig +dnssec example.com

Study Cards

Practice Deck

References

• RFC 1034: Domain Names - Concepts and Facilities
• RFC 1035: Domain Names - Implementation and Specification
• RFC 2308: Negative Caching of DNS Queries
• RFC 4033: DNS Security Introduction and Requirements
• RFC 6891: Extension Mechanisms for DNS
• Cloudflare: How DNS works