DNS is a distributed naming system: its names form a tree, authority for parts of that tree is delegated among operators, and recursive resolvers follow those delegations or use cached answers to find records. The phonebook analogy captures the lookup, but misses how the directory is divided and how the lookup is carried out.
How does DNS work?
DNS—the Domain Name System—maps domain names to records that other systems can use. A browser may need an IP address to connect to a site, for example, while other applications may look up different kinds of records. DNS is not one central directory. Its names form a hierarchy, and its data is distributed among independently operated zones.
As an Amazon Associate I earn from qualifying purchases.
RFC 1034 describes the domain name space as a tree: “The domain name space is a tree structure.” A name such as www.example.com consists of labels along a path in that tree, read from the most specific label toward the root. The root sits above top-level domains such as .com, which sit above domains such as example.com. RFC 1034, Domain Names—Concepts and Facilities
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →What are zones and delegation?
The name tree is divided into zones: connected portions of the namespace for which particular operators serve authoritative data. A zone can include a domain and its names, while a subdomain may be delegated as its own zone. That division lets different organizations manage different parts of the tree without one central operator maintaining every record.
#1 Best Overall
Delegation is recorded at the boundary between a parent zone and a child zone, known as a zone cut. The parent’s NS records identify the name servers for the child. If a delegated name server is inside the child zone—for example, a server named within the very domain it serves—resolvers may also need glue address records from the parent. Glue helps them reach that server without first needing to resolve the child zone it serves. RFC 1034
What happens when I type a website name into my browser?
Consider a request for the AAAA records for www.example.com. AAAA records provide IPv6 addresses. The exact exchange depends on the system and resolver, but a common path looks like this:
- The client asks its configured resolver. The browser or operating system generally uses a client-side stub resolver, which sends the question to a recursive resolver rather than finding all the authoritative servers itself.
- The resolver checks what it already knows. It may have a usable answer in local information or its cache. If so, it can return that result without repeating upstream queries.
- If needed, the resolver pursues the answer. It queries DNS servers using information it has available and follows referrals toward the zone responsible for the requested name. A referral points the resolver toward another server, often at a delegation.
- An authoritative server answers for its zone. The server holding the relevant zone data can return the requested record or an error. The recursive resolver then returns the result to the client.
- The resolver may cache the result. A later query can reuse the cached data while it remains within its time to live, or TTL.
Not every lookup starts at a root server or follows an identical sequence. Forwarding, local zones, aliases such as CNAME, cache contents, and other DNS features can change the path. RFC 1034 describes recursive service as a mode in which the server returns an answer or error rather than referrals to the client. RFC 1034
What is a DNS resolver, and how is it different from an authoritative server?
People often call both systems “DNS servers,” but their jobs differ. A recursive resolver works on behalf of clients to find an answer; an authoritative server serves the data for zones it is configured to host. Some software or systems can perform both roles, but the functions remain distinct. The terminology below follows the IETF’s March 2024 DNS terminology standard, RFC 9499, which obsoletes RFC 8499. RFC 9499, DNS Terminology
Rank #3
- Used Book in Good Condition
| Role | Where it gets data | Typical response to a client or resolver | Main responsibility |
|---|---|---|---|
| Stub resolver | Relies on another resolver for full resolution. | Sends a question to its configured recursive resolver. | Requests DNS information for a client. |
| Recursive resolver | Uses local information, cache, and queries to other DNS servers. | Returns a completed answer or an error to the requesting client. | Resolves queries on clients’ behalf. |
| Authoritative server | Serves configured zone data. | Returns authoritative data for its zone; at a delegation it may refer the requester onward. | Publishes and serves DNS data for its zones. |
Why does DNS use caching?
Without caching, resolvers would have to repeat more of the upstream lookup process for each request. A resolver can reuse a record until its TTL expires; the TTL places a limit on how long that record may remain cached before the information should be consulted again. This reduces repeated work while allowing DNS data to be refreshed over time.
Caching can also apply to negative results, such as information that a requested name or record does not exist. As a result, a change to DNS data may not be reflected everywhere immediately: a resolver that already holds an unexpired answer or negative result can continue using it until its cache lifetime ends. RFC 9499
Rank #4
Is DNS just a phonebook for the internet?
The analogy is useful in one narrow sense: a person can look up a name to find associated information. But a phonebook suggests a single, centrally maintained directory with direct entries. DNS instead has a hierarchical namespace divided among zones, with delegation indicating where authority for a child section lies. A recursive resolver does work for the client and may answer from cache rather than consult every upstream source each time.
The resolver also matters to the result and to privacy. A client’s use of one configured resolver does not mean the lookup is private: DNS queries may be visible to parties involved in handling or observing them, depending on how the queries are transported and the surrounding network. The IETF’s DNS Privacy Considerations, RFC 9076, discusses these risks.
Why the distinction matters
Thinking of DNS as a delegation tree with caching explains two behaviors the phonebook model cannot: different operators can control different parts of a domain hierarchy, and the same query can take a shorter route when a resolver has a still-valid cached answer. It also clarifies why “DNS server” is not a precise job description: the system serving a zone and the resolver pursuing an answer play different roles.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
