Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator
updates
Extracted elements (25)
On-demand triggers (like notifications) are preferred over timer-based triggers (such as daily scans) because timer-based mechanisms exhibit undesirable properties with respect to processing delay and scaling. Both child DNS operators and parental agents are encouraged to use on-demand triggers to reduce delays and scanning traffic.
Signaling domains SHOULD be delegated as standalone zones so that the signaling zone apex coincides with the signaling domain (e.g., _signal.ns1.example.net). This ensures that bootstrapping activities do not require modifications to the zone containing the nameserver hostname.
The protocol is designed as a generic signaling mechanism, not just for DNSSEC bootstrapping. The '_dsboot' signaling type is one application; other applications could include publishing operational metadata or API endpoints. This generality is why the mechanism uses a signaling type label to namespace different use cases.
DNSSEC bootstrapping does not work for fully in-domain delegations because no preexisting chain of trust to the child domain exists during bootstrapping. A workaround is to temporarily add an out-of-domain nameserver to the NS RRset and remove it after bootstrapping is complete, potentially using CSYNC records (RFC 7477).
The DS enrollment methods in Section 3 of RFC 8078 are less secure than the method in this document. Child DNS operators and parental agents wishing to use CDS/CDNSKEY records for initial DS enrollment SHOULD support the authentication protocol described in this document instead.
The protocol does not support unusually long child domain names or NS hostnames, as fully qualified signaling names must be valid DNS names subject to the label count and length requirements of RFC 1035 Section 3.1.
This document updates RFC 7344 by removing the apex-only location restriction for CDS/CDNSKEY records (Section 4.1 of RFC 7344), enabling use of these record types at non-apex owner names for DNSSEC bootstrapping signaling.
A signaling RRset MUST be signed with the corresponding signaling zone's key(s), and its contents MUST be identical to the corresponding CDS/CDNSKEY RRset published at the child's apex.
Each signaling zone MUST be signed and be validatable by the parental agent, i.e., have a valid publicly resolvable DNSSEC chain of trust. This is typically achieved by securely delegating each signaling zone.
It is RECOMMENDED that QNAME minimization (RFC 9156) be used when resolving queries for signaling records, to guard against forgery attacks where an upstream parent of a signaling domain intercepts CDS/CDNSKEY queries and responds with a fraudulent authoritative answer.
It is RECOMMENDED that queries into signaling domains be performed with an initially empty resolver cache, or that some other method for retrieving fresh data from authoritative servers be used, to avoid stalemate situations from stale cached records causing RRset mismatch in Step 4.
Parental agents SHOULD trigger the bootstrapping validation procedure when receiving new/updated NS RRsets, receiving a notification from the child, encountering signaling records during proactive scans, or encountering signaling records during NSEC walks or zone parsing.
Signaling records MUST be accompanied by RRSIG records created with the corresponding signaling zone's key(s). The type and contents of signaling records depend on the type of signal.
The parental agent MUST abort the bootstrapping procedure on any error, including: the child already being securely delegated or having only in-domain nameservers; retrieval failure from any authoritative nameserver; DNSSEC validation failure or unauthenticated data (AD bit not set) for any signaling record; or inconsistent RRsets across direct and signaling queries.
There MUST NOT be a zone cut at a signaling name, in order to exclude the possibility of semantic collision from extending CDS/CDNSKEY use to non-apex owner names.
To signal consent to act as the child's signer, the child DNS operator MUST copublish the child's CDS/CDNSKEY RRsets at the corresponding signaling name under each signaling domain, excluding those that would fall within the child domain.
To validate CDS/CDNSKEY records for DNSSEC bootstrapping, the parental agent MUST execute four steps: (1) verify no DS records exist and at least one NS is out-of-domain; (2) query CDS/CDNSKEY directly from all authoritative servers without caching; (3) query CDS/CDNSKEY at each signaling name via a trusted DNSSEC-validating resolver; (4) verify all retrieved RRsets have equal contents by record type.
When discovering signaling names via NSEC walk or zone transfer, the parental agent MUST NOT assume that a nameserver under whose signaling domain a signaling record appears is actually authoritative for the corresponding child. The parental agent MUST ascertain that the delegation contains the nameserver hostname seen during discovery before querying signaling records.
A signaling domain is constructed by prepending the label '_signal' to a nameserver hostname taken from a delegation's NS RRset. There are as many signaling domains as there are distinct NS targets for a given delegation.
A signaling name is formed by prepending a signaling type label (e.g., '_dsboot' for DNSSEC bootstrapping) and the child zone name (without the root label) to the signaling domain. For example, bootstrapping 'example.co.uk' via 'ns1.example.net' produces '_dsboot.example.co.uk._signal.ns1.example.net'.
IANA has added two entries to the 'Underscored and Globally Scoped DNS Node Names' registry (RFC 8552): '_signal' for RR type CDS and '_signal' for RR type CDNSKEY, both referencing RFC 9615.
If QNAME minimization is not used when querying for signaling records, an upstream parent of a signaling domain will see the CDS/CDNSKEY queries and could respond with a fraudulent authoritative answer signed with its own key rather than returning a referral. Using QNAME minimization reduces this attack surface.
The bootstrapping method's security level is strictly higher than existing RFC 8078 approaches such as 'Accept after Delay', because it adds cryptographic authentication to the CDS/CDNSKEY concept. The same security considerations from RFC 8078 otherwise apply.
The requirement that all RRsets retrieved from all nameservers and all signaling domains must agree ensures that in a multi-homed setup, an operator cannot enable DNSSEC unless all other operators agree. This prevents publication of an ill-conceived DS RRset authorized under only a subset of NS hostnames.
To prevent the parents of nameserver hostnames from becoming single points of failure (both for resolution availability and for the protocol's trust model), operators are advised to diversify the path from the root to nameserver hostnames, for example by using different independently operated TLDs for each nameserver.