Difficulty: Intermediate
How does DNS resolve a domain name? Explain recursive versus iterative queries and the role of root, TLD and authoritative servers.
DNS is the phone book of the internet: humans remember names like www.internhack.xyz, machines route on IP addresses, and DNS translates between them. But it is not one giant phone book on one server. It is a globally distributed, hierarchical database, and that design is what lets it scale to billions of lookups per day. The hierarchy reads right to left: the invisible root dot, then top-level domains like .com or .in, then the second-level domain like internhack, then subdomains like www.
Four kinds of players take part. The stub resolver is the tiny client library in your OS or browser. The recursive resolver (also called the caching resolver) is typically run by your ISP or a public service such as Google 8.8.8.8 or Cloudflare 1.1.1.1; it does the actual legwork on your behalf. Then the authoritative servers: root servers (13 logical addresses, A to M, served by hundreds of anycast instances) know where the TLD servers are; TLD servers know which name servers are responsible for each domain under them; and the domain's authoritative name servers hold the actual records.
Now the two query types. In a recursive query, the client says give me the final answer or an error and the server takes full responsibility, doing whatever queries are needed. Your laptop sends a recursive query to the resolver. In an iterative query, the server answers with the best it knows, which is either the answer or a referral, go ask this other server. The resolver uses iterative queries to walk the hierarchy.
Walkthrough for www.example.com with a cold cache: the browser and OS check their own caches and the hosts file first. Then the stub resolver sends a recursive query to the recursive resolver. The resolver asks a root server, which does not know the answer but replies with a referral to the .com TLD servers. The resolver asks a .com TLD server, which replies with the NS records for example.com. The resolver asks the authoritative server for example.com, which returns the A record with the IP address. The resolver caches every step, and returns the answer to the client, which caches it as well. That is 4 hops but usually under 100 ms, and with caching most queries never leave the resolver at all.
Caching is what makes DNS fast, and every record carries a TTL, the number of seconds it may be cached. The resolver also caches the NS referrals, so the root and TLD servers are rarely bothered. Negative caching remembers that a name does not exist (NXDOMAIN) too. The trade-off is propagation delay: when you change a record, old answers linger until TTLs expire, which is why engineers lower the TTL before a migration.
Edge cases: DNS uses UDP port 53 for most queries and TCP port 53 for large responses and zone transfers. DNSSEC adds signatures to prove answers were not tampered with; DNS over HTTPS and DNS over TLS encrypt the query so your ISP cannot read it. DNS is also used for load distribution (returning multiple A records or geo-aware answers) and it is a common outage source, hence the engineer joke that it is always DNS.
$ dig +trace www.example.com
. 518400 IN NS a.root-servers.net.
com. 172800 IN NS a.gtld-servers.net.
example.com. 172800 IN NS a.iana-servers.net.
www.example.com. 86400 IN A 93.184.216.34Each block is one referral: root to .com TLD to example.com authoritative server, ending in the A record with its TTL of 86400 seconds.
DNS, Recursive Resolver, Iterative Query, Root Servers, Caching