Limiting the Scope of the KEY Resource Record (RR)
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
updates
- rfc-2535 — Domain Name System Security Extensions
Extracted elements (18)
A compromise of an application key stored in the KEY RR could allow an attacker to forge DNS data from the affected zone and all sub-zones if resolvers do not carefully check the KEY sub-type. Separating application keys from DNSSEC keys eliminates this vulnerability entirely.
Application keys are not part of the DNS chain of trust and are never configured as trusted keys in the DNS hierarchy, whereas DNSSEC zone keys must be exchanged with parent zones and authenticated via chain of trust. Mixing them forces resolvers to handle application keys as if they were DNS infrastructure, creating unnecessary complexity.
Storing DNSSEC keys and application keys (Email, IPSEC, TLS) in the same KEY RR sub-type is a mistake because they differ in purpose, management, authentication rules, nameserver handling, resolver processing, and fault consequences. A resolver cannot request a specific sub-type directly and must retrieve the entire KEY RR set, and DNSSEC signatures apply to the entire set regardless of sub-type.
DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible under this specification, but the distinction between host keys and user keys (flag bit 6) is permanently lost.
DNSSEC zone KEY RRs remain fully backwards compatible: a properly formatted RFC 2535 zone KEY would already have all flag bits except bit 7 set to 0 and the protocol octet set to 3, which is exactly what this document requires.
No backwards compatibility is provided for application keys (Email, IPSEC, TLS). Any such keys stored in KEY RRs are now deprecated, and the problems they caused (keys at the zone apex, large RR sets) motivated this change regardless.
All flag bits in the KEY RR except bit 7 (Zone bit) MUST be set to zero. Bit 7 indicates whether the key is a DNS Zone key.
Assignment of any future KEY RR Flag values or Protocol Octet values requires a standards action.
KEY RRs with a protocol octet value other than 3 MUST NOT be used to authenticate DNS data, even if they appear in an accepted KEY RR set.
Name servers and resolvers SHOULD accept KEY RR sets that contain KEY RRs with a protocol octet value other than 3, to avoid invalidating associated SIG records or creating caching consistency problems with out-of-date zones.
The A/C bits (bits 0 and 1) in the KEY RR flags field are eliminated; they MUST be set to 0 and MUST be ignored by the receiver.
The authoritative data for a zone MUST NOT include any KEY records with a protocol octet other than 3.
The extended flags bit (bit 3), the host/user bit (bit 6), and the signatory field (bits 12-15) are all eliminated; each MUST be set to 0 and MUST be ignored by the receiver.
The protocol field in the KEY RR MUST be set to 3 (DNSSEC). All other protocol octet values are now reserved.
The KEY RR uses type 25 and is restricted to storing DNSSEC keys only. In the flags field, all bits except bit 7 (Zone bit) are reserved. Bit 7 set to 1 indicates a DNS Zone key; set to 0 indicates a non-zone DNSSEC key (e.g., SIG(0)/TKEY).
The IANA registry for DNS KEY RR Protocol Octet values is closed for new assignments. Values 1 (Email), 2 (IPSEC), 4 (TLS), and 255 (ANY) are re-assigned to RESERVED; value 3 (DNSSEC) remains unchanged; values 5-254 remain reserved. Future assignments require a standards action.
Prior to this document, a compromised application key stored in the KEY RR could be used as a false DNS zone key to generate false SIG records. Resolvers that did not carefully check the KEY sub-type would accept these false signatures and incorrectly authenticate DNS data. Restricting the KEY RR to DNSSEC use eliminates this vulnerability entirely.
The KEY RR RDATA consists of a 16-bit flags field, an 8-bit protocol octet, an 8-bit algorithm field, and a variable-length public key. The format is unchanged from RFC 2535; only the semantics of the flags and protocol fields are restricted.