Domain Name System (DNS)

The Domain Name System (DNS) is the distributed hierarchical database that translates human-readable hostnames like example.com into machine-routable IP addresses. Instead of relying on a single centralized database, which would quickly crash under the load of global internet traffic, DNS divides its namespace into a tree hierarchy.

This structure can be compared to a corporate directory system. If you want to contact an employee in a massive multinational corporation, you do not ask a single front-desk receptionist who has memorized all 100,000 employees' phone extensions. Instead, you ask the front desk receptionist (Root), who points you to the sales department floor directory (Top-Level Domain), who finally points you to the sales department administrator (Authoritative Nameserver) who maintains the specific desk list.

The tree hierarchy consists of three primary layers of nameservers:

• Root Nameservers: The root zone sits at the top of the hierarchy, represented as a trailing dot in a domain name (e.g., example.com.). There are 13 logical root server IP addresses globally, operated by organizations like ICANN, NASA, and the US Army, and distributed across hundreds of physical locations using Anycast routing. Root servers do not store IP addresses, they point resolvers to the appropriate Top-Level Domain (TLD) servers.
• Top-Level Domain (TLD) Nameservers: These servers manage specific extensions like .com, .org, and .net (generic TLDs), or .uk and .de (country code TLDs). The TLD servers maintain registry lists pointing to the authoritative nameservers for individual domains.
• Authoritative Nameservers: The final authority for a domain. These servers store the actual mapping records (such as IP addresses) for specific hostnames. When you configure DNS records at a domain registrar, you are defining which authoritative nameservers hold the records for your domain.

---

Locating an IP address involves two distinct querying modes: recursive and iterative resolution.

A recursive resolver (typically operated by your ISP, or public resolvers like Cloudflare's 1.1.1.1 and Google's 8.8.8.8) act as an agent on behalf of the client. The client machine sends a single recursive query: "Give me the IP address for example.com, do not return intermediate pointers." The recursive resolver manages the entire resolution loop, caching the results to accelerate subsequent lookups.

If the recursive resolver does not have the mapping cached, it executes an iterative resolution flow, querying each level of the DNS tree step by step:

1. The resolver queries a Root Nameserver, requesting the IP of example.com.
2. The Root Nameserver returns the IP addresses of the .com TLD Nameservers.
3. The resolver queries the .com TLD Nameserver for example.com.
4. The TLD Nameserver returns the IP addresses of the Authoritative Nameservers for example.com.
5. The resolver queries the Authoritative Nameserver.
6. The Authoritative Nameserver returns the A record containing the IP address (e.g., 93.184.216.34).
7. The resolver returns this IP to the client.

---

DNS hosts store maps called resource records (RRs). The most common record types used in web infrastructure are:

• A (Address): Maps a hostname to an IPv4 address (e.g., example.com -> 93.184.216.34).
• AAAA (IPv6 Address): Maps a hostname to a 128-bit IPv6 address (e.g., example.com -> 2606:2800:220:1:248:1893:25c8:1946).
• CNAME (Canonical Name): Creates an alias pointing one hostname to another. A CNAME lookup forces the resolver to restart its query sequence using the target hostname.
• NS (Nameserver): Identifies which authoritative nameservers hold records for the domain.
• MX (Mail Exchange): Directs email traffic to the appropriate mail servers.
• TXT (Text): Stores arbitrary text-based metadata, often used to verify domain ownership (e.g., SPF, DKIM, and Google Site Verification).

---

To prevent network bottlenecking, DNS relies heavily on multi-level caching. When a resolver receives a record, it stores it locally for a duration defined by the record's Time-To-Live (TTL) value, expressed in seconds.

DNS records are cached at several layers:

• Browser Cache: Web browsers store records to avoid system-level calls.
• OS Cache: The operating system kernel maintains a local cache (accessible via commands like ipconfig /displaydns or systemd-resolved).
• Local Router Cache: Home or office routers cache lookups for local network speed.
• Recursive Resolver Cache: Managed by your ISP or DNS provider.

Propagation Delays and Cache-Busting

When you update a DNS record, it does not instantly apply worldwide. Resolvers that have cached the old record will continue serving it until their local TTL timers expire, a phenomenon known as DNS propagation delay.

If you plan to migrate server IPs, you should lower the TTL of the target records (e.g., from 86,400 seconds to 300 seconds) a few days in advance. This ensures that when you execute the migration, resolvers will fetch the new IP address within 5 minutes rather than caching the old one for a full day.

---

DNS can be used to optimize global traffic routing before a client ever connects to an application server.

Geolocation-Based Routing

Authoritative nameservers can evaluate the incoming IP address of the recursive resolver. Using IP geolocation databases, the nameserver responds with the IP address of the data center physically closest to the client, minimizing network latency.

Anycast DNS

With Anycast, multiple physical nameservers distributed worldwide advertise the exact same IP address using the Border Gateway Protocol (BGP). The internet routing infrastructure automatically routes the client's UDP packets to the topologically closest server instance, enhancing reliability and DDoS resistance.

---

DNS historically operated almost exclusively over UDP on port 53.

The 512-Byte Limit and TCP Fallback

The original DNS specification limited UDP packet payloads to 512 bytes to prevent packet fragmentation over early WAN infrastructure. If a DNS response (such as a query returning multiple IPv6 records and DNSSEC signatures) exceeded 512 bytes, the nameserver truncated the packet and set the truncation (TC) flag in the header. Upon seeing this flag, the resolver fell back to establish a TCP connection on port 53 to retry the query.

EDNS0

To prevent the latency overhead of TCP handshakes, the Extension Mechanisms for DNS (EDNS0) protocol was introduced. EDNS0 allows resolvers to advertise their supported buffer size in the query, enabling nameservers to send UDP payloads up to 4,096 bytes without truncation.

---

Traditional DNS queries are sent in plaintext, making them vulnerable to eavesdropping, tampering, and ISP injection attacks. Modern security protocols encrypt this traffic:

• DNS over TLS (DoT): Wraps raw DNS queries inside a TLS tunnel on port 853, encrypting all traffic between the resolver and the client.
• DNS over HTTPS (DoH): Encapsulates DNS queries as standard HTTP/2 or HTTP/3 request streams on port 443. Because DoH traffic looks identical to standard HTTPS web traffic, it bypasses network firewalls and prevents ISPs from monitoring lookup history.

---

• RFC 1034: Domain Names - Concepts and Facilities — The primary RFC establishing the architectural principles of DNS.
• RFC 1035: Domain Names - Implementation and Specification — Detailed specifications for packet formats and resolution algorithms.
• How Anycast Works — Architectural overview of Anycast routing for globally distributed DNS resolvers.
• RFC 6891: Extension Mechanisms for DNS (EDNS0) — Standard specifications for high-capacity UDP DNS packets.