In November 1987, four years after the original DNS specifications, Paul Mockapetris published updated documents that would become the definitive DNS standards: RFC 1034 (“Domain Names — Concepts and Facilities”) and RFC 1035 (“Domain Names — Implementation and Specification”). Unlike their experimental predecessors, these were designated Internet Standards — the real rules that every DNS implementation must follow.
Why New RFCs?
RFC 882 and 883 were explicitly marked “experimental.” The ARPA community expected to learn from deployment and iterate. And learn they did.
By 1987, DNS had been running in production for three years. Operators discovered:
- Ambiguities in the original specifications
- Edge cases the specs didn’t cover
- Security concerns that needed addressing
- Features that should be mandatory vs. optional
- Operational practices that needed documenting
Rather than patch RFC 882/883 endlessly, Mockapetris wrote comprehensive replacements.
RFC 1034: Concepts and Facilities
RFC 1034 replaced RFC 882 as the conceptual foundation of DNS. It runs 55 pages and covers:
Domain Name Space
The document formalizes the tree structure:
“The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term ‘node’ to refer to both.”
Labels and Names
RFC 1034 tightened the rules:
- Labels are 63 octets or less
- Total name length is 255 octets or less
- Names are case-insensitive (but case-preserving)
- Comparisons must be done case-insensitively
Zones and Delegation
The document clarifies zone boundaries:
“The domain name space is partitioned into areas called zones. A zone starts at a node and extends downward to the leaf nodes or to nodes where other zones start.”
This crystallized the delegation model that makes DNS scalable.
Resource Records
RFC 1034 defined the standard record types:
| Type | Value | Description |
|---|---|---|
| A | 1 | Host address |
| NS | 2 | Authoritative name server |
| CNAME | 5 | Canonical name (alias) |
| SOA | 6 | Start of authority |
| PTR | 12 | Domain name pointer |
| HINFO | 13 | Host information |
| MX | 15 | Mail exchange |
Note that MX records are now formally part of the spec — they were added after RFC 882/883 to improve email routing.
Resolver Behavior
The document spends considerable attention on resolver algorithms:
- How to follow referrals
- When to cache data
- How to handle failures
- Recursive vs. iterative queries
This guidance helped create interoperable implementations.
RFC 1035: Implementation and Specification
RFC 1035 replaced RFC 883 with detailed technical specifications. At 55 pages, it covers the wire protocol, master file format, and implementation requirements.
Message Format
The document specifies the exact byte layout:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Every bit and byte is specified. This precision enables interoperability — a query from any implementation works with servers from any other implementation.
Master File Format
RFC 1035 formalized the zone file format that BIND had popularized:
$ORIGIN EXAMPLE.COM.
@ IN SOA NS1.EXAMPLE.COM. HOSTMASTER.EXAMPLE.COM. (
2024010101 ; serial
7200 ; refresh (2 hours)
600 ; retry (10 minutes)
1209600 ; expire (2 weeks)
3600 ) ; minimum (1 hour)
IN NS NS1.EXAMPLE.COM.
IN NS NS2.EXAMPLE.COM.
NS1 IN A 192.0.2.1
NS2 IN A 192.0.2.2
WWW IN A 192.0.2.3
This text format remains the standard for expressing DNS zones, though modern systems often generate it from databases.
Transport
The specification mandates:
- UDP on port 53 for queries (with 512-byte limit)
- TCP on port 53 for responses exceeding UDP limits and zone transfers
- Resolvers MUST handle truncated UDP responses by retrying via TCP
The 512-byte UDP limit would later cause problems as DNSSEC added larger responses, eventually addressed by EDNS (Extension mechanisms for DNS, RFC 2671).
What Changed from 882/883?
The 1987 RFCs weren’t revolutionary updates — they were refinements. Key changes:
Clarifications
Many sections that were ambiguous in 882/883 got precise language. What happens when a CNAME points to another CNAME? RFC 1034 says follow the chain (up to a limit).
SOA Record Tuning
The SOA record gained clearer semantics for its timing parameters:
- Refresh: How often secondaries should check for updates
- Retry: How long to wait after a failed refresh
- Expire: When to stop serving the zone if primary is unreachable
- Minimum: Originally the minimum TTL, later repurposed for negative caching
Negative Caching
RFC 1034 addressed caching of negative responses (NXDOMAIN). You should cache “this domain doesn’t exist” to prevent repeated queries for non-existent domains.
Security Notes
While not solving the security problem, the RFCs acknowledged it:
“The design of the DNS system assumes that the database is coherent, and that all copies of the database, and all resolvers which are willing to cache data, operate correctly… This assumption simplifies the design but clearly requires trust in the integrity of information returned from DNS queries.”
This honest acknowledgment set the stage for later security work.
The Standard Track
RFC 1034 and 1035 progressed through the IETF standards process:
| Date | Status |
|---|---|
| November 1987 | Published as Proposed Standard |
| October 1991 | Advanced to Draft Standard |
| November 1996 | Advanced to Internet Standard (STD 13) |
Reaching Internet Standard status meant the specifications were considered stable and mature. Very few RFCs achieve this designation.
Still the Foundation
Here’s the remarkable thing: RFC 1034 and 1035 are still the DNS specification. Every DNS implementation, every resolver, every nameserver — all must implement these documents.
Of course, DNS has evolved. Later RFCs added:
- AAAA records for IPv6 (RFC 3596)
- SRV records for service discovery (RFC 2782)
- EDNS for larger messages (RFC 2671, updated by RFC 6891)
- DNSSEC for cryptographic security (RFC 4033-4035)
- DNS over HTTPS/TLS for privacy (RFC 8484, RFC 7858)
But all these extend RFC 1034/1035 — they don’t replace it. The core protocol defined in 1987 remains the foundation.
Reading the Standards
These documents are publicly available:
They’re technical documents, but surprisingly readable. If you work with DNS professionally, you should read them at least once.
Key Takeaways
- RFC 1034 and 1035 (November 1987) replaced the experimental 882/883 with Internet Standards
- These documents remain the authoritative DNS specification today
- Key additions: MX records, negative caching guidance, clearer SOA semantics
- The message format and zone file format are precisely specified for interoperability
- RFC 1034/1035 achieved Internet Standard status (STD 13) in 1996
- Modern DNS features (DNSSEC, IPv6, DoH) extend rather than replace the original spec
Next: Early DNS Infrastructure
With the specification complete and BIND providing a reference implementation, DNS was ready for deployment. In the next chapter, we’ll explore how the early DNS infrastructure came online — the original root servers, the first TLDs, and the organizations that operated them.