How DNS Resolution Works
The Domain Name System (DNS) translates human-readable domain names (like example.com) into IP addresses (like 93.184.216.34). It is a distributed, hierarchical database — no single server holds all the data. DNS is sometimes called the "phone book of the Internet."
The DNS Hierarchy
DNS is organized as an inverted tree:
- Root servers (
.) — 13 logical root server clusters (A through M), operated by organizations like ICANN, Verisign, and NASA. They know which servers are authoritative for each top-level domain. - TLD servers (
.com,.org,.io, etc.) — each TLD has its own set of authoritative nameservers. Verisign operates the .com and .net TLD servers. - Authoritative nameservers — the servers that hold the actual DNS records for a domain. When you register
example.com, you configure its authoritative nameservers (often your hosting provider's).
Recursive vs Iterative Resolution
When your browser needs to resolve www.example.com:
Recursive resolution: your computer sends the query to a recursive resolver (typically your ISP's DNS server or a public resolver like 8.8.8.8 or 1.1.1.1). The resolver takes full responsibility for finding the answer — it queries root servers, TLD servers, and authoritative servers on your behalf, then returns the final answer.
Iterative resolution: this is what happens inside the recursive resolver. It asks each server in turn, and each server responds with a referral (not the answer, but who to ask next). The resolver asks the root: "Where is www.example.com?" Root says: "I don't know, but here are the .com TLD servers." The resolver asks the .com TLD server, which says: "Here are example.com's authoritative nameservers." Finally, the resolver asks the authoritative server and gets the actual IP address.
DNS Record Types
| Record | Purpose | Example |
|---|---|---|
| A | Maps domain to IPv4 address | example.com → 93.184.216.34 |
| AAAA | Maps domain to IPv6 address | example.com → 2606:2800:220:1:... |
| CNAME | Alias — points to another domain name | www.example.com → example.com |
| MX | Mail exchange server (with priority) | example.com → mail.example.com (pri 10) |
| NS | Delegates a zone to nameservers | example.com → ns1.example.com |
| TXT | Arbitrary text (SPF, DKIM, verification) | example.com → "v=spf1 include:..." |
| SRV | Service location with port and weight | _sip._tcp.example.com → sipserver:5060 |
TTL and Caching
Every DNS record has a Time To Live (TTL) value in seconds. When a resolver fetches a record, it caches the result for TTL seconds. A TTL of 3600 means the record is cached for one hour. Low TTLs (60s) allow fast updates but increase query load. High TTLs (86400s) reduce load but delay propagation of changes. DNS propagation delays are mostly due to caches honoring old TTLs.
DNS Security
DNS over HTTPS (DoH) wraps DNS queries in HTTPS to port 443, preventing ISPs and network operators from seeing or tampering with DNS queries. DNS over TLS (DoT) encrypts DNS queries using TLS on port 853. Both prevent eavesdropping and man-in-the-middle attacks on DNS. Major browsers and operating systems now support DoH.
DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that a response has not been tampered with. It uses a chain of trust from the root zone down to individual domains.
Tracing a DNS Lookup
Resolving www.github.com step by step:
- Your laptop checks its local DNS cache. Cache miss.
- Your laptop sends a recursive query to the configured resolver (say,
1.1.1.1— Cloudflare's public DNS). - The resolver checks its cache. Cache miss. It starts iterative resolution:
- Asks a root server: "Where is www.github.com?" → Referral to .com TLD servers.
- Asks the .com TLD server: "Where is www.github.com?" → Referral to GitHub's authoritative nameservers (
dns1.p08.nsone.net). - Asks GitHub's authoritative server: "What is www.github.com?" → Response: CNAME to
github.com, then A record140.82.121.3(TTL: 60).
- The resolver caches the result (for 60 seconds) and returns it to your laptop.
- Your laptop caches it locally and connects to
140.82.121.3.
Why GitHub uses a short TTL of 60 seconds: GitHub serves traffic from multiple data centers and uses DNS-based load balancing. Short TTLs let them redirect traffic quickly during outages or failovers. The cost is higher query volume to their authoritative servers.
Common debugging tools:
dig www.github.com— shows the full DNS response with record type, TTL, and answer sectiondig +trace www.github.com— shows each step of iterative resolution from root to authoritativenslookup www.github.com— simpler query tool, shows the resolver used and the answer