1.1.Terminology

This section defines the terminology used in this document.¶

CDS/CDNSKEY:

This notation refers to CDS and/or CDNSKEY, i.e., one or both.¶

Child:

SeeSection 7 of [RFC9499].¶

Child DNS operator:

The entity that maintains and publishes the zone information forthe child DNS.¶

Parent:

SeeSection 7 of [RFC9499].¶

Parental agent:

The entity that has the authority to insert DS records into theparent zone on behalf of the child.(It could be the registry, registrar, a reseller, or some otherauthorized entity.)¶

Signaling domain:

A domain name constructed by prepending the label_signal to ahostname taken from a delegation's NS RRset.There are as many signaling domains as there are distinct NStargets.¶

Signaling name:

The labels that are prefixed to a signaling domain in order toidentify a signaling type and a child zone's name (seeSection 3.2).¶

Signaling record:

A DNS record located at a signaling name under a signaling domain.Signaling records are used by the child DNS operator to publishinformation about the child.¶

Signaling type:

A signal type identifier, such as_dsboot for DNSSEC bootstrapping.¶

Signaling zone:

The zone that is authoritative for a given signaling record.¶

1.2.Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.1.Chain of Trust

If a child DNS operator implements this specification, each signalingzoneMUST be signed and be validatable by the parental agent (i.e., havea valid publicly resolvable DNSSEC chain of trust).This is typically achieved by securely delegating each signaling zone.¶

For example, when publishing a signal that relates to a child zonewith NS recordsns1.example.net andns2.example.org, the childDNS operator needs to ensure that the parental agent has a valid DNSSECchain of trust for the zone(s) that are authoritative for the signalingdomains_signal.ns1.example.net and_signal.ns2.example.org.¶

3.2.Signaling Names

To publish information about the child zone in anauthenticated fashion, the child DNS operatorMUST publish one ormore signaling records at a signaling name under each signaling domain.¶

Signaling recordsMUST be accompanied by RRSIG records created withthe corresponding signaling zone's key(s).The type and contents of these signaling records depend on the type ofsignal.¶

The signaling name identifies the child and the signaling type.It is identical to the child name (with the final root label removed),prefixed with a label containing the signaling type.¶

4.1.Signaling Consent to Act as the Child's Signer

To confirm its willingness to act as the child's delegated signer andauthenticate the child's CDS/CDNSKEY RRsets, the child DNS operatorMUST copublish them at the corresponding signaling name under eachsignaling domain, excluding those that would fall within the childdomain (Section 3.2).For simplicity, the child DNS operatorMAY also copublish the child'sCDS/CDNSKEY RRsets under signaling domains within the child domain,although those signaling domains are not used for validation(Section 4.2).¶

Unlike the CDS/CDNSKEY RRsets at the child's apex, a signalingRRsetMUST be signed with the corresponding signaling zone'skey(s). Its contentsMUST be identical to the correspondingRRset published at the child's apex.¶

Existing use of CDS/CDNSKEY records was specified at the child apexonly (Section 4.1 of [RFC7344]). This protocol extends the use ofthese record types to non-apex owner names for the purpose of DNSSECbootstrapping. To exclude the possibility of semantic collision,thereMUST NOT be a zone cut at a signaling name.¶

_dsboot.example.co.uk._signal.ns1.example.net_dsboot.example.co.uk._signal.ns2.example.org

4.2.Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping

To validate a child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, theparental agent, knowing both the child zone name and its NShostnames,MUST execute the following steps:¶

Step 1:

verify that the child has no DS records published at the parent andthat at least one of its nameservers is outside the child domain;¶

Step 2:

query the CDS/CDNSKEY RRset at the child zone apex directly fromeach of the authoritative servers as determined by the delegation's(parent-side) NS RRset, without caching;¶

Step 3:

query the CDS/CDNSKEY RRset located at the signaling name undereach signaling domain (except those falling within the child domain)using a trusted DNS resolver and enforce DNSSEC validation;¶

Step 4:

check (separately by record type) that all RRsets retrievedin Steps 2 and 3 have equal contents;¶

If the above steps succeed without error, the CDS/CDNSKEY RRsets aresuccessfully verified, and the parental agent can proceed with thepublication of the DS RRset under the precautions described inSection 5 of [RFC8078].¶

The parental agentMUST abort the procedure if an errorcondition occurs, in particular:¶

• inStep 1: the child is already securely delegated or has in-domainnameservers only;¶

