On November 1, 1983, Paul Mockapetris published two documents that would change the internet forever: RFC 882 (“Domain Names — Concepts and Facilities”) and RFC 883 (“Domain Names — Implementation and Specification”). Together, these RFCs defined the Domain Name System.
Two RFCs, One System
Mockapetris split the specification into two parts for good reason:
RFC 882 covered the what and why:
- The concept of domain names
- The hierarchical namespace structure
- How domains relate to each other
- The user-level view of the system
RFC 883 covered the how:
- Wire protocol formats
- Server implementation details
- Message structures
- Operational procedures
This separation allowed different audiences to read what they needed. A system administrator could understand the concepts from RFC 882; a developer implementing DNS software needed both.
RFC 882: Concepts and Facilities
RFC 882 introduced several revolutionary ideas:
The Domain Name Space
The document defined a domain name space as a tree structure:
(root)
|
+------------------+------------------+
| | |
arpa com edu
| | |
+----+----+ +----+----+ mit
| | | | |
in-addr arpa example company ai
Names are read from bottom to top: ai.mit.edu means the ai subdomain within mit within edu.
Labels and Length
Each component of a domain name (separated by dots) is called a label. RFC 882 specified:
- Labels can be up to 63 characters
- Full domain names can be up to 255 characters total
- Labels are case-insensitive (though case is preserved)
- Labels can contain letters, digits, and hyphens
These constraints still apply today.
Zones and Delegation
Perhaps the most important concept: zones. A zone is a portion of the namespace managed by a particular authority.
For example, MIT might operate the mit.edu zone, containing:
mit.edu. (zone apex)
www.mit.edu.
mail.mit.edu.
ai.mit.edu. (delegated to another zone)
The ai.mit.edu subdomain could be delegated to the AI Lab, becoming its own zone with its own nameservers.
This is the killer feature. Instead of one central authority managing all names, responsibility is distributed. Each organization manages its own piece.
Resource Records
DNS stores information in resource records (RRs). RFC 882 defined several types:
| Type | Purpose |
|---|---|
| A | IPv4 address |
| NS | Nameserver for a zone |
| CNAME | Canonical name (alias) |
| SOA | Start of Authority (zone metadata) |
| PTR | Pointer (reverse lookup) |
| MX | Mail exchanger (added later) |
Each record has:
- A name (the domain it applies to)
- A type (what kind of data)
- A class (almost always IN for Internet)
- A TTL (how long it can be cached)
- RDATA (the actual data)
The Resolver-Server Model
RFC 882 described two types of DNS participants:
Resolvers make queries on behalf of applications. When your browser needs to look up example.com, it talks to a resolver.
Servers answer queries. Some are authoritative (they own the data), others are recursive (they query on your behalf).
This separation lets endpoints be simple. A laptop doesn’t need to know how to traverse the DNS hierarchy — it just asks its configured resolver.
RFC 883: Implementation and Specification
While RFC 882 explained concepts, RFC 883 got into the weeds.
Message Format
DNS messages have a specific binary format:
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing to authoritative servers
+---------------------+
| Additional | RRs which may be useful
+---------------------+
The header contains:
- ID — matches responses to queries
- QR — query (0) or response (1)
- Opcode — type of query (standard, inverse, status)
- Flags — authoritative, truncated, recursion desired, etc.
- Counts — number of records in each section
Name Compression
To save space, DNS allows name compression. If a name (or suffix) appears earlier in the message, later occurrences can point back to it.
For example, if example.com appears at byte offset 30, a later reference to www.example.com could store just www followed by a pointer to offset 30.
This optimization was crucial in 1983 when every byte mattered.
Transport
RFC 883 specified that DNS primarily uses UDP on port 53 for queries, with TCP on port 53 for zone transfers and responses that exceed UDP limits.
The choice of UDP was deliberate — it’s faster and lighter than TCP for simple queries. But the protocol had fallback:
“If the resolver’s transport gets an answer which was truncated, and the resolver permits, it should retry using a connection instead of datagrams.”
This design persists. DNS queries are still primarily UDP, with TCP as a backup.
Caching
The specification detailed caching behavior:
- Resolvers and servers SHOULD cache data
- TTL (Time To Live) determines cache lifetime
- When TTL expires, data MUST be refreshed
- Negative responses (NXDOMAIN) should also be cached
This caching is why DNS scales. A popular domain like google.com gets looked up millions of times per second globally, but each resolver only queries the authoritative servers occasionally — everyone else uses cached data.
What These RFCs Got Right
Looking back, it’s remarkable how much RFC 882/883 got right on the first try:
Extensibility
The resource record type system allowed new record types without changing the protocol. MX records, AAAA (IPv6), TXT, SRV — all added later without breaking the original design.
Scalability
The hierarchical delegation model has scaled from hundreds of hosts to billions. Each new domain just adds a leaf to the tree.
Simplicity
The basic query-response protocol is simple enough that students still implement DNS resolvers as homework. Complexity lives in the implementations, not the core protocol.
Pragmatism
Rather than redesigning everything, DNS worked with existing infrastructure. It coexisted with HOSTS.TXT for years. It used existing transport (UDP/TCP). It didn’t require coordinated flag-day transitions.
What They Got Wrong (Or Left Out)
No design is perfect, and these early RFCs had gaps:
Security
There was essentially no security model. Anyone could claim to be authoritative for any domain. This omission would haunt DNS for decades until DNSSEC addressed it (in the 2000s).
No Authentication
Queries and responses had no authentication. A malicious server could send fake responses, and resolvers had no way to verify them.
Zone Transfer Issues
The AXFR (zone transfer) mechanism let anyone request a complete copy of a zone. This later became a security and privacy concern.
Undersized Limits
Some limits seemed generous in 1983 but proved constraining later:
- 512-byte UDP limit required awkward workarounds
- 255-character name limit affects some uses
- 13 root server addresses fit in one UDP packet — by design, but limiting
The Path to RFC 1034/1035
RFC 882 and 883 were designated experimental. The ARPA community would learn from deployments, gather feedback, and iterate.
By 1987, after several years of operational experience, Mockapetris published updated specifications:
- RFC 1034: Domain Names — Concepts and Facilities (replacing RFC 882)
- RFC 1035: Domain Names — Implementation and Specification (replacing RFC 883)
These became the standard specifications that DNS implementations follow today. We’ll examine them in a later section.
Reading the Original
If you want to read these historic documents:
Fair warning: they’re written in the dry technical style of 1983 RFCs. But they’re surprisingly readable and represent a pivotal moment in internet history.
Key Takeaways
- RFC 882 and 883 were published in November 1983, defining the original DNS
- RFC 882 covered concepts: domain names, zones, delegation, resource records
- RFC 883 covered implementation: message format, compression, transport, caching
- The design emphasized extensibility, scalability, and pragmatism
- Security was the major gap — authentication and integrity checking came decades later
- These RFCs were experimental; RFC 1034/1035 (1987) became the standards
Next
With the specification in hand, we can examine the design principles that made DNS successful: distributed, hierarchical, and cacheable. These weren’t accidents — they were deliberate choices to solve specific problems.