How DNS Works - A Complete Guide to Name Resolution

DNS - How the Internet's Phone Book Actually Works

Type example.com into your browser and the site appears almost instantly. But computers do not communicate using domain names - they use IP addresses (e.g., 93.184.216.34). The system that translates domain names into IP addresses is DNS (Domain Name System).

DNS was proposed in 1983 by Paul Mockapetris in RFC 882/883, replacing the previous HOSTS.TXT file that was manually maintained. At the time, the internet consisted of only a few hundred hosts, and a single text file managed by SRI-NIC mapped every hostname. DNS solved the scalability limits of that approach with a distributed, hierarchical system that remains one of the internet's most critical infrastructure components.

The very first step in the process of what happens when you type a URL is this DNS name resolution.

The Resolution Process - Four Stages of Lookup

When your browser needs the IP address for www.example.com, up to four stages of queries take place.

1. Local cache check: The OS cache is checked first, then the browser cache. If you have visited the domain recently, the answer is found here
2. Recursive resolver query: If the cache misses, the query goes to a recursive resolver - typically your ISP's DNS server or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1
3. Root server query: If the resolver's cache also misses, it queries a root server to learn which authoritative server handles the .com TLD
4. Authoritative server query: The .com TLD server responds with the authoritative server for example.com, which finally returns the IP address

This entire chain typically completes in 20-120 milliseconds. When the cache hits, resolution takes less than 1 millisecond.

Recursive vs. Iterative Queries

The query from your browser to the resolver is a recursive query - the client says "give me the final answer" and the resolver does all the legwork. In contrast, the queries from the resolver to root and authoritative servers are iterative: each server replies with "I don't know, but ask this server next," without taking responsibility for the final answer. This division of labor is what makes DNS scale to billions of queries per day.

DNS Caching - The Speed vs. Freshness Tradeoff

If every DNS lookup had to traverse the full chain from root servers down, the internet would grind to a halt. Caching is what makes DNS performant at global scale.

Every DNS record carries a TTL (Time To Live) value, specified in seconds, that dictates how long the record can be cached. A TTL of 3600 means the record is reused for one hour before the resolver must query again.

• Short TTL (60-300 seconds): DNS changes propagate quickly. Used by CDNs and failover configurations. The tradeoff is increased query volume to resolvers
• Long TTL (3600-86400 seconds): Reduces resolver load and speeds up resolution. The tradeoff is that DNS record changes take longer to take effect while stale caches persist

The phrase "DNS propagation" is commonly used but technically inaccurate. DNS changes do not "propagate" across the internet. What actually happens is that each resolver's cache expires according to the TTL, and the resolver fetches the updated record on the next query. By lowering the TTL before making a change, you can accelerate how quickly the new record is seen worldwide.

Root Servers - The Apex of the Internet

At the top of the DNS hierarchy sit 13 root server clusters, labeled A through M. A common misconception is that there are only 13 physical servers. In reality, Anycast technology distributes over 1,700 instances across the globe, ensuring low-latency access from virtually anywhere.

Root servers are coordinated by ICANN, with each cluster operated by a different organization. A and J are run by Verisign, B by USC-ISI, K by RIPE NCC, and M by the WIDE Project (centered at Keio University in Japan), among others.

The information root servers hold is surprisingly simple: delegation records for top-level domains. "Queries for .com go to this authoritative server. Queries for .jp go to that one." The entire root zone file is approximately 2 MB - a remarkably small dataset for a system that underpins the entire internet.

DNS Record Types

DNS supports a variety of record types, each storing a different kind of information.

TXT records were originally designed as a generic container for arbitrary text, but today they are heavily used for email authentication (SPF, DKIM, DMARC) and domain ownership verification. Google Search Console and Let's Encrypt certificate issuance both rely on TXT record verification. The CNAME record is also worth noting - it is the mechanism behind why typing "www" is no longer necessary for most websites, as it aliases the www subdomain to the root domain.

DNS Security and the Road Ahead

DNS was designed in 1983 with no security considerations. Queries and responses are sent in plaintext, meaning your ISP or anyone on the same network can see exactly which domains you are resolving.

Two technologies have emerged to address this: DNS over HTTPS (DoH) and DNS over TLS (DoT). DoH wraps DNS queries inside HTTPS, making them indistinguishable from regular web traffic. DoT encrypts queries over a dedicated port (853) using TLS.

DNSSEC (DNS Security Extensions) is another critical technology. It uses digital signatures to verify the authenticity of DNS responses, preventing cache poisoning and man-in-the-middle attacks. However, DNSSEC adoption remains low - even among .com domains, only about 3% have DNSSEC enabled. The fragility of DNS remains a challenge that directly impacts the security of the entire internet. To check whether your DNS queries are leaking to unintended resolvers, you can run a DNS leak test on IP確認さん.

For those who want to build a solid foundation in DNS and networking, computer networking books are an excellent starting point.