Key RFCs

The protocol is defined in documents, not in code

DNS is not defined by any single implementation. It is defined by Requests for Comments (RFCs) — documents published by the Internet Engineering Task Force (IETF) that specify how the protocol works. As of 2022, approximately 297 RFCs touch DNS directly, with over 2,327 Internet-Drafts submitted on DNS-related topics.

Nobody needs to read all 297. The protocol’s core is defined by a handful of documents, and each major extension or refinement has its own RFC. This page covers the ones that matter most — the documents that DNS operators, developers, and anyone building on DNS should know exist.

The foundation: RFC 1034 and RFC 1035

Everything starts here.

RFC 1034 — Domain Names: Concepts and Facilities (November 1987)

The conceptual document. RFC 1034 describes the DNS architecture without specifying wire formats or implementation details. It defines:

• The hierarchical namespace (the domain name tree)
• The roles of authoritative servers, recursive resolvers, and stub resolvers
• The delegation model (how responsibility for zones is distributed)
• Caching behavior and TTLs
• Wildcard records and their matching rules
• The iterative and recursive query models

RFC 1034 replaced the original DNS specification in RFC 882 (1983), written by Paul Mockapetris. The four years between RFC 882 and RFC 1034 refined the design based on operational experience with the early DNS deployment.

RFC 1035 — Domain Names: Implementation and Specification (November 1987)

The implementation document. RFC 1035 specifies the binary wire format, message structure, and protocol mechanics in precise detail. It defines:

• The 12-byte header format and its flags
• The question section, resource record format, and name compression
• The 512-byte UDP message limit
• Master file (zone file) format
• Record types: A, NS, CNAME, SOA, MX, TXT, PTR, and others
• Transport requirements (UDP port 53, TCP port 53)

RFC 1035 is 55 pages long and remains the single most important DNS document. Every DNS implementation on earth implements this specification. Its core structures — the header, the question, the resource record — have not changed in nearly four decades.

Clarifications and corrections

RFC 2181 — Clarifications to the DNS Specification (July 1997)

A decade of deployment revealed ambiguities and inconsistencies in RFC 1034/1035. RFC 2181 clarified:

• RRset handling: All resource records with the same name, class, and type form an RRset. Members of an RRset must have the same TTL.
• Bailiwick rules: A trust hierarchy for data in DNS responses. A server for example.com can be trusted for records within example.com but not for records in attacker.com. Without these rules, a malicious server could inject poisoned records for any domain.
• Name uniqueness: A domain name can have multiple record types, but certain types (CNAME) are exclusive — a name with a CNAME record cannot have any other record types.
• TTL as signed 32-bit integer: Maximum TTL is 2^31 - 1 seconds (about 68 years).

RFC 2308 — Negative Caching of DNS Queries (March 1998)

Defined how resolvers should cache negative responses — NXDOMAIN (name does not exist) and NODATA (name exists but not with the requested type). Without negative caching, resolvers would repeatedly query authoritative servers for domains that don’t exist, wasting bandwidth and increasing latency.

The SOA record’s MINIMUM field specifies the TTL for negative cache entries. This value — typically 300 to 3600 seconds — controls how long an NXDOMAIN response is remembered before the resolver asks again.

DNSSEC

RFC 4033 — DNS Security Introduction and Requirements (March 2005) RFC 4034 — Resource Records for DNS Security Extensions (March 2005) RFC 4035 — Protocol Modifications for DNS Security Extensions (March 2005)

The DNSSEC trio. These three RFCs define the system that adds cryptographic authentication to DNS responses. RFC 4033 provides the overview, RFC 4034 defines the new record types (DNSKEY, RRSIG, DS, NSEC), and RFC 4035 specifies how resolvers validate signatures.

DNSSEC does not encrypt DNS traffic — it proves that a response has not been tampered with. See DNSSEC for a full explanation.

RFC 5155 — NSEC3 (March 2008)

Added hashed denial-of-existence records to prevent zone enumeration. With plain NSEC records, an attacker can walk the entire zone by following NSEC chains. NSEC3 replaces domain names with hashes, making enumeration computationally expensive.

Extension mechanisms

RFC 6891 — Extension Mechanisms for DNS (EDNS(0)) (April 2013)

The definitive EDNS specification, superseding the original RFC 2671. Defines the OPT pseudo-record that allows DNS messages to exceed 512 bytes, carry extension flags (like the DNSSEC OK bit), and transport option code/value pairs.

