DNS

Definition

The Domain Name System (DNS) is the hierarchical, distributed naming service of the Internet — specified by RFCs 1034 and 1035 in 1987 and continuously extended since — that maps human-readable names like example.com to the data needed to reach a service: IPv4 and IPv6 addresses, mail-exchanger hosts, service endpoints, certificate-authority authorisations, cryptographic trust anchors, and arbitrary text. Every TCP connection, every HTTPS request, every git pull, every email delivery, and almost every TLS handshake begins with a DNS lookup; without DNS the Internet is a phone book of IP literals. DNS is implemented as a delegation tree rooted at . (the "root zone"), traversed by recursive resolvers on behalf of clients and answered by authoritative servers that own each branch.

Why it matters

DNS is the single most-used naming layer in computing — billions of queries per second flow through it — and it sits on the critical path of practically every networked operation. A misconfigured MX record drops your mail; a missing CAA record blocks certificate issuance; a stale A record sends users to a decommissioned host long after the cutover; a wrong TTL on a planned migration extends downtime by hours. Beyond name-to-address resolution, DNS now carries policy (SPF, DKIM, DMARC, MTA-STS), service discovery (SRV, SVCB/HTTPS for HTTP/3 + ECH), CDN steering (anycast + EDNS Client Subnet), and the chain of trust that PKI itself increasingly leans on — since March 2026 the CA/B Forum requires DNSSEC validation during certificate issuance (Ballot SC-085v2). Understanding DNS resolution, caching, and failure modes is the difference between debugging a flaky deploy in minutes and chasing ghosts for a day.

How it works

A lookup walks the delegation hierarchy from the root down. When a client resolves www.example.com, the OS stub-resolver hands the question to a recursive resolver (typically the LAN gateway, an ISP server, or a public service like 1.1.1.1, 8.8.8.8, 9.9.9.9). The recursor — if it has nothing cached — does the legwork:

1. Ask a root server (a.root-servers.net … m.root-servers.net, 13 named anycast clusters); the root delegates .com to the TLD nameservers.
2. Ask a TLD authoritative server (a.gtld-servers.net …); the TLD delegates example.com to that zone's nameservers via NS records.
3. Ask the authoritative nameserver for example.com; it returns the answer for www.example.com with the AA (Authoritative Answer) flag set (RFC 1034 §6.2.1).
4. The recursor caches each response for the record's TTL and hands the answer back to the stub.

The wire format is the same OPT-extended message (originally UDP/53, falling back to TCP/53 for large responses) defined in RFC 1035 and extended by EDNS(0) (RFC 6891) to lift the 512-byte UDP cap, signal capabilities, and carry Client Subnet (ECS) and Extended DNS Errors (EDE).

Records you will meet daily — every entry is an (owner, class, type, TTL, RDATA) tuple:

Type	Purpose	RFC
A	IPv4 address	1035
AAAA	IPv6 address	3596
CNAME	Alias to another name (one per owner; not at apex)	1035
MX	Mail exchanger + priority	1035 / 7505
TXT	Free-form text — SPF, DKIM, DMARC, ACME challenges	1035
NS	Delegation to authoritative servers	1035
SOA	Zone metadata (serial, refresh, retry, expire, minimum)	1035
SRV	Service location (host + port + priority + weight)	2782
CAA	CA authorisation for TLS issuance	8659
PTR	Reverse mapping — IP → name via in-addr.arpa / ip6.arpa	1035
DS / DNSKEY / RRSIG / NSEC(3)	DNSSEC chain-of-trust	4033–4035, 5155
SVCB / HTTPS	Service binding — ALPN, port, IP hints, ECH config	9460

