How the Domain Name System (DNS) Resolves Names Across the Planet

Every single second of every day, humans initiate hundreds of millions of connections across the global internet. You type wikipedia.org into a search bar, click a link to a news article, or open a messaging application.

Yet underneath the polished glass screens and clean browser windows, the internet cannot route a single packet of data to a human-readable text name.

The hardware routers, optical switches, and transatlantic undersea cables that form the backbone of the global network understand only numbers: 32-bit binary IPv4 addresses like 198.35.26.96 or 128-bit IPv6 hexadecimal strings like 2620:0:862:ed1a::1 (see How Packets Travel Across the Internet).

If humans were forced to memorize a twelve-digit numerical sequence for every website, email server, and mobile app API they used, the internet would have remained a niche academic curiosity.

The system that bridges the gap between human language and binary machine routing is the Domain Name System (DNS). It is often described as the "phonebook of the internet," but that simple metaphor completely fails to convey the sheer scale of the engineering miracle.

DNS is not a monolithic database sitting in a server room in Silicon Valley. It is a globally distributed, hierarchical, federated database containing billions of records, operated by thousands of independent entities, answering over two trillion queries every day—all while delivering answers in less than 30 milliseconds.

How does a query travel from your home laptop to find the authoritative owner of a domain name? Why are there nominally only 13 root server IP addresses in the entire world? And how does the global internet keep this system secure against hackers attempting to hijack banking and government traffic?

---

1. The ARPANET Bottleneck: The Collapse of HOSTS.TXT

To understand why DNS was built the way it was, we must look at how the early network functioned in the 1970s.

On the early ARPANET—the military and academic predecessor of the modern internet—there were only a few hundred computers connected. The mapping of computer names to numerical addresses was managed by a single human being: Elizabeth Feinler, affectionately known to network pioneers as Jake.

Feinler and her team at the Stanford Research Institute Network Information Center (SRI-NIC) maintained a single text file named:

HOSTS.TXT

Whenever a computer scientist at MIT, UCLA, or DARPA added a new mainframe to the network, they telephoned or emailed Feinler’s office during California business hours. Feinler’s team manually edited the text file, adding a line like:

10.0.0.51    MIT-MULTICS
10.2.0.72    UCLA-HOST

Every night, every mainframe computer on the ARPANET established an FTP connection to SRI-NIC, downloaded the updated HOSTS.TXT file, and stored it locally on disk.

               THE CENTRALIZED ARPANET HOSTS.TXT MODEL
               
    UCLA Mainframe ──┐
    MIT Multics    ──┼──[ Nightly FTP Download ]──► [ SRI-NIC Central Server ]
    DARPA PDP-11   ──┘                              (Maintained by Jake Feinler)

By the early 1980s, the microcomputer revolution and local area networks (LANs) caused the network to explode. The centralized HOSTS.TXT system broke down completely under three insurmountable bottlenecks:

1. Bandwidth Saturation: As thousands of computers tried to download the file simultaneously, the SRI-NIC server’s network connection choked, consuming massive amounts of ARPANET capacity just to distribute a list of names.
2. Name Collisions: No two computers on the entire network could share a name. If Stanford added a computer called MAIL, no university or laboratory in the world could ever name a computer MAIL again!
3. Operational Latency: If a server changed its network address, it took days for the update to be submitted, approved, edited, and downloaded across the world. In the meantime, messages to that computer failed.

In 1983, computer scientist Paul Mockapetris, working under the guidance of internet pioneer Jon Postel at USC's Information Sciences Institute, set out to design a replacement.

Mockapetris realized that no centralized authority could ever scale to a global network. Instead, the internet needed a hierarchical, distributed, and federated namespace where authority could be delegated recursively. In 1983, he published RFC 882 and RFC 883 (formalized in 1987 as RFC 1034 and RFC 1035).

The Domain Name System was born.

---

2. The Inverted Tree: Hierarchical Naming Architecture

The core conceptual breakthrough of DNS is that it organizes all hostnames on Earth into an inverted tree structure, reading from right to left.

Consider a fully qualified domain name (FQDN):

api.thisishowitworks.in.

