Domain Name System Security (DNSSEC) Signing Authority
obsoleted by
- rfc-4033 — DNS Security Introduction and Requirements
- rfc-4034 — Resource Records for the DNS Security Extensions
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
updated by
- rfc-3658 — Delegation Signer (DS) Resource Record (RR)
updates
- rfc-2535 — Domain Name System Security Extensions
Extracted elements (23)
Limiting material DNSSEC signatures to zone keys simplifies validation: the verification chain length is bounded by the name's label depth, and authority is clearly defined. A resolver does not need to make a complicated decision about whether a key has proper authority to sign data.
RFC 2535 originally allowed host and user keys to generate material DNSSEC signatures to permit dynamic update without online zone keys. However, online zone keys are unavoidable because they are necessary to sign NXT and SOA record sets (per RFC 3007), so the original motivation for allowing host/user key signatures no longer holds.
There is no additional flexibility granted by allowing host/user key material signatures: as long as users and hosts can authenticate update requests to the primary zone server, zone key signatures are sufficient to protect data integrity to the world at large.
This document updates RFC 2535 section 2.3.6 by restricting material DNSSEC signatures to zone keys only. Resolvers implementing RFC 2535 that accept host or user key signatures would be inconsistent with this revised model.
A SIG(0) generated by a client SHOULD have name type user or host. A SIG(0) generated by a nameserver SHOULD have name type host, as a nameserver is associated with a host and its SIG(0) use is not associated with a particular zone.
All SIG record field requirements defined in this document MUST be met for a DNSSEC-capable resolver to process the signature. If any requirement is not met, the SIG cannot be further processed.
For a data SIG, the type covered field MUST be the same as the type of data in the associated RRset. For a SIG(0), the type covered MUST be 0.
If a SIG record covers an RRset, the name type of the associated KEY MUST be 01 (zone). This updates RFC 2535 section 2.3.6. A DNSSEC resolver MUST ignore all keys that are not zone keys unless local policy dictates otherwise.
If the SIG record is a SIG(0) protecting a message, the name type of the associated KEY SHOULD be 00 (user) or 10 (host/entity). Zone keys SHOULD NOT generate SIG(0) records, as transactions are initiated by a host or user, not a zone.
The algorithm field of the signing KEY MUST be identical to that of the generated SIG record, and MUST meet all requirements for an algorithm value in a SIG record.
The algorithm specified in a SIG MUST be recognized by the client, and it MUST be an algorithm that has a defined SIG rdata format.
The current time at the time of validation MUST lie within the validity period bounded by the SIG's inception and expiration times.
The labels count in a SIG MUST be less than or equal to the number of labels in the SIG owner name, as specified in RFC 2535 section 4.1.3.
The original TTL in a SIG record MUST be greater than or equal to the TTL of the SIG record itself, since intermediate servers cannot increase the TTL. This field may be ignored for SIG(0) records.
The signer's name field in a SIG KEY at a zone apex SHOULD contain the parent zone's name, unless the KEY set is self-signed.
The signer's name field of a data SIG MUST contain the name of the zone to which the data and signature belong. The combination of signer's name, key tag, and algorithm MUST identify a zone key for the SIG to be considered material.
The signing KEY record MUST have a flags value of 00 or 01 (authentication allowed, confidentiality optional). A DNSSEC resolver MUST only trust signatures generated by keys that are permitted to authenticate data.
The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 (ALL). A DNSSEC resolver MUST NOT trust any signature generated by a key not specified for use with DNSSEC.
A SIG(0) record has a type covered field of 0 and is attached to a DNS message to protect message integrity, as opposed to data SIGs which cover RRsets. SIG(0) is defined in RFC 2535 and RFC 2931.
A SIG record is either a 'data SIG' covering an RRset (demonstrating its authenticity and integrity) or a SIG(0) covering a message for transaction security. Multiple SIG records may cover the same RRset; each must be validated independently. SIGs not bound to any RRset are considered immaterial.
A SIG record's materiality determines whether it is relevant to DNSSEC validation. Material SIGs must satisfy all requirements in this document. Immaterial (extra-DNSSEC) SIGs may have application-defined roles and require no DNSSEC validation.
Once a SIG's fields are validated, the resolver locates a KEY matching the signer name, key tag, and algorithm. If no matching KEY is found, the SIG is considered immaterial. If multiple KEYs are found, all are checked since the actual signing key cannot be determined prior to signature verification.
This document defines a standard baseline for DNSSEC-capable resolvers by placing additional restrictions on SIG records that must be validated before a signature can be trusted. These restrictions simplify the protocol, making it more robust and suitable for security analysis.