DNS Explained: The Internet's Phone Book

The Domain Name System (DNS) is the internet's address translation service — the critical infrastructure that converts human-readable domain names like flyfishnwa.com into machine-readable IP addresses like 104.26.10.78. Without DNS, you would need to memorize long numeric addresses for every website you visit. Often called the "phone book of the internet," DNS is one of the oldest and most essential protocols in networking, and it plays a central role in how CDNs route content to users worldwide.

What Problem Did DNS Solve?

Before DNS existed, the early internet (then called ARPANET) used a single text file called HOSTS.TXT to map hostnames to IP addresses. Maintained by the Stanford Research Institute's Network Information Center (SRI-NIC), this file was manually updated and distributed to every connected machine. In the early 1980s, with only a few hundred hosts, this worked — barely.

By 1983, the system was breaking down. The file was growing rapidly, updates took days to propagate, name collisions were common, and the centralized architecture created a single point of failure. If SRI-NIC's server went down, no new name mappings could be distributed. The internet needed a distributed, scalable naming system.

In November 1983, Paul Mockapetris published RFC 882 and RFC 883, defining the Domain Name System. His design was elegant: a hierarchical, distributed database where responsibility for name resolution is delegated across a tree of authoritative servers. No single server holds all answers, but any query can find its way to the right answer by traversing the hierarchy. This architecture has scaled from hundreds of hosts in 1983 to over 350 million registered domains today.

How Does DNS Resolution Work Step by Step?

When you type flyfishnwa.com into your browser, a carefully orchestrated sequence of lookups occurs — typically completing in under 100 milliseconds:

1. Browser Cache Check: Your browser first checks its own DNS cache. If you've visited the site recently and the record's TTL (Time to Live) hasn't expired, the IP address is returned immediately — no network request needed.
2. Operating System Cache: If the browser cache misses, the OS-level DNS resolver (called the "stub resolver") checks its cache. On Linux, this is managed by systemd-resolved; on macOS, by mDNSResponder.
3. Recursive Resolver Query: If no cached answer exists locally, the query goes to a recursive resolver — typically operated by your ISP or a public service like Google Public DNS (8.8.8.8), Cloudflare DNS (1.1.1.1), or Quad9 (9.9.9.9).
4. Root Server Query: The recursive resolver contacts one of the 13 root server clusters (labeled A through M). These servers don't know the IP address of flyfishnwa.com, but they know which servers are authoritative for the .com TLD and return a referral.
5. TLD Server Query: The resolver contacts a .com TLD server (operated by Verisign), which returns the authoritative nameservers for flyfishnwa.com.
6. Authoritative Server Query: Finally, the resolver contacts the authoritative nameserver for flyfishnwa.com, which returns the actual IP address (the A record for IPv4, or AAAA record for IPv6).
7. Response Caching: The recursive resolver caches this answer according to the record's TTL (commonly 300 seconds to 86,400 seconds), and returns it to your browser. Future queries from any user on the same resolver skip steps 4-6.

What Are the Most Important DNS Record Types?

How Do CDNs Use DNS for Traffic Routing?

DNS is the primary mechanism CDNs use to direct users to the optimal edge server. When a website uses a CDN, its DNS records point to the CDN's infrastructure rather than directly to the origin server. The CDN's authoritative DNS then uses several techniques to select the best edge server:

• GeoDNS: The CDN's DNS server identifies the geographic location of the recursive resolver (using its IP address) and returns the IP of the nearest edge server. A user in Tokyo gets directed to a Tokyo PoP, while a user in London gets directed to a London PoP. This technique is fundamental to CDN geo-routing strategies.
• EDNS Client Subnet (ECS): Traditional GeoDNS routes based on the resolver's location, which can be inaccurate when users use public resolvers like 8.8.8.8. EDNS Client Subnet (RFC 7871) allows the resolver to include a portion of the client's IP address in the DNS query, letting the CDN route based on the actual user's location rather than the resolver's.
• Low TTL: CDNs typically set DNS TTLs to 30-300 seconds (compared to hours or days for traditional DNS). This enables rapid failover: if an edge server goes down, the CDN's DNS stops returning its IP within seconds, and subsequent queries are routed to healthy servers. Understanding DNS propagation and TTL is essential for CDN operations.
• Anycast DNS: Major CDN providers use anycast for their own DNS infrastructure, ensuring that DNS resolution itself is fast regardless of user location.

What Are the Major DNS Security Concerns?

DNS was designed in 1983 without encryption or authentication, creating several security vulnerabilities that persist today:

• DNS Cache Poisoning: An attacker injects fraudulent DNS records into a resolver's cache, redirecting users to malicious servers. The Kaminsky attack (2008) demonstrated this vulnerability could be exploited remotely, affecting millions of users.
• DNS Amplification DDoS: Attackers send small DNS queries with a spoofed source IP (the victim's) to open resolvers. The resolvers send large responses to the victim, amplifying the attack volume by 28-70x. CDN providers like Cloudflare have built DDoS protection services specifically to counter these attacks.
• DNS Hijacking: Attackers compromise authoritative DNS servers or registrar accounts to redirect traffic. This was demonstrated in the 2019 Sea Turtle campaign that targeted government and telecommunications organizations.

Modern countermeasures include:

• DNSSEC: Adds cryptographic signatures to DNS records, allowing resolvers to verify that responses haven't been tampered with.
• DNS over HTTPS (DoH): Encrypts DNS queries inside HTTPS connections, preventing eavesdropping and tampering by network intermediaries. Cloudflare (1.1.1.1) and Google (8.8.8.8) both support DoH.
• DNS over TLS (DoT): Similar to DoH but uses a dedicated port (853) for encrypted DNS queries, making it easier for network administrators to identify and manage DNS traffic separately from web traffic.

What Are Common DNS Problems and How to Fix Them?

Several DNS issues frequently affect website operators and CDN users:

• Propagation Delays: After changing DNS records, old cached values persist until their TTL expires across resolvers worldwide. This can take 24-72 hours for records with high TTLs. The solution is to lower TTLs well before making changes, make the change, then raise TTLs once confirmed.
• CNAME Flattening: The DNS specification prohibits CNAME records at the zone apex (e.g., example.com without www). CDN providers like Cloudflare solve this with "CNAME flattening" — resolving the CNAME at the DNS level and returning an A record to the client.
• DNS TTL for CDN Failover: Low TTLs enable fast failover but increase DNS query volume. Most CDNs recommend 300-second TTLs as a balance between failover speed and query efficiency. Some CDN providers handle failover within their own anycast network, making client-facing TTL less critical for availability.