Notice that subtle trailing dot at the very end: .. Most web browsers hide it automatically, but in the formal architecture of DNS, that dot is the absolute foundation of the entire system: The DNS Root.

                                  [ . ] (Root Zone)
                                    │
               ┌────────────────────┼────────────────────┐
               ▼                    ▼                    ▼
            [ com ]              [ org ]              [ in ] (Top-Level Domains)
               │                                         │
        [ example.com ]                      [ thisishowitworks.in ] (Second-Level Domains)
               │                                         │
      [ www.example.com ]                    [ api.thisishowitworks.in ] (Subdomains)

The hierarchy consists of four distinct levels:

Level 1: The Root Zone (.)

The apex of the entire tree. The root does not know the IP address of any specific website; it only knows who is responsible for each Top-Level Domain. If you ask the root about a .in domain, it replies: "I don't know that specific website, but here are the authoritative nameservers that manage the .in registry."

Level 2: Top-Level Domains (TLDs)

The broad extensions directly below the root. TLDs are categorized into:

• Generic TLDs (gTLDs): .com, .org, .net, .edu, and newer strings like .app or .tech.
• Country-Code TLDs (ccTLDs): Two-letter geographical country designations like .in (India), .uk (United Kingdom), .de (Germany), and .jp (Japan).

Each TLD is operated by a dedicated Registry under contract with the Internet Corporation for Assigned Names and Numbers (ICANN). For example, Verisign operates .com and .net, while the National Internet eXchange of India (NIXI) operates .in.

Level 3: Second-Level Domains (SLDs)

The unique name registered by an individual, company, or institution (e.g., thisishowitworks in thisishowitworks.in). The registrant has complete administrative control over this zone, deciding which servers host its website and email.

Level 4: Subdomains

Administrative partitions created by the domain owner (e.g., api, www, mail, auth). The domain owner can delegate subdomains to third-party cloud providers (like AWS, Cloudflare, or Vercel) without consulting ICANN or the registry.

This inverted tree architecture guarantees that no single entity needs to know everything. The root only delegates to TLDs; TLDs only delegate to second-level domains; and second-level domains delegate to hostnames. Authority is distributed cleanly across the globe.

---

3. The 13 Root Server Clusters and the Magic of BGP Anycast

At the pinnacle of this inverted tree sits the most famous number in internet infrastructure: 13.

If you inspect the configuration files of any operating system or DNS software, you will find a hardcoded list of 13 root server clusters, designated alphabetically from:

a.root-servers.net  (198.41.0.4, 2001:503:ba3e::2:30)
b.root-servers.net  (170.247.170.2, 2801:1b8:10::b)
...
m.root-servers.net  (202.12.27.33, 2001:dc3::35)

Why 13? Why not 50, or 500?

The 512-Byte UDP Constraint

The number 13 was not a political compromise; it was a rigid mathematical constraint imposed by computer networking in the 1980s.

DNS was designed to run primarily over UDP (User Datagram Protocol) on Port 53. Unlike TCP, UDP does not require a three-way handshake (SYN → SYN-ACK → ACK), making it blazingly fast. A DNS lookup requires only a single packet sent, and a single packet received.

However, in the original IPv4 specification (RFC 791), the maximum transmission unit that all internet networks were guaranteed to pass without fragmentation was 576 bytes.

Subtracting the 20-byte IP header and the 8-byte UDP header leaves exactly 512 bytes for the DNS payload.

Mockapetris and Postel calculated:

• Each root server requires its hostname (a.root-servers.net), an IPv4 address (4 bytes), and binary protocol headers.
• To fit all root server addresses into a single 512 byte UDP reply packet with room for protocol flags:

If they had added a 14th root server, the response packet would have exceeded 512 bytes, triggering IP packet fragmentation or forcing fallback to slow TCP connections.

    ┌───────────────────────── 512 Bytes UDP Payload ─────────────────────────┐
    │ 13 Root Server Names + 13 IPv4 Addresses + Resource Record Flags & TTLs │
    └─────────────────────────────────────────────────────────────────────────┘

The Anycast Revolution: From 13 Machines to 1,700+ Data Centers

