7.3 Domain Name System (DNS)

DNS Overview

DNS translates human-readable domain names (like www.example.com) into IP addresses (like 192.0.2.1) that machines use to route traffic. Without it, you'd need to memorize numerical addresses for every website you visit. As a distributed, hierarchical database, DNS is one of the most critical pieces of internet infrastructure.

Purpose of DNS

• Translates domain names into IP addresses so devices can locate and communicate with each other
• Lets users type memorable names instead of numerical addresses, which makes the internet actually usable
• Operates as a distributed system, meaning no single server holds all the answers. This design scales to support billions of devices and domains worldwide.
• Acts as a foundational layer for nearly every internet application: web browsing, email delivery, API calls, and more

Structure of the DNS Namespace

The DNS namespace is organized as a hierarchical tree, similar to a file system. Each level delegates authority downward, which keeps management distributed and efficient.

• Root domain: Sits at the very top, represented by a dot (.). Every domain name technically ends with this dot, though browsers hide it. Root servers store pointers to TLD servers and are the starting point for resolution.
• Top-Level Domains (TLDs): Sit directly below the root. These include generic TLDs (.com, .org, .edu) and country-code TLDs (.us, .uk, .cn). Each TLD is managed by a designated registry organization.
• Second-level domains: Registered under a TLD by organizations or individuals (e.g., example.com). The authoritative name server for a second-level domain holds the actual records for that domain.
• Subdomains: Created under second-level domains for further organization. For instance, mail.example.com and blog.example.com are subdomains of example.com. There's no hard limit on how deep subdomains can nest.

The key idea: each level only needs to know about the level directly below it. Root servers know about TLD servers, TLD servers know about authoritative servers for individual domains, and those authoritative servers hold the final answers. This delegation is what makes DNS scalable.

DNS Resolution Process

Process of DNS Resolution

When you type www.example.com into a browser, here's what happens behind the scenes:

1. Your device sends a query to a DNS resolver (usually operated by your ISP or a public service like Google's 8.8.8.8), asking for the IP address of www.example.com.
2. The resolver checks its local cache. If it recently resolved this name, it returns the cached IP address immediately. This is the fast path.
3. If the cache has no answer, the resolver queries a root server, asking which TLD server handles .com.
4. The root server responds with the address of the .com TLD server.
5. The resolver queries the .com TLD server, asking which authoritative server handles example.com.
6. The TLD server responds with the address of the authoritative name server for example.com.
7. The resolver queries that authoritative server, asking for the IP address of www.example.com.
8. The authoritative server responds with the IP address (e.g., 192.0.2.1).
9. The resolver caches this result (respecting the record's TTL value) and returns the IP address to your device. Your browser can now open a TCP connection to that address.

In practice, most of these steps get skipped thanks to caching. The resolver, your OS, and even your browser all maintain caches, so a full resolution from root to authoritative is relatively rare for popular domains.

Iterative vs. Recursive DNS Queries

These are two different strategies for how the resolution workload gets distributed.

Iterative queries:

• The resolver does all the legwork. It sends a query to a server, and if that server doesn't have the final answer, it returns a referral pointing to the next server to ask.
• The resolver then follows that referral, querying the next server, and repeats until it reaches the authoritative server.
• This spreads the work across the resolver and keeps the burden on each individual DNS server low.

Recursive queries:

• The resolver sends a query to a server, and that server takes full responsibility for finding the answer. If it doesn't know, it queries other servers on the resolver's behalf and only responds once it has the final answer.
• This simplifies things for the client but puts more load on the server handling the recursion.

In typical deployments, the query from your device to the resolver is recursive (your device expects a complete answer), while the queries the resolver makes to root, TLD, and authoritative servers are iterative (the resolver follows referrals itself). This hybrid approach balances efficiency: your device stays simple, the resolver does the chasing, and the authoritative servers aren't burdened with recursive lookups for other people's queries.

DNS Resource Records

Resource records (RRs) are the actual data entries stored in DNS. Each record has a type, a name, a value, and a TTL (time-to-live, which controls how long the record can be cached). Here are the most common types:

• A record: Maps a domain name to an IPv4 address.
  • Example: www.example.com → 192.0.2.1
  • This is the most fundamental record type. When you resolve a domain to browse a website, you're typically getting an A record.
• AAAA record: Maps a domain name to an IPv6 address.
  • Example: www.example.com → 2001:db8::1
  • Functions identically to an A record but for the 128-bit IPv6 address space. As IPv6 adoption grows, these records become increasingly common.
• MX (Mail Exchange) record: Specifies which mail server handles email for a domain.
  • Example: The MX record for example.com might point to mail.example.com with a priority value of 10.
  • Priority values matter here. A lower number means higher priority. If you set two MX records with priorities 10 and 20, mail delivery attempts the priority-10 server first and falls back to priority-20 if the first is unreachable. This enables redundancy and load balancing for email.
• CNAME (Canonical Name) record: Creates an alias that points to another domain name.
  • Example: blog.example.com (CNAME) → www.example.com (canonical name)
  • Useful when multiple subdomains should resolve to the same server. Instead of maintaining separate A records for each, you point them all via CNAME to one canonical name that has the A record. Change the A record once, and all aliases follow.
  • One restriction: a CNAME cannot coexist with other record types for the same name. You also can't place a CNAME at the zone apex (e.g., example.com itself).