DNS Hierarchy: Root, TLD, and Authoritative Nameservers
The Domain Name System is a globally distributed hierarchical database organized as an inverted tree. At the top sit 13 logical root nameserver clusters (A through M), operated by different organizations and replicated via anycast to over 1,500 physical locations worldwide. Below the root are Top-Level Domain (TLD) nameservers, one set per TLD (.com, .org, .net, country-code TLDs). Below TLD servers sit authoritative nameservers, which hold the actual DNS records for registered domains. When a resolver needs to resolve example.com it starts at the root, which delegates to the .com TLD servers, which in turn delegate to the nameservers listed in example.com’s NS records, which finally answer with the A or AAAA record. This delegation chain is encoded in NS records at each level and is the mechanism by which DNS distributes authority across millions of independently operated domains without any central coordination. The root zone itself is managed by ICANN and the root zone maintainer (currently Verisign for the root zone file), and changes propagate via zone transfer to all root server operators.
Recursive Resolver: Stub Resolvers, Cache-First Lookup, and Root Priming
Most DNS queries originate from a stub resolver — a minimal DNS client built into the operating system — that knows only one thing: the IP address of a recursive resolver (typically provided by DHCP or manually configured). The stub sends all queries to the recursive resolver and expects a complete answer. The recursive resolver does the actual work: it checks its cache first, and if the answer is present and the TTL has not expired, it returns it immediately without any upstream queries. On a cache miss the resolver must walk the hierarchy. It starts with the root nameservers, whose IP addresses are compiled into the resolver software as a priming file (root.hints). The resolver sends a query to a root server and receives a referral to the TLD nameservers. It queries a TLD server and receives a referral to the authoritative nameservers. It queries the authoritative nameserver and receives the final answer. All intermediate results (NS records, glue A records for nameservers) are also cached with their respective TTLs so subsequent queries for the same zone skip earlier steps. A single recursive resolver serving many clients benefits from a warm cache: the more queries it handles, the higher its cache hit rate and the lower the average latency across all users.
Authoritative Nameserver: Zone Files, SOA Records, and Zone Transfer
The authoritative nameserver holds the ground truth for a zone. Zone data is stored in a zone file — a text file using the RFC 1035 master file format — containing all resource records (RRs) for the zone: A, AAAA, CNAME, MX, TXT, NS, and others. Every zone has a Start of Authority (SOA) record that carries administrative metadata: the primary nameserver hostname, the responsible party’s email address (encoded with a dot instead of @), a serial number, and timing parameters (refresh, retry, expire, and minimum TTL). The serial number is critical for zone transfer: secondary nameservers periodically poll the primary’s SOA record and compare the serial number. If the serial has incremented, the secondary initiates a zone transfer (AXFR for full transfer, IXFR for incremental transfer of only the changed records). TSIG (Transaction Signature) or DNSSEC signatures authenticate zone transfers to prevent a rogue server from impersonating the primary. DNS hosting providers have moved beyond static zone files to database-backed systems with API-driven record management, where the zone file format is a rendering detail rather than the authoritative data store.
Caching and TTL: Negative Caching, TTL Tuning, and Propagation Tradeoffs
Caching is the mechanism that makes DNS scalable: without it, every DNS query in the world would ultimately reach the authoritative servers. Recursive resolvers cache every resource record with its TTL countdown. When the TTL reaches zero the record is evicted and the next query triggers a fresh lookup. TTL values are a deliberate tradeoff between propagation speed and origin load. A TTL of 300 seconds means a DNS change (pointing a domain to a new IP after a migration) propagates globally in at most 5 minutes — any cached copies will expire and resolvers will fetch the new value. A TTL of 86400 seconds (one day) means changes take up to 24 hours to propagate but the authoritative server receives far fewer queries. Best practice for planned migrations is to lower TTLs to 60–300 seconds well before the cutover, perform the switch, and then raise TTLs back after confirming the change is correct. Negative caching (RFC 2308) applies to NXDOMAIN responses: a resolver caches the fact that a name does not exist for the duration specified in the SOA’s minimum TTL field, preventing repeated queries for nonexistent names from hammering authoritative servers.
Anycast for Authoritative Nameservers: BGP Announcement and Stateless Protocol Benefits
DNS is a UDP protocol (with TCP fallback for large responses and zone transfers), and UDP is stateless — each query-response pair is independent with no connection state. This property makes DNS uniquely well-suited to anycast routing. The operator announces the same IP address from multiple physical locations via BGP. Internet routers forward DNS queries toward the topologically nearest announcement, so a query from a user in Asia reaches the Asian PoP while a query from Europe reaches the European PoP. Each location handles queries for the same zone independently, with no coordination required between locations because there is no session state to synchronize. If a PoP goes offline, BGP withdraws its announcement and queries reroute to the next-nearest location within seconds, providing automatic failover without any application-level health checks. Authoritative DNS operators like NS1, Route 53, and Cloudflare operate dozens to hundreds of anycast PoPs, keeping authoritative query latency well under 10ms for most users globally. The occasional split-brain issue — where routing changes cause a query to reach a different PoP mid-resolution for TCP fallback — is handled by ensuring all PoPs serve identical zone data, typically through a distributed database with synchronous replication or a central zone publishing system.
DNSSEC Validation: Signatures, Key Hierarchy, and Authenticated Denial
DNSSEC adds cryptographic authentication to DNS responses, protecting against cache poisoning attacks where a malicious resolver injects forged records. Each zone signs its resource record sets (RRsets) with its Zone Signing Key (ZSK), producing RRSIG records that accompany the RRset in responses. The zone also publishes its DNSKEY records (the public key material) so validators can verify the signatures. The chain of trust works through DS (Delegation Signer) records: a parent zone publishes a DS record containing a hash of the child zone’s Key Signing Key (KSK). A validator resolving example.com starts by trusting the root zone’s DNSKEY (the trust anchor, distributed with resolver software and updated infrequently). It verifies the root’s signature over the .com DS record, then the .com zone’s signature over example.com’s DS record, then example.com’s KSK’s signature over its ZSK, and finally the ZSK’s signature over the queried RRset. Authenticated denial of existence uses NSEC or NSEC3 records to prove that a name does not exist without exposing the full zone contents to enumeration (NSEC3 adds hashing to prevent zone walking). DNSSEC validation is computationally expensive relative to plain DNS, which is why it typically runs at the recursive resolver rather than the stub.
DNS-Based Load Balancing: Round-Robin, Weighted Records, GeoDNS, and Health Checks
DNS is a natural load-balancing primitive because the authoritative server controls which IP addresses a name resolves to and can vary that answer per query. The simplest form is round-robin: return multiple A records and rotate the order with each response, relying on the client to use the first record. Weighted records assign different weights to each IP, so a server with twice the capacity receives twice the traffic. GeoDNS (or latency-based routing in Route 53 terms) inspects the source IP of the recursive resolver and returns different record sets based on the resolver’s inferred geographic region — European resolvers get European IPs, Asian resolvers get Asian IPs. Health-check-driven record removal closes the loop: a health-checking system continuously probes each backend and removes its A record from DNS responses when it fails, typically within one TTL window. The combination of GeoDNS and health checks is how global services like AWS Route 53 Latency Routing and Cloudflare Load Balancing implement active-active multi-region deployments. The fundamental limitation of DNS-based load balancing is that clients and intermediate resolvers cache responses for the TTL duration, so you cannot react faster than your TTL when removing a failed server — low TTLs are essential for health-check-driven routing to be effective.
DNS over HTTPS and DNS over TLS: Encrypted Resolution and Privacy
Traditional DNS sends queries and responses in plaintext over UDP port 53, making them visible to any observer on the network path — ISPs, corporate network administrators, and adversaries who can see traffic. DNS over TLS (DoT, RFC 7858) wraps DNS in a standard TLS connection on port 853, encrypting the query and response from the stub resolver to the recursive resolver. DNS over HTTPS (DoH, RFC 8484) encodes DNS queries as HTTPS requests to a well-known URL (typically https://resolver/dns-query), making DNS traffic indistinguishable from ordinary web traffic and bypassing firewalls that block port 853. Both protocols provide confidentiality (an observer sees only that you contacted a DNS resolver, not what you queried) and integrity (TLS prevents tampering). From an infrastructure perspective, DoH and DoT require the recursive resolver to terminate TLS, which adds CPU cost and connection overhead relative to UDP. Large resolver operators (Cloudflare 1.1.1.1, Google 8.8.8.8) have absorbed this cost. Resolver discovery — how a stub learns the DoH URL of its assigned resolver — is addressed by DHCP option 252 for DoH and an ALPN-based mechanism for DoT, though both are still being standardized and adoption is uneven across operating systems and network equipment.
See also: Scale AI Interview Guide 2026: Data Infrastructure, RLHF Pipelines, and ML Engineering