If the entire global internet truly depended on only 13 physical computers, a single distributed denial-of-service (DDoS) attack or an earthquake in Virginia would take down world communications.

In reality, there are 13 root IP addresses, but there are over 1,700 physical root server instances distributed across more than 130 countries!

This is achieved using BGP Anycast:

Under standard unicast routing, every IP address belongs to exactly one physical network interface.

Under Anycast, dozens or hundreds of servers across North America, Europe, Asia, Africa, and South America all announce the exact same IP address to the global internet via BGP (Border Gateway Protocol).

When your router sends a packet to 193.0.14.129 (k.root-servers.net, operated by RIPE NCC), global routers automatically forward the packet along the shortest topological path. If you are in Mumbai, your query routes to an anycast node in Mumbai; if you are in Frankfurt, it routes to Frankfurt.

Anycast turns a potential single point of failure into a virtually indestructible global mesh.

---

4. The Resolution Journey: Recursive Resolvers vs. Iterative Queries

When you enter a web address, what actually happens across the wire?

To understand this journey, we must distinguish between the two types of DNS actors:

• Stub Resolver: A lightweight software library built into your computer's operating system (macOS, Windows, Linux, iOS, Android). It does not know how to traverse the global tree; it simply asks for help.
• Recursive Resolver (or Full Resolver): A high-performance server operated by your Internet Service Provider (ISP) or public providers like Cloudflare (1.1.1.1) or Google (8.8.8.8). Its job is to do the heavy lifting of hunting down the answer.
• Authoritative Nameserver: A server that holds the genuine, source-of-truth record for a domain.

Let us trace what happens when you type https://www.example.com into your browser:

               THE COMPLETE ITERATIVE RESOLUTION CHAIN
               
   Client Device                Recursive Resolver                 Root Nameserver
     (Browser)                     (e.g., 1.1.1.1)                      ( . )
         │                               │                                │
         │─── 1. Recursive Query ───────►│                                │
         │    "What is www.example.com?" │                                │
         │                               │─── 2. Iterative Query ────────►│
         │                               │◄── 3. Referral to .com ────────┘
         │                               │
         │                               │      .com TLD Nameserver
         │                               │               │
         │                               │─── 4. Query ──►│
         │                               │◄── 5. Referral to example.com
         │                               │
         │                               │      Authoritative Nameserver
         │                               │          (ns1.example.com)
         │                               │               │
         │                               │─── 6. Query ──►│
         │                               │◄── 7. Answer: 93.184.216.34
         │                               │
         │◄── 8. Final Resolved IP ──────┘

Step 1: The Local Check

Before sending a single packet out to the network, your computer checks its local memory:

1. Browser Cache: Did you visit this website in the last 60 seconds?
2. Operating System Cache: Does the OS DNS cache hold a recent translation?
3. Hosts File: Does /etc/hosts (or C:\Windows\System32\drivers\etc\hosts) have an explicit manual mapping?

If all three miss, the stub resolver constructs a UDP datagram and fires a Recursive Query to its configured recursive resolver (e.g., 1.1.1.1).

Step 2: The Referral to the Root

The recursive resolver receives the query: "What is the IP of www.example.com?" Assuming its cache is completely empty, the recursive resolver cannot answer. It must perform a series of Iterative Queries:

• The recursive resolver contacts one of the 13 root server anycast addresses (e.g., a.root-servers.net).
• The root server does not have the IP address for www.example.com.
• Instead, the root server responds with an Iterative Referral: a list of authoritative nameservers for the .com TLD (along with their IP addresses, called Glue Records).

Step 3: The Referral to the TLD Registry

The recursive resolver now contacts a .com TLD nameserver (operated by Verisign):

• "What is the IP of www.example.com?"
• Verisign’s .com nameserver does not know the internal IP of www.example.com.
• But Verisign knows who registered example.com! It replies with another referral: "Go talk to the authoritative nameservers for example.com: ns1.example.com and ns2.example.com."

Step 4: The Authoritative Answer

Finally, the recursive resolver sends a UDP packet to ns1.example.com:

• "What is the IP of www.example.com?"
• ns1.example.com is the Authoritative Nameserver for this domain. It opens its zone file, looks up the record, and returns the definitive answer:

