Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)
Extracted elements (18)
Clients are under no obligation to list every algorithm they implement and MAY choose to list only the algorithms they wish to signal. PRIVATEDNS (253) and PRIVATEOID (254) codes are noted as unlikely to be useful to a server and need not be included.
The DAU, DHU, and N3U options are intended to let zone administrators measure client adoption of new algorithms so they can determine when it is safe to complete a DNSSEC algorithm rollover. The survey may span years before a tipping point is reached.
The document explicitly does not introduce a new process for approving DNSSEC algorithms nor recommend which algorithms are mandatory or preferred; it only specifies the signaling mechanism.
Intermediate DNS proxies are RECOMMENDED to behave like a comparable recursive resolver when dealing with the DAU, DHU, and N3U options, per the guidance in RFC 5625 Section 4.4.2.
A validating end-system resolver that sets DAU/DHU/N3U options MUST also set the DNSSEC OK (DO) bit to indicate it wishes to receive DNSSEC RRs in the response.
Authoritative servers MUST NOT perform any special processing (e.g., RRSIG filtering) triggered by the DAU, DHU, or N3U options, and MUST NOT set these options in any responses.
Clients MUST NOT include RESERVED algorithm codes in any of the DAU, DHU, or N3U options.
If a client sees DAU, DHU, or N3U options in a response, it MUST ignore the option values; these options are only meaningful in queries.
Non-validating recursive resolvers MUST copy the DAU, DHU, and/or N3U option(s) from received queries unchanged, as they represent the wishes of the validating downstream resolver.
Non-validating stub resolvers MUST NOT include the DAU, DHU, or N3U EDNS0 options in queries.
The order of ALG-CODE values within a DAU, DHU, or N3U option MUST NOT be used to infer preference.
Validating recursive resolvers MUST NOT set the DAU, DHU, and/or N3U option(s) in the final response to the stub client.
Validating stub resolvers SHOULD include the DAU, DHU, and/or N3U option(s) in the OPT RR when sending a query.
When a validating recursive resolver receives a query with DAU/DHU/N3U options set, it MUST set the algorithm list for outgoing iterative queries to the union of the stub client's list and the resolver's own list.
Three new EDNS0 options are defined for clients to signal algorithm support: DAU (DNSSEC Algorithm Understood, option code 5), DHU (DS Hash Understood, option code 6), and N3U (NSEC3 Hash Understood, option code 7). Each option is carried in the OPT meta-RR and is OPTIONAL to implement and use.
IANA allocated option codes 5 (DAU), 6 (DHU), and 7 (N3U) in the 'DNS EDNS0 Option Codes (OPT)' registry, each with status 'standard'. Existing DNSSEC algorithm, DS hash, and NSEC3 hash registries are unchanged.
An eavesdropper or server could infer the DNSSEC validator implementation in use by a client from the presence and content of the DAU/DHU/N3U options. This fingerprinting could narrow down the validator software and potentially expose known vulnerabilities to an attacker.
Each DAU/DHU/N3U option is encoded with a 16-bit OPTION-CODE, a 16-bit LIST-LENGTH (number of octets in the algorithm list), and a variable-length ALG-CODE list where each algorithm code occupies a single octet.