🌐 DNS Resolution — Recursive Lookup & Caching

The hierarchy has three levels below the recursive resolver. Root servers (there are 13 logical root server addresses, operated by organisations such as ICANN and Verisign, replicated to over 1,500 physical nodes via anycast) know nothing about individual domain names but point to the authoritative TLD servers. TLD servers (for .com, .uk, .org, etc.) hold NS records pointing to the authoritative name servers for each second-level domain. Authoritative servers hold the actual A, AAAA, MX, CNAME, and TXT records that resolve a name to a final value. The resolver performs iterative queries to each tier and collects referrals until it receives an authoritative answer.

Every internet action that uses a hostname triggers DNS. When you open a browser, send email, join a video call, or stream media, DNS runs silently in the background. CDN providers such as Cloudflare and Akamai use DNS to route users to the nearest edge node. Load balancers use DNS round-robin or weighted records to distribute traffic across servers. Cloud services use wildcard and CNAME records to map tenant subdomains dynamically. DNS is also exploited for email authentication (SPF, DKIM, DMARC all rely on TXT records) and for certificate validation (DNS-01 challenge in ACME/Let's Encrypt).

Classic DNS queries travel in plaintext UDP over port 53, meaning your ISP, network operators, and anyone on the path can see every hostname you look up, even if the subsequent HTTPS connection is encrypted. This is a common misconception — many people assume HTTPS protects their DNS. Modern alternatives such as DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) encrypt the DNS conversation, preventing passive surveillance. Browsers like Firefox and Chrome use DoH by default to a trusted resolver when enabled.

Paul Mockapetris designed DNS and published it in RFCs 882 and 883 in November 1983 while working at the USC Information Sciences Institute. The driving problem was the ARPANET's centrally maintained HOSTS.TXT file, which had to be manually downloaded by every host and was becoming unmanageable as the network grew past a few hundred nodes. DNS replaced it with a decentralised, hierarchical, automatically delegated system. The first operational root servers went live in 1984, and DNS has remained the internet's naming backbone ever since.

DNS sits within a broader networking and cryptography landscape. Hash functions underpin DNSSEC, the DNS security extension that digitally signs records to prevent cache poisoning — the SHA Hashing simulation on this site shows how those one-way functions work. Merkle Trees are used inside DNSSEC for authenticated denial-of-existence (NSEC3). BGP routing determines which physical path your DNS query travels across the internet, and packet routing simulations show how UDP datagrams are forwarded between routers before reaching a root server.

DevOps teams treat DNS as a first-class infrastructure concern. Short TTLs (30–60 s) are set before planned IP changes or failover events so that re-pointed records propagate quickly. Services such as AWS Route 53 and Cloudflare provide health-check-based failover that automatically removes unhealthy endpoints from DNS answers within seconds. Kubernetes uses CoreDNS as an in-cluster resolver so that service names like my-service.default.svc.cluster.local resolve to cluster-internal ClusterIP addresses without leaving the node. Split-horizon DNS lets internal and external clients receive different answers for the same name, enabling private network access.

Active research areas include encrypted DNS at scale: deploying DoH and DoT universally while preserving operators' ability to apply security policies and parental controls. DNSSEC adoption remains low (around 20% of domains are signed) partly because key-rollover complexity and NSEC zone-enumeration risks deter operators. Oblivious DNS over HTTPS (ODoH) and DNS over QUIC (DoQ, RFC 9250) aim to further reduce latency and improve privacy. Researchers are also studying how AI-based classifiers can detect DNS tunnelling and data exfiltration hidden inside TXT or NULL record payloads, which are increasingly used by malware for command-and-control communication.