2 The problem DNS solves

2.1 Identity is not location

A network delivers packets to addresses. Humans and applications want stable identities. Those two things should not be fused.

Suppose a service is reached at 192.0.2.8. If that address is embedded in every configuration, moving the service requires changing every client. A name such as api.example introduces indirection:

application → api.example → 192.0.2.8 → packets

Indirection has a cost: another system must answer the middle question. Its benefit is that the service owner can change the answer without changing the application. DNS is the globally deployed mechanism for this indirection.

The mapping is not a function from one name to one address. One name may have several addresses. The answers may differ by client location. A mail domain may name several mail exchangers with preferences. A service may delegate a subtree to another organization. The useful abstraction is therefore:

(owner name, record type, class) → a set of resource records

The owner and type together select an RRset. “RRset” means all resource records with the same owner, type, and class. Implementations should normally treat the set as a unit because caches and DNSSEC signatures do.

2.2 Requirements that pull in different directions

A global naming system must satisfy conflicting demands:

• It must scale without one central database receiving every query.
• Different organizations must control different parts of the namespace.
• Changes must propagate, but cached answers are essential for performance.
• Replies should usually fit in one datagram, but some answers are large.
• Old implementations must coexist with protocol extensions.
• A client needs to distinguish “no such name” from “that name has no record of this type.”
• Operators need a way to transfer complete zones and to diagnose individual exchanges.

DNS answers these demands with hierarchy, delegation, caching lifetimes, compact binary messages, UDP plus TCP, explicit result codes, and typed records. Many operational surprises are direct consequences of those design choices rather than random quirks.

2.3 Roles, not just “DNS servers”

The phrase “DNS server” hides several jobs.

An authoritative server publishes data for zones it controls. It answers from configured facts and does not chase referrals on behalf of a client.

A recursive resolver accepts a question from a stub client, follows the delegation chain, validates and caches what it learns, and returns a final answer.

A stub resolver is the client-side library or program that sends a recursive query to a configured resolver.

A forwarder sends selected questions to another resolver rather than performing iteration itself.

Keeping these roles distinct is both conceptual hygiene and a security boundary. An authoritative daemon does not need a large mutable Internet-fed cache. A recursive resolver does not need the private machinery used to edit a zone. rgbdns follows the djbdns design and runs authority and recursion as different programs.