The DS RR is stored in the parent zone rather than the child zone to simplify DNS zone management and zone signing, though it introduces special response processing requirements. The Key Tag and algorithm are stored alongside the digest to make identification more efficient, since digest lookup alone would be sufficient but slower.

dns

The Original TTL field in RRSIG is necessary because caching resolvers decrement the TTL of cached RRsets. To validate a signature, a validator needs the original TTL as it appeared in the authoritative zone, which cannot be recovered from a decremented value.

dns

The Protocol Field in DNSKEY RDATA always has value 3 but is retained in the wire format for backward compatibility with early versions of the KEY record, which allowed other protocol values.

dns

The RSA/MD5 algorithm (algorithm 1) is included in Appendix A for completeness but is NOT RECOMMENDED per RFC 3110. Its key tag calculation also differs from all other algorithms: it uses the most significant 16 bits of the least significant 24 bits of the public key modulus.

dns, crypto

A DNSSEC-aware resolver or name server MUST implement all MANDATORY algorithms. At the time of this document, RSA/SHA-1 (algorithm 5) is MANDATORY for zone signing, and SHA-1 (digest type 1) is MANDATORY for DS records.

dns, crypto, security

A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR. A zone MUST NOT include an NSEC RR for any domain name that only holds glue records.

dns

An RRSIG and NSEC MUST exist for the same name as a CNAME resource record in a signed zone. This is a change from RFC 1034, which stated that CNAME is the only type allowed at a name.

dns

An RRSIG RR MUST have the same class as the RRset it covers, and the TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers.

dns

DNSKEY flags bits 0-6 and 8-14 are reserved: they MUST have value 0 upon creation and MUST be ignored upon receipt. A DNSKEY RR with the SEP bit set but the Zone Key flag not set MUST NOT be used to verify RRSIGs.

dns, security

If an implementation detects duplicate RRs when putting an RRset into canonical form, it MUST treat this as a protocol error. If choosing to handle it robustly, it MUST remove all but one of the duplicate RRs for canonical form calculation purposes.

dns

In NSEC Type Bit Maps, bits representing pseudo-types MUST be clear. Blocks with no types present MUST NOT be included, and trailing zero octets in a bitmap MUST be omitted.

dns

The DNSKEY RR MUST NOT be used to store certificates or public keys that do not directly relate to the DNS infrastructure.

dns, security

The Protocol Field in a DNSKEY RR MUST have value 3. If it is found to be any other value during signature verification, the DNSKEY RR MUST be treated as invalid.

dns, security

The RRSIG record MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date. All comparisons involving these time fields MUST use serial number arithmetic as defined in RFC 1982.

dns, security

The Signer's Name field MUST contain the name of the zone of the covered RRset. A sender MUST NOT use DNS name compression on the Signer's Name field when transmitting a RRSIG RR.

dns

When validating using a DS RR, the referenced DNSKEY RR MUST be a DNSSEC zone key (Flags bit 7 set). If the DNSKEY flags do not indicate a zone key, the DS RR and the referenced DNSKEY RR MUST NOT be used in the validation process.

dns, security

Canonical DNS name ordering sorts names by treating labels as unsigned left-justified octet strings, starting from the most significant (rightmost) label, with uppercase US-ASCII treated as lowercase. This ordering is required for constructing the NSEC chain and for signing/verifying RRSIGs.

dns

Canonical RR form for DNSSEC requires: fully expanded and qualified domain names (no compression), lowercase owner name, lowercase DNS names in RDATA for specified RR types, wildcard owner names in unexpanded form, and TTL set to the original authoritative value.

dns, crypto

The DNSKEY RR (type 48) stores public keys used in DNSSEC. Its RDATA consists of a 2-octet Flags field, a 1-octet Protocol field (always 3), a 1-octet Algorithm field, and a variable-length Public Key field.

dns, crypto, security

The DS RR (type 43) links the DNSSEC authentication chain across zone boundaries. It stores the Key Tag, Algorithm number, and a cryptographic digest of the referenced DNSKEY RR. The DS RR appears only on the parental side of a delegation, in the parent zone.

dns, crypto, security

The Labels field in RRSIG specifies the number of labels in the original RRSIG owner name (excluding the root label and any wildcard label). Validators use it to determine whether an answer was synthesized from a wildcard and to reconstruct the original owner name for signature validation.

dns, security

The NSEC RR (type 47) lists the next owner name in canonical zone order that has authoritative data or a delegation NS RRset, and the set of RR types present at the NSEC owner name. Together, NSEC RRs form a chain enabling authenticated denial of existence.

dns, security

The RRSIG RR (type 46) carries the digital signature for a DNS RRset. It specifies the Type Covered, Algorithm, Labels count, Original TTL, Signature Expiration, Signature Inception, Key Tag, Signer's Name, and the Signature itself.

dns, crypto, security

IANA registries relevant to DNSSEC: DNS Resource Record Types (DNSKEY=48, RRSIG=46, NSEC=47, DS=43); DNS Security Algorithm Numbers (values 1-5 and 252-255 defined; 6-251 available by IETF Standards Action); DNSSEC DS Digest Types (0=reserved, 1=SHA-1 MANDATORY); DNSKEY/KEY flag bits (bit 7=ZONE, bit 15=SEP).

dns, registry, crypto

The DS record identifies a DNSKEY by digest, key algorithm, and key tag, but it is theoretically possible for an attacker to construct a DNSKEY matching all DS fields. The SHA-1 digest makes this sufficiently difficult to not be a serious threat at the time of writing. Additionally, the key tag is not a unique identifier—two distinct DNSKEY RRs may share the same owner name, algorithm, and key tag, so implementations MUST NOT use only the key tag to select a DNSKEY.

dns, security, crypto

DNSKEY RDATA wire format: 2-octet Flags field, 1-octet Protocol field, 1-octet Algorithm field, followed by a variable-length Public Key field. Flags bit 7 is the Zone Key flag; bit 15 is the Secure Entry Point flag.

dns, crypto

DS RDATA wire format: 2-octet Key Tag field, 1-octet Algorithm field, 1-octet Digest Type field, and a variable-length Digest field. The digest is computed over the canonical owner name concatenated with the DNSKEY RDATA.

dns, crypto

NSEC RDATA wire format: variable-length Next Domain Name field (uncompressed wire-format domain name) followed by a Type Bit Maps field. The Type Bit Maps field uses 256 window blocks, each encoded as a 1-octet window number, 1-octet bitmap length (1-32), and up to 32 octets of bitmap.

dns

RRSIG RDATA wire format: 2-octet Type Covered, 1-octet Algorithm, 1-octet Labels, 4-octet Original TTL, 4-octet Signature Expiration, 4-octet Signature Inception, 2-octet Key Tag, variable-length Signer's Name (uncompressed), and variable-length Signature.

dns, crypto