Step 5: Returning the Result and Connection

The recursive resolver stores 93.184.216.34 in its local cache for 3,600 seconds, sends the IP address back to your laptop’s stub resolver, and your browser initiates a TCP three-way handshake to 93.184.216.34 on port 443 to begin the TLS handshake.

The entire process—from root to TLD to authoritative nameserver—takes between 15 and 45 milliseconds.

---

5. Anatomy of DNS Records: The Vocabulary of the Domain

When an authoritative nameserver answers a query, what kind of information does it return?

DNS is not limited to IP addresses; it is a general-purpose database storing typed entries called Resource Records (RRs). Every record consists of five fields:

[ Name ]       [ TTL ]    [ Class ]    [ Type ]    [ Data (RDATA) ]
example.com.    3600       IN           A           93.184.216.34

Here are the critical record types that power modern internet communication:

Record Type	Name	Purpose	Example Value
A	Address	Maps a hostname to a 32-bit IPv4 address.	93.184.216.34
AAAA	IPv6 Address ("Quad-A")	Maps a hostname to a 128-bit IPv6 address.	2606:2800:220:1:248:1893:25c8:1946
CNAME	Canonical Name	Creates an alias pointing one domain to another domain.	www.example.com → example.com
NS	Name Server	Specifies the authoritative servers that hold the zone file.	ns1.cloudflare.com
MX	Mail Exchanger	Directs email to mail servers, sorted by numeric priority.	10 mail.example.com
TXT	Text Record	Stores arbitrary human or machine-readable metadata.	v=spf1 include:_spf.google.com ~all
SOA	Start of Authority	Core metadata about the zone: admin email, serial number, refresh intervals.	Serial: 2026101401
PTR	Pointer	Reverse DNS: maps an IP address back to a hostname.	34.216.184.93.in-addr.arpa

The CNAME Apex Restriction

A common point of confusion for web developers is why you cannot place a CNAME record at the root of a domain (the "zone apex", such as example.com itself).

By definition in RFC 1034, if a name has a CNAME record, no other record of any type can exist for that same name.

If you put a CNAME on example.com, you could not have an NS record (which is legally required for the zone to exist) or an MX record (so your domain could never receive email)! This is why modern DNS providers (like Cloudflare and Route 53) invented proprietary workarounds like CNAME Flattening or ALIAS/ANAME records, which dynamically resolve the CNAME target and synthesize standard A records at the apex.

---

6. Caching and Time-To-Live (TTL): The Hidden Armor

If every single web request required walking the chain from root to TLD to authoritative nameserver, the internet's core servers would crash within minutes.

The secret to DNS scalability is aggressive, distributed Caching.

Every resource record returned by an authoritative nameserver includes a parameter called Time-To-Live (TTL), measured in seconds:

www.example.com.    300    IN    A    93.184.216.34

A TTL of 300 tells every recursive resolver on Earth: "You may cache this IP address and hand it out to your users for the next 5 minutes (300 seconds). Do not contact me again until that timer expires."

               THE POWER OF DISTRIBUTED DNS CACHING
               
    10,000 Users in London ──► [ Local ISP Resolver ] ──(Only 1 Query!)──► Authoritative Server
                               (9,999 Served from Cache)

Because of caching, over 95% of all DNS queries in the world are answered instantly from recursive resolver caches. The root and TLD nameservers handle only a tiny fraction of global traffic.

The Myth of "DNS Propagation"

When web administrators update their server IP address, they often say: "The DNS is propagating across the world."

In reality, DNS does not propagate. There is no push notification broadcast from your server to the rest of the world.

Instead, caching resolvers around the world simply hold onto your old IP address until their locally cached TTL expires. If you set your TTL to 86,400 seconds (24 hours), resolvers will continue serving the old IP for up to 24 hours. If you lower your TTL to 60 seconds prior to a server migration, resolvers will fetch the new IP address almost immediately.

---

7. Security: The Kaminsky Attack and the Rise of DNSSEC

When DNS was designed in 1983, the internet was a small community of trusted academic and military researchers. Security and cryptography were not part of the protocol.