Encrypted transports (all interchangeable from the resolver's perspective, just different wire encapsulations):

Protocol	Transport	RFC	Notes
Do53	UDP/TCP 53, cleartext	1035	Legacy; on-path observers see every query
DoT — DNS over TLS	TLS 853	7858	Stub-to-resolver privacy; long-lived TCP
DoH — DNS over HTTPS	HTTPS 443 (HTTP/2 or HTTP/3)	8484	Mixes with web traffic, hard to block selectively
DoQ — DNS over QUIC	QUIC 853	9250	Per-query streams remove head-of-line blocking; ~20% lower median latency than DoT in 2024–25 measurements

DNSSEC layers a cryptographic chain of trust on top: each zone signs its RRsets with RRSIG, publishes DNSKEYs, and the parent zone publishes a DS (Delegation Signer) hash of the child's KSK — anchoring the chain at the root's KSK-2017 trust anchor. About 38% of global DNS queries are DNSSEC-validated as of 2026. Use delv (the modern replacement for dig +sigchase) to walk the chain.

Extended DNS Errors (EDE, RFC 8914) finally give resolvers a structured way to say why SERVFAIL happened. The IANA registry now lists 30+ codes — DNSSEC validation failures (1, 2, 5–12), filtered/blocked (15–18), stale answer served (3), forged answer (4), and so on. BIND 9.20, Unbound, Knot, and PowerDNS Recursor all emit EDE; dig displays them on a separate line as ; EDE: <code> (<purpose>): <extra-text>.

Common pitfalls

1. TTL surprise during cutovers. A 24-hour A record TTL means stragglers keep hitting the old host for a day after you flip it. Fix: drop the TTL to ≤ 5 minutes 48 hours before the change, then raise it again afterwards.
2. CNAME at zone apex is illegal. RFC 1034 forbids a CNAME alongside other RRtypes, and the apex always has SOA/NS. Use ALIAS/ANAME at the provider level, or the new HTTPS/SVCB records (RFC 9460) that do work at the apex.
3. Forgetting the trailing dot. In zone files and many APIs, www is relative (www.example.com. after $ORIGIN expansion), but www.example.com without the dot becomes www.example.com.example.com. — a classic silent breakage.
4. Stale glue and lame delegation. When you change nameservers but the parent zone still points to the old IPs, queries chase ghosts. Verify with dig +trace and the registry's WHOIS NS list.
5. SERVFAIL interpreted as "DNS is down". It usually means DNSSEC validation failed, an upstream timed out, or a filter blocked the name. Re-run with +cd (checking-disabled) to bypass DNSSEC, and inspect EDE for the real reason.
6. Trusting /etc/hosts to override DNS for everything. Browsers using DoH (Firefox, Chrome) bypass the OS resolver entirely, so hosts edits silently stop working. Disable DoH in the browser or use the system's secure-DNS setting.
7. Caching at the wrong layer. Negative caching (SOA.minimum, RFC 2308) means a typo'd lookup is remembered for as long as the SOA's minimum — often hours. Flush with sudo resolvectl flush-caches (systemd), sudo killall -HUP mDNSResponder (macOS), or ipconfig /flushdns (Windows).
8. Geo-steering blind spots without ECS. Public resolvers like 1.1.1.1 don't forward EDNS Client Subnet by default, so geo-DNS CDNs route based on the resolver's location, not the client's. Test with dig @8.8.8.8 +subnet=<your-prefix>.

Where to go next

Companion cheat sheets and concepts that put DNS to work:

• /sections/linux/dig — the canonical query tool: every flag, record type, +trace, +dnssec, +norecurse, and EDE display.
• /sections/windows/nslookup — the built-in Windows equivalent, interactive and non-interactive forms, plus the modern Resolve-DnsName PowerShell cmdlet.
• /sections/os/networking-stack — where DNS sits in the OSI / TCP-IP stack, how getaddrinfo() reaches the resolver, and why DNS uses both UDP and TCP.
• /sections/linux/ip — once DNS gives you an address, ip is how Linux configures, routes, and inspects it.
• /sections/linux/ssh-tunnels — port forwarding that depends on (and sometimes works around) DNS resolution, including -D SOCKS with remote DNS.
• /sections/osx/networksetup — the macOS way to script DNS resolvers, search domains, and per-service network configuration.

Sources

References consulted while writing this concept page. Links open in a new tab.

• RFC 1034 — Domain Names: Concepts and Facilities — Original architectural specification; source for the delegation-tree model and the AA-bit semantics.
• RFC 1035 — Domain Names: Implementation and Specification — Wire format, message structure, and the 512-byte UDP cap that EDNS later lifted.
• RFC 9460 — SVCB and HTTPS Resource Records — Defines the modern service-binding records used for HTTP/3 advertisement, ALPN hints, port overrides, and Encrypted Client Hello config.
• RFC 8914 — Extended DNS Errors — Structured error codes carried in the OPT record's EDE option; underpins the "30+ EDE codes" claim and the BIND 9.20 emit behaviour.
• RFC 9250 — DNS over Dedicated QUIC Connections (DoQ) — The DoQ standard; basis for the protocol-comparison table and the head-of-line-blocking advantage over DoT.
• Wikipedia — DNSSEC — Chain-of-trust overview (DS → DNSKEY → RRSIG → RRset) and the current root trust-anchor lineage.
• CaptainDNS — CAs now require DNSSEC validation — Background on CA/B Forum Ballot SC-085v2 (effective March 2026) that ties TLS issuance to a valid DNSSEC chain.
• APNIC — Extended DNS Errors in the wild — Measurement-paper summary showing which EDE codes the public resolvers actually emit and at what rates.
• doggo — modern multi-protocol DNS client — Reference for the modern alternatives to dig mentioned in the "see also" links; supports Do53, DoH, DoT, DoQ, and DNSCrypt in one tool.
• dog — colourful Rust DNS client — Rust-based dig replacement; cited alongside doggo as the lineage of human-friendly CLIs.