DNS resolution is a distributed, hierarchical system that translates human-readable domain names into machine-readable IP addresses, and it’s far more resilient than you might think because no single entity controls the entire system.
Let’s see this in action. Imagine you type www.example.com into your browser. Your computer doesn’t know what to do with that. It needs an IP address. So, it asks its configured DNS resolver. This resolver is usually provided by your ISP or a public service like Google DNS (8.8.8.8) or Cloudflare (1.1.1.1).
# Example of a dig command to see the process from your machine
dig www.example.com
The resolver, let’s say it’s 1.1.1.1, receives the request for www.example.com. If 1.1.1.1 doesn’t have the answer cached (and it probably doesn’t for a random domain), it starts a recursive process. It first asks one of the 13 root name servers, "Where can I find information about .com?"
The root server doesn’t know the IP for www.example.com, but it knows who is authoritative for the .com top-level domain (TLD). It responds with the IP addresses of the .com TLD name servers.
Next, our resolver 1.1.1.1 asks one of the .com TLD servers, "Where can I find information about example.com?" The .com TLD server, in turn, doesn’t have the IP for www.example.com but knows which name servers are authoritative for the example.com domain. It responds with those IP addresses.
Finally, 1.1.1.1 asks one of the authoritative name servers for example.com, "What is the IP address for www.example.com?" This authoritative server does know. It looks up the A record (for IPv4) or AAAA record (for IPv6) associated with www within the example.com zone file and returns the IP address (e.g., 93.184.216.34).
The resolver 1.1.1.1 then caches this answer for a specific time-to-live (TTL) and returns it to your computer. Your browser can now connect to 93.184.216.34 to fetch the webpage.
The magic here is the hierarchical delegation. The root servers only know about TLD servers. TLD servers only know about authoritative servers for domains within their TLD. Authoritative servers know about the specific records (like A, AAAA, MX, CNAME) for the domains they manage. This distributed model prevents a single point of failure and allows for massive scalability.
Zone files are the actual text files stored on authoritative name servers that contain all the DNS records for a specific domain or subdomain. For example.com, a simplified zone file might look like this:
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ; Minimum TTL
)
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 93.184.216.34
www IN A 93.184.216.34
mail IN A 192.168.1.100
ftp IN CNAME www.example.com.
Here, @ refers to the zone origin (example.com). SOA is the Start of Authority record, defining primary name server, administrator, and timing parameters. NS records indicate the name servers responsible for this zone. A records map hostnames to IPv4 addresses. CNAME records create aliases, pointing ftp.example.com to www.example.com. The TTL at the top sets the default caching time for records in this zone.
When a resolver asks an authoritative server for www.example.com, that server reads its zone file, finds the A record for www, and returns the IP.
The most surprising part of DNS is that the "root servers" are not a single set of physical machines, but rather a distributed network of servers managed by various organizations worldwide, with specific IP addresses announced via BGP. There are actually 13 logical root server addresses, but each of these is served by hundreds of physical servers globally. This redundancy ensures that even if many root servers go offline, the system continues to function.
The next step in understanding DNS is exploring how other record types like MX (Mail Exchanger) and SRV (Service Location) enable more complex internet services.