EDNS is the single most important protocol extension since the original RFCs. Without it, DNSSEC, DNS Cookies, Client Subnet, and padding would all be impossible.

RFC 7871 — Client Subnet in DNS Queries (May 2016)

Specifies the EDNS Client Subnet option, which allows resolvers to include a truncated client IP prefix in queries to authoritative servers. This enables CDN optimization but raises privacy concerns. See EDNS for the tradeoffs.

RFC 7873 — Domain Name System (DNS) Cookies (May 2016)

Defines lightweight transaction authentication using client and server cookies carried as EDNS options. Cookies defend against off-path spoofing and amplification attacks without the overhead of TSIG or DNSSEC.

Encrypted transports

RFC 7858 — DNS over TLS (DoT) (May 2016)

Specifies encrypted DNS over TLS on port 853. The first standardized encrypted DNS transport. See DNS Transport Protocols.

RFC 8484 — DNS over HTTPS (DoH) (October 2018)

Specifies DNS queries as HTTP requests over standard HTTPS on port 443. The most controversial DNS RFC in recent memory — it shifts DNS resolution into browsers, bypassing operating system resolvers and the network policies built on them.

RFC 9250 — DNS over Dedicated QUIC Connections (DoQ) (May 2022)

The newest encrypted DNS transport. Uses QUIC on UDP port 853, providing encryption with zero head-of-line blocking and connection migration for mobile devices.

Operations and best practices

RFC 1996 — DNS NOTIFY (August 1996)

Allows a primary nameserver to inform secondaries that the zone has changed, triggering an immediate zone transfer instead of waiting for the SOA refresh interval. Written by Paul Vixie. Essential for timely propagation of DNS changes.

RFC 2136 — Dynamic Updates in the DNS (April 1997)

Specifies how clients can add, delete, or modify resource records in a zone by sending UPDATE messages (opcode 5) to the authoritative server. Used by DHCP servers, Let’s Encrypt DNS-01 challenges, Active Directory, and cloud auto-scaling.

RFC 5936 — DNS Zone Transfer Protocol (AXFR) (June 2010)

The current specification for full zone transfers over TCP. AXFR transfers the complete contents of a zone from primary to secondary nameserver.

RFC 1995 — Incremental Zone Transfer (IXFR) (August 1996)

Allows secondary nameservers to request only the changes since their last transfer, rather than the full zone. Essential for large zones where full transfers would be wasteful.

RFC 7766 — DNS Transport over TCP (March 2016)

Elevated TCP from “fallback only” to first-class DNS transport. Required all DNS implementations to support TCP and specified connection reuse for amortizing handshake overhead.

Record types

RFC 3596 — DNS Extensions to Support IPv6 (AAAA) (October 2003)

Defined the AAAA record type for IPv6 addresses. With IPv6 adoption at 40–48% globally and AAAA queries growing 16% year-over-year, this RFC’s importance continues to increase.

RFC 2782 — DNS SRV Records (February 2000)

Defined the SRV record type for service location — specifying the hostname, port, priority, and weight for a service. Used extensively by Active Directory, XMPP, SIP, and Minecraft server discovery.

RFC 9460 — Service Binding and Parameter Specification via the DNS (SVCB and HTTPS) (November 2023)

The newest major record types. SVCB and HTTPS records allow DNS to advertise service parameters — including supported protocols (HTTP/2, HTTP/3), port numbers, and encryption keys — in a single lookup. This eliminates extra round trips that were previously needed to discover a server’s capabilities.

The essential reading list

For someone building on or operating DNS, these are the documents worth reading in full:

Priority	RFC	Title	Why
Must read	1035	Implementation and Specification	The protocol itself
Must read	2181	Clarifications	Corrects ambiguities in 1035
Must read	6891	EDNS(0)	The extension mechanism everything depends on
Should read	4033–4035	DNSSEC	Authentication of DNS data
Should read	8484	DNS over HTTPS	The most deployed encrypted DNS
Should read	7766	TCP Transport	Modern TCP requirements
Reference	2308	Negative Caching	Understanding NXDOMAIN TTLs
Reference	2136	Dynamic Updates	If you operate DNS zones
Reference	9250	DNS over QUIC	The future of encrypted DNS
Reference	9460	SVCB and HTTPS Records	The newest evolution

The full list of DNS-related RFCs is maintained in the IETF’s RFC index. But DNS is unusual among internet protocols in that its core specification — RFC 1035, written in 1987 — is still the authoritative reference for the message format used by every DNS query on earth. Extensions have been layered on top, but the foundation has never been replaced.