Domain Name System Security Extensions
Extracted elements (31)
No access control lists or confidentiality for queries/responses are provided, following the DNS design philosophy that data in the DNS is public and the same answers are given to all inquirers. Confidentiality may be available via IPsec. The security extensions focus solely on data integrity and authentication.
The labels field in SIG RDATA counts how many labels are in the original owner name (excluding root label and wildcard '*'). This allows resolvers to detect wildcard substitution and use the original form of the name for signature verification, optimizing the determination without requiring the resolver to track the query chain.
The NXT name space is treated as circular: the last NXT in a zone has its RDATA set to the zone name itself, handling the problem of indicating the entire remainder of the name space beyond the last existing name without needing a special sentinel value.
The original TTL is included in the SIG RDATA rather than relying solely on the current TTL field to prevent two problems: (1) caching servers would cause authentication failures by decrementing the real TTL, and (2) unscrupulous servers could manipulate TTL values undetected. A security-aware resolver bounds the TTL at the original signed value.
Transaction SIGs cannot be pre-calculated because requests and replies are highly variable, requiring the private key to be kept on-line (in software or directly connected hardware). This is in contrast to zone SIGs, which are pre-computed offline. The transaction SIG is signed by the host key, not the zone key.
Minimal server conformance requires ability to store, retrieve, and zone-transfer SIG, KEY, and NXT RRs; any secondary, caching, or other server for a secure zone MUST be at least minimally compliant. Full compliance additionally requires reading these RRs in zone files, generating SIG/NXT RRs, proper automatic inclusion in responses, CNAME suppression, CD/AD bit handling, and proper delegation point NXT handling.
Old (non-security-aware) servers and resolvers return zero for the AD and CD bits. This ensures backward compatibility: responses from old servers are not flagged as authenticated, and queries from non-security-aware resolvers (CD=0) will be answered by security-aware servers only with Authenticated or Insecure data.
An appropriate zone KEY RR MUST occur at the apex node of a secure zone and at every delegation point within a secure zone. Security aware DNS implementations MUST be designed to handle at least two simultaneously valid keys of the same type associated with a name.
Every authoritative secure zone server MUST also include a KEY RR for its super-zone signed by the secure zone via a keyfile directive, enabling resolvers to climb the zone tree if starting below root. A secure sub-zone is indicated by a non-null KEY RR appearing alongside NS RRs.
If a resolver does not implement transaction and/or request SIGs, it MUST ignore them without error. A transaction authentication SIG does NOT authenticate any RRs in the message; only a proper zone SIG or a key tracing authority to the zone can authenticate RRs.
If time synchronization protocols such as NTP are used, they MUST be used securely so that time cannot be spoofed. Otherwise a host could have its clock set back and accept old SIG and KEY RRs that were once valid but are no longer.
Resolvers MUST NOT trust the AD bit unless they trust the server they are talking to and either have a secure path to it or use DNS transaction security. Security aware resolvers SHOULD assert the CD bit on all queries to reduce DNS latency by allowing servers to answer before fully validating data.
Security aware DNS servers MUST, for every authoritative RR returned, attempt to send the SIG RRs that authenticate it. When an RR set is in a response, its SIG has higher inclusion priority than other additional RRs; if space does not permit its inclusion, the response MUST be considered truncated (except for additional information section RRs).
Security aware DNS servers MUST include KEY RRs as additional information in responses: zone key KEY RR(s) MUST be included on NS RR retrieval, and end entity KEY RR(s) MUST be included on A or AAAA RR retrieval, if space is available. If the zone KEY RR does not fit, the retrieval must be considered truncated.
Security aware servers in a secure zone MUST use security-aware servers to securely handle CNAME processing. Specifically, they must (1) allow KEY, SIG, and NXT RRs coexisting with CNAME RRs, (2) suppress CNAME processing on retrieval of those types, and (3) automatically return SIG RRs authenticating encountered CNAMEs.
The AD bit MUST NOT be set in a response unless all RRs in the response are either Authenticated or Insecure. Security aware servers MUST return only Authenticated or Insecure data with AD set when the CD bit is clear (i.e., for non-security-aware resolvers or those not requesting pending data).
The RSA modulus size for MD5/RSA (algorithm 1) SHALL be not less than 512 bits and not more than 2552 bits. The modulus n and exponent e SHOULD be chosen such that the public exponent is small. Leading zero bytes are not permitted in the signature.
The KEY resource record (type 25) stores a public key associated with a DNS name. It includes a 16-bit flags field, an 8-bit protocol octet, an 8-bit algorithm number, and the variable-length public key. It can represent zone keys, host/entity keys, or user keys, with flag bits distinguishing these roles.
The NXT resource record (type 30) provides authenticated denial of existence. Its RDATA contains the next existing domain name in canonical order and a bit map indicating which RR types exist for the owner name. NXT records cover a name interval, asserting no names exist between the owner and the next name.
The SIG resource record (type 24) provides cryptographic authentication for other DNS RRs. Its RDATA includes: type covered (16 bits), algorithm (8 bits), labels count (8 bits), original TTL (32 bits), signature expiration (32 bits), time signed (32 bits), key footprint (16 bits), signer's name (variable), and the signature (variable).
Two new DNS header bits are defined: AD (Authentic Data, bit 10) set in responses to indicate the server has verified the data, and CD (Checking Disabled, bit 11) set in queries to indicate the resolver accepts non-verified data. Both bits are zero in old servers and resolvers, ensuring backward compatibility.
This document creates the KEY algorithm number registry. Algorithm 1 is MD5/RSA. Numbers 2-252 are available for IETF standards action assignment. Number 253 is the 'expiration date algorithm' (null signature, for use with dynamic update). Number 254 is reserved for private use with OID-identified algorithms. Values 0 and 255 are reserved.
This document creates the KEY protocol octet registry. Values 1-191 are available for IANA assignment to specific protocols. Values 192-254 are reserved for experimental use under bilateral agreement. Value 0 means not valid for any additional protocol. Value 255 means valid for all assigned protocols (1-191).
A security-conscious resolver should refuse to step from a secure zone into a non-secure zone unless the non-secure zone is certified as non-secure or experimentally secure by an authenticated KEY RR with no-key type value or the experimental bit set. Zones reachable only via non-secure zones cannot be trusted, and their distance metric should be set to 512 or more.
If wildcards exist in a zone, a malicious server can return the wildcard-match NXT instead of more specifically named RRs, hiding their existence. With a zone-wide wildcard, a server could conceal all more-specific RRs. A more strict NXT design could eliminate this but would make dynamic update very difficult.
NXT records enable 'NXT walking': a resolver can iteratively query for successive NXT records to enumerate all names in a zone, defeating administrative zone transfer restrictions. Zones can mitigate this by adding a zone-wide wildcard KEY RR with the no-key type value, but at the cost of eliminating authenticated denial-of-existence for names.
Zone private keys and zone file master copies should be kept on off-line, physically secure, non-network-connected machines. The zone file should be signed offline and then transferred to network servers by sneaker-net or similar one-way mechanisms to prevent tampering from the network. Compromise of all servers for a zone does not affect the data authenticity assurance.
A security-aware server categorizes cached data into four states: Authenticated (valid SIG chain to a configured key), Pending (no authenticated SIG but at least one still being verified), Insecure (in or reached via a non-secured zone, can never be authenticated), and Bad (all SIG checks explicitly failed; data is not retained).
KEY RDATA encodes: flags (16 bits), protocol (8 bits), algorithm (8 bits), followed by the public key in algorithm-dependent format. For MD5/RSA (algorithm 1), the public key field contains: exponent length (1 octet for lengths 1-255, or 0 + 2-octet length for longer), the exponent, and the modulus. Leading zero bytes are prohibited.
NXT RDATA encodes the next domain name (variable length, compressible) followed by a type bit map (one bit per RR type). Bit 30 (NXT itself) is always set, so the minimum bit map is 4 octets. Bits beyond the end of the map are treated as zero.
SIG RDATA packs type covered (2 octets), algorithm (1 octet), labels (1 octet), original TTL (4 octets), signature expiration (4 octets, seconds since 1970-01-01), time signed (4 octets), key footprint (2 octets), signer's name (compressed DNS name), and the variable-length signature. A SIG with expiration before time signed is corrupt and must be ignored.