Delegation Signer (DS) 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
updated by
- rfc-3755 — Legacy Resolver Compatibility for Delegation Signer (DS)
updates
Extracted elements (23)
No backwards compatibility with RFC 2535 is provided. The DNSEXT Working Group determined that rapid adoption of DS is preferable to dealing with both RFC 2535-secured and DS-secured zones simultaneously, requiring a 'flag day' upgrade of nameservers and resolvers.
The DS model was chosen over storing signed KEY RRsets at the parent because RFC 2535 required frequent two-way communication between parent and child for key updates, and required NULL KEY records at every unsecure delegation (wasteful for large delegation zones). The DS approach reduces parent-child communication to only changes in the key that signs the apex KEY RRset.
The DS record includes both a key tag and a SHA-1 digest rather than just one, because two different mapping functions provide greater assurance than either alone. The algorithm and key tag fields allow resolvers to quickly identify candidate KEY records, and the compact format keeps delegation answer sizes small to reduce DNS message overflow probability.
It is difficult for a resolver to distinguish between a secure RFC 2535 delegation and an unsecure DS delegation because both lack a DS record in different ways. The NXT bit map patterns differ: secure DS has NS+SIG+NXT+DS bits; unsecure DS has NS+SIG+NXT; secure RFC 2535 has NS+SIG+NXT; unsecure RFC 2535 has NS+SIG+KEY+NXT.
RFC 2535-compliant resolvers will assume all DS-secured delegations are locally secure, which is incorrect. Old nameservers may be authoritative for zones with DS records but will not add NXT or DS records to the authority section; some caching nameservers may refuse to pass DS or NXT records.
A query for KEY RR MUST NOT trigger any additional section processing, and KEY records SHOULD NOT be added to the additional records section in response to any query. This replaces RFC 2535 section 3.5.
A secure zone MUST contain a self-signed KEY RRset at its apex. Upon verifying the DS RRset from the parent, a resolver MAY trust any KEY identified in the DS RRset as a valid signer of the child's apex KEY RRset.
All DNS servers and resolvers that support DS MUST support the OK bit (RFC 3225) and a larger message size (RFC 3226). A delegation is considered secure only if it contains a DS RRset.
An authoritative nameserver queried for type DS MUST return the DS RRset in the answer section. When authoritative for the parent zone at a delegation point, it MUST answer based on parent zone data regardless of also being authoritative for the child zone.
Digest type value 0 is reserved, value 1 is SHA-1, and reserving other types requires IETF standards action. Keeping the number of digest algorithms low is strongly RECOMMENDED for interoperability.
DS records MUST point to zone KEY records that are allowed to authenticate DNS data: the indicated KEY record's protocol field MUST be set to 3 and flag field bit 7 MUST be set to 1.
DS RRsets MUST NOT appear at non-delegation points or at a zone's apex. Each DS RRset stored in the parent zone MUST be signed by at least one of the parent zone's private keys. The parent zone MUST NOT contain a KEY RRset at any delegation point.
Parents MUST allow multiple DS records to facilitate key roll-over and support multiple KEY algorithms.
The KEY RRset at a zone's apex MUST be self-signed by a private key whose public counterpart appears in a zone signing KEY RR at the apex specifying a mandatory-to-implement algorithm, and this KEY RR MUST be identified by a DS RR in a signed DS RRset in the parent zone.
The signer's name field of a SIG RR 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.
When a nameserver is authoritative for the child zone at a delegation point but not the parent zone, it MUST answer DS queries with RCODE NOERROR, AA bit set, empty answer section, and SOA (plus optional SIG/NXT) in the authority section—as if it is authoritative and DS does not exist.
When a referral is returned for a delegation with the OK bit set, the nameserver MUST include NS RRset and DS+SIG(DS) (if DS exists) or NS RRset and NXT+SIG(NXT) (if no DS) in the authority section. If DS or NXT RRsets with signatures do not fit, the TC bit MUST be set.
The Delegation Signer (DS) RR (type code 43) is inserted at a zone cut in the parent zone to indicate that the delegated child zone is digitally signed and identifies the key(s) the child uses to self-sign its apex KEY RRset. It replaces the RFC 2535 model of storing signed KEY RRsets at the parent.
IANA allocated RR type code 43 for the DS resource record. IANA also established a new registry for DS RR digest algorithm types: value 0 is Reserved, value 1 is SHA-1. Adding new types requires IETF standards action.
An attacker attempting to forge child zone data by generating a KEY matching all DS fields would need to generate on average 2^(160 - number_of_keys_in_DS_set) keys; an attacker trying to match any DS record faces at least 2^80 key generations on average. This makes forgery computationally impractical given SHA-1's strength.
The DS protocol change requires the same parent-child authentication as RFC 2535, but allows the child greater local control over its KEY RRset. Implementations that do not understand DS will consider all DS-secured zones as unsecure, undermining the chain of trust.
A nameserver receiving a DS query applies these ordered rules: (1) if authoritative for the parent zone holding the DS RRset, return authoritative answer; (2) if recursive service with RD bit set, perform the query itself; (3) if authoritative for the child zone apex SOA, return authoritative negative answer; (4) if authoritative for an ancestor zone, return a referral; (5) otherwise, indicate lame nameserver.
The DS RDATA contains four fields: a 16-bit key tag, an 8-bit algorithm identifier, an 8-bit digest type, and a variable-length digest. For digest type 1 (SHA-1), the total RDATA is 24 bytes. The digest is computed as hash(canonical FQDN | KEY_RR_rdata), where KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key.