• inStep 2: any failure during the retrieval of the CDS/CDNSKEYRRset located at the child apex from any of the authoritativenameservers;¶

• inStep 3: any failure to retrieve the CDS/CDNSKEY RRsets locatedat the signaling name under any signaling domain, including failureof DNSSEC validation, or unauthenticated data (AD bit not set);¶

• inStep 4: inconsistent responses (for at least one of the types),including an RRset that is empty in one of Steps2 or3, butnon-empty in the other.¶

4.3.Triggers

Parental agentsSHOULD trigger the procedure described inSection 4.2once one of the following conditions is fulfilled:¶

• The parental agent receives a new or updated NS RRset for achild;¶

• The parental agent receives a notification indicating that the childwishes to have its CDS/CDNSKEY RRset processed;¶

• The parental agent encounters a signaling record during a proactive,opportunistic scan (e.g., daily queries of signaling records forsome or all of its delegations);¶

• The parental agent encounters a signaling record during an NSEC walkor when parsing a signaling zone (e.g., when made available via AXFRby the child DNS operator);¶

• Any other condition deemed appropriate by local policy.¶

Timer-based trigger mechanisms (such as scans) exhibit undesirableproperties with respect to processing delay and scaling; on-demandtriggers (like notifications) are preferable. Whenever possible, childDNS operators and parental agents are thus encouraged to use them,reducing both delays and the amount of scanning traffic.¶

Most types of discovery (such as daily scans of delegations) are baseddirectly on the delegation's NS RRset.In this case, these NS names can be used as is by the bootstrappingalgorithm (Section 4.2) for querying signaling records.¶

Some discovery methods, however, do not imply reliable knowledge of thedelegation's NS RRset.For example, when discovering signaling names by performing an NSECwalk or zone transfer of a signaling zone, the parental agentMUST NOTassume that a nameserver under whose signaling domain a signalingrecord appears is actually authoritative for the corresponding child.¶

Instead, whenever a list of "bootstrappable domains" is obtained by means otherthan directly from the parent, the parentalagentMUST ascertain that the delegation actually contains thenameserver hostname seen during discovery, and ensure that signaling-record queries are only made against the proper set of nameservers aslisted in the child's delegation from the parent.¶

4.4.Limitations

As a consequence ofStep 3 inSection 4.2, DS bootstrapping does notwork for fully in-domain delegations, as no preexisting chain oftrust to the child domain is available during bootstrapping.(As a workaround, one can add an out-of-domain nameserver to theinitial NS RRset and remove it once bootstrapping is completed.Automation for this is available via CSYNC records, see[RFC7477].)¶

Fully qualified signaling names must by valid DNS names.Label count and length requirements for DNS names (Section 3.1 of [RFC1035]) imply that the protocol does not work for unusually long childdomain names or NS hostnames.¶

5.1.Child DNS Operator

It is possible to add CDS/CDNSKEY records and corresponding signalingrecords to a zone without the domain owner's explicit knowledge.To spare domain owners from being caught off guard by the ensuing DSchanges, child DNS operators following this practice are advised to makethat transparent, such as by informing the domain owner during zonecreation (e.g., in a GUI) or by notifying them via email.¶

When transferring a zone to another DNS operator, the old and new childDNS operators need to cooperate to achieve a smooth transition, e.g.,by using the multi-signer protocols described in[RFC8901].If all else fails, the domain owner might have to request the removal ofall DS records and have the transfer performed insecurely (see[INSEC]).¶

Signaling domainsSHOULD be delegated as standalone zones, sothat the signaling zone's apex coincides with the signaling domain (suchas_signal.ns1.example.net).While it is permissible for the signaling domain to be containedin a signaling zone of fewer labels (such asexample.net), azone cut ensures that bootstrapping activities do not requiremodifications of the zone containing the nameserver hostname.¶

Once a child DNS operator determines that specific signaling record setshave been processed (e.g., by seeing the result in the parent zone),they are advised to remove them.This will reduce the size of the signaling zone and facilitate moreefficient bulk processing (such as via zone transfers).¶

5.2.Parental Agent

In order to ensure timely DNSSEC bootstrapping of insecure domains,stalemate situations due to mismatch of stale cached records (Step 4 ofSection 4.2) need to be avoided. It is thusRECOMMENDED 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.¶

It is alsoRECOMMENDED that QNAME minimization[RFC9156] be used whenresolving queries for signaling records to guard against certainattacks (seeSection 6).¶