DNS queries and responses were sent as unencrypted, unauthenticated cleartext over UDP. This created a catastrophic structural vulnerability known as DNS Cache Poisoning.

The Kaminsky Cache Poisoning Attack (2008)

To match a DNS response to a query, the protocol uses a 16-bit number in the UDP header called the Transaction ID (TXID):

    16-Bit Transaction ID = 2¹⁶ = 65,536 Possible Values

When a recursive resolver asks an authoritative server for an IP address, it waits for a response with the matching 16-bit ID.

In 2008, security researcher Dan Kaminsky discovered a flaw in how resolvers handled queries that allowed attackers to poison recursive caches with staggering speed:

               THE KAMINSKY CACHE POISONING ATTACK
               
    1. Attacker queries resolver for: random123.bank.com
    2. Resolver queries bank.com authoritative nameserver...
    3. Attacker floods resolver with thousands of forged UDP replies:
       "random123.bank.com = 1.2.3.4"
       "ALSO, the authoritative nameserver for bank.com is: ATTACKER_IP"
       (Guessing the 16-bit Transaction ID)
    4. When one forged packet matches the TXID before the real reply arrives:
       Resolver cache is poisoned! All users visiting bank.com are routed to fake site!

Because 16 bits only allows 65,536 combinations, an attacker on a fast broadband connection could flood the resolver with all possible IDs in less than 10 seconds. Once the cache was poisoned, millions of unsuspecting bank customers typing bank.com into their browsers were silently routed to an attacker's clone server.

Kaminsky worked in secret with major tech companies to deploy a universal patch: Source Port Randomization (SPR). Instead of sending queries from fixed UDP port 53, resolvers randomized both the 16-bit Transaction ID and the 16-bit source port, expanding the search space from 65,536 to:

This made brute-force spoofing computationally impractical over normal network latencies.

DNSSEC: Cryptographic Chain of Trust

While source port randomization made attacks harder, it was still a statistical band-aid. The definitive solution was to cryptographically sign DNS records using public-key cryptography: DNSSEC (Domain Name System Security Extensions).

Under DNSSEC:

• Every record is accompanied by an RRSIG (Resource Record Signature).
• The authoritative nameserver holds a private key and signs the records in the zone.
• The parent zone holds a DS (Delegation Signer) record, which is a SHA-256 hash of the child zone's public key.
• The root zone's public key is hardcoded into recursive resolvers worldwide.

When a validating resolver looks up example.com, it does not just verify the IP address; it traces a continuous cryptographic Chain of Trust all the way from the ICANN root down to the individual A record. If an attacker injects a forged IP address, the cryptographic signature fails, and the resolver rejects the data with a SERVFAIL status.

The Privacy Frontier: DNS over HTTPS (DoH) and DNS over TLS (DoT)

DNSSEC guarantees that DNS records cannot be forged, but it does not guarantee privacy. Traditional DNS requests are still sent in plain, unencrypted text across port 53.

Any entity sitting between your computer and the recursive resolver—your local coffee-shop Wi-Fi operator, your home ISP, or a surveillance agency—can see every domain name you ever query, building an exact, real-time profile of your online life.

To seal this privacy hole, the IETF developed two modern encryption standards:

1. DNS over TLS (DoT, RFC 7858): Wraps standard DNS queries in a dedicated TLS tunnel on TCP port 853.
2. DNS over HTTPS (DoH, RFC 8484): Packages DNS queries inside standard HTTPS traffic on port 443, making DNS lookups indistinguishable from ordinary encrypted web browsing.

Today, major web browsers and operating systems enable DoH by default, ensuring that your DNS queries cannot be monitored or censored by local networks.

---

8. Summary: The Nervous System of the Global Web

The Domain Name System is a triumph of distributed systems engineering:

When Paul Mockapetris created DNS in 1983, there were fewer than a thousand computers on the network. He designed a system so robust, mathematically sound, and cleanly separated that it has scaled by a factor of hundreds of millions without changing its fundamental core.

Every time you load a webpage, stream a video, or send an email, you are relying on an inverted tree of anycast roots, recursive resolvers, and cryptographic signatures executing in the blink of an eye—the invisible nervous system that keeps the global internet running.