ietf-corpus

rfc-1035

Domain names - implementation and specification

P. Mockapetris
date1987-11 streamLegacy statusINTERNET STANDARD pages55 canonicalhttps://www.rfc-editor.org/rfc/rfc1035 doi10.17487/RFC1035 errataview
This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.

obsoletes

updated by

also

Extracted elements (30)

design-rationale §3.6

DNS stores multiple values of a type as multiple RRs rather than as multiple values inside a single RR's RDATA. This keeps individual RRs shorter and simplifies caching, at the cost of some efficiency for bulk retrieval.

dns

design-rationale §3.5

IPv4 addresses in IN-ADDR.ARPA are written in reversed-octet order so that DNS zones can be delegated to match exactly one network of address space (e.g., 10.IN-ADDR.ARPA covers all of net 10). The awkward reversal is intentional to align zone boundaries with network boundaries.

dns, ip

design-rationale §3.6

The original MD/MF dual-type mail exchange design was replaced by a single MX type with a numeric PREFERENCE field. The old scheme caused cache coherence problems: a cache populated by an MF-only query would not signal the absence of MD records, making it impossible to safely use partial results.

dns, email

interoperability-note §4.1.4

Compression pointers may only be used in domain name positions whose format is not class-specific. This ensures name servers and resolvers do not need to understand all possible RR formats in order to follow pointers correctly.

dns

normative-requirement §6.1.1 MUST

A name server must support multiple concurrent activities and must not block UDP query service while waiting for TCP data (zone refresh or recursive queries). Identical requests from the same client may be treated as duplicates.

dns

normative-requirement §4.1.4 MUST

All DNS implementations must understand arriving messages that contain compression pointers, even if they choose not to generate pointers in messages they send.

dns

normative-requirement §2.3.3 MUST

All DNS label comparisons must be done case-insensitively (A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly. Original case should be preserved whenever possible when data enters the system.

dns

normative-requirement §4.2 MUST

DNS uses server port 53 (decimal) for both UDP (standard queries) and TCP (zone transfers and other operations). Zone refresh activities must use TCP (virtual circuits) for reliable transfer.

dns, tcp, udp

normative-requirement §6.3 MUST NOT

During a zone transfer via AXFR, a master must never send part of one zone version and part of another. If a new version is created mid-transfer, the master should continue with the old version or reset the connection.

dns

normative-requirement §3.3.13 MUST

The SOA MINIMUM field acts as a floor on the TTL of all RRs sent from a zone; a name server must apply this floor when copying RRs into a response, not when loading the zone.

dns

normative-requirement §4.1.1 MUST

The Z (reserved) bits in the message header must be zero in all queries and responses.

dns

normative-requirement §4.2.1 MUST

UDP DNS messages must not exceed 512 bytes (excluding IP/UDP headers). Messages exceeding this limit are truncated and the TC bit must be set in the header.

dns, udp

normative-requirement §5.2 SHOULD

Zone loading from a master file should be suppressed entirely if any errors are encountered, since a single syntax error (e.g., in delegation RRs) can cause a server to return authoritative errors for an entire subzone.

dns

protocol-element §3.2.4

CLASS values: IN=1 (Internet), CS=2 (CSNET, obsolete), CH=3 (CHAOS), HS=4 (Hesiod). QCLASS adds *=255 (any class).

dns, registry

protocol-element §2.3.4

DNS enforces size limits: labels must be 63 octets or less, total domain names must be 255 octets or less, TTL is a positive 32-bit signed integer, and UDP messages are limited to 512 octets.

dns

protocol-element §4.1

DNS messages are divided into five sections: Header (always present), Question (query parameters: QNAME, QTYPE, QCLASS), Answer (RRs answering the query), Authority (RRs pointing to authoritative servers), and Additional (related RRs).

dns

protocol-element §3.2.3

QTYPE values extend TYPE to include AXFR=252 (zone transfer request), MAILB=253 (mailbox-related records), MAILA=254 (obsolete), and *=255 (any record type).

dns, registry

protocol-element §4.1.1

RCODE field in the response header encodes: 0=NoError, 1=FormErr (can't interpret query), 2=ServFail (name server problem), 3=NXDomain (name does not exist, authoritative only), 4=NotImp (unsupported query type), 5=Refused (policy refusal); 6–15 reserved.

dns

protocol-element §3.2.2

RR TYPE values: A=1 (host address), NS=2 (name server), CNAME=5 (alias), SOA=6 (start of authority), MX=15 (mail exchange), TXT=16 (text), PTR=12 (pointer), HINFO=13 (host info). MD=3 and MF=4 are obsolete; types 7–10 are experimental.

dns, registry

protocol-element §3.5

The IN-ADDR.ARPA domain provides reverse DNS: an IPv4 address is written in reversed-octet label form (e.g., 10.2.0.52 → 52.0.2.10.IN-ADDR.ARPA) with PTR records pointing to canonical host names. Network-level nodes carry PTR records for gateway discovery.

dns, ip

security-consideration §3.5

IN-ADDR.ARPA reverse-DNS data and the forward DNS zone for the same host reside in different zones, so inconsistency between them is possible. Additionally, gateway routing table initialization using DNS requires pre-configured bootstrap name server addresses to avoid a chicken-and-egg dependency.

dns, security

state-machine §6.3

If a server cannot load zone data from its master file (e.g., syntax errors) or cannot refresh a zone before its EXPIRE deadline, it must answer queries as though it is not authoritative for that zone, effectively falling back to a non-authoritative state until the zone is successfully reloaded.

dns

wire-format §3.4.1

A RDATA contains a single 32-bit Internet address (ADDRESS field). Hosts with multiple addresses have multiple A records.

dns, ip

wire-format §4.1.1

DNS message header is 12 bytes containing: ID (16-bit), QR (1-bit), OPCODE (4-bit), AA, TC, RD, RA flags (1-bit each), Z reserved (3-bit, must be zero), RCODE (4-bit), followed by QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT (each 16-bit unsigned).

dns

wire-format §3.1

Domain name labels are encoded as a one-octet length field followed by that many octets of label data; the high-order two bits of each length octet must be zero, limiting labels to 63 octets. The name is terminated by a zero-length octet (root label).

dns

wire-format §4.1.4

Message compression replaces a domain name or suffix with a two-octet pointer whose top two bits are both 1 (0xC0 mask), with the remaining 14 bits giving the byte offset from the start of the message (the ID field). Labels begin with two zero bits, making label vs. pointer unambiguous.

dns

wire-format §3.3.9

MX RDATA encodes a 16-bit PREFERENCE integer (lower value = higher priority) followed by an EXCHANGE domain name identifying the mail-exchange host.

dns, email

wire-format §3.2.1

Resource records share a common wire format: NAME (variable domain name), TYPE (2 octets), CLASS (2 octets), TTL (32-bit signed integer in seconds), RDLENGTH (16-bit unsigned), and RDATA (variable, RDLENGTH octets).

dns

wire-format §3.3.13

SOA RDATA contains MNAME and RNAME (domain names), SERIAL (32-bit unsigned), REFRESH, RETRY, EXPIRE (32-bit time intervals), and MINIMUM (32-bit unsigned minimum TTL for the zone). All time values are in seconds.

dns

wire-format §4.2.2

TCP DNS messages are prefixed with a 2-byte length field (big-endian) giving the message length excluding the length field itself, allowing the receiver to assemble a complete message before parsing.

dns, tcp