Incrementally Deployable DNSSEC Delegation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 July 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document describes a DNSSEC delegation mechanism that complements [I-D.homburg-deleg-incremental-deleg]. In particular, this mechanism makes it possible to store the contents of DS records as 'ds' parameters in SVCB-style records. This way, a single mechanism can specify both name servers and DNSSEC delegations.¶

In addition to a replacement for DS records, this document also introduces a 'dnskeyref' parameter that provides more flexibility and reduces the need to coordinate both for key rollovers and for multi-signer setups.¶

There are two main problems with the current DS record. The first is a DS record refers to a key in a DNSKEY RRset. Updating this keys (during a key rollover) requires updating the corresponding DS record. At the moment there is no widespread mechanism to update DS records automatically. However, even if such an update mechanism would become widespread, the signer also has to track to propagation of the new DS record to the secondaries of the parent zone. This is needed to make sure that all old DS records are expired in caches before moving to the next stage of a key roll.¶

The second problem is that DS records enforce the use of a single DNSKEY RRset (at the apex of the zone). This means that in a multi-signer setup, signers have to coordinate when rolling their signing keys.¶

There is one minor problem that can be solved as well. Currently every signed zone has to have a DNSKEY RRset at the apex. If a collection of zones share the same keys then this can be burden to maintain.¶

The solution to these problems is to introduce a dnskeyref parameter that contains the names of DNSKEY RRsets that are allowed to sign a zone. This extra level of indirection avoids the need to involve the parent during key rolls. Multiple DNSKEY RRsets make it possible to perform key rolls in a multi-signer setup without coordination. Finally, this allows a single DNSKEY RRset to be used for multiple domains.¶

The charter for the Deleg working group has the following:¶

The DNS protocol has limited ability for authoritative servers to signal their capabilities to recursive resolvers. In part, this stems from the lack of a mechanism for parents (often registries) to specify additional information about child delegations (often registrants) beyond NS, DS, and glue records. Further complicating matters is the similar lack of a mechanism for a registrant to signal that the operation of a delegation point is being outsourced to a different operator, leaving a challenge when operators need to update parental information that is only in the control of the child. Data is often out of synchronization between parents and children, which causes significant operational problems.¶

The main focus to date has been on making it possible to update the name servers of a delegation without involving the registrant. However, DNSSEC has a similar problem.¶

The introduction of the dnskeyref parameter make it possible to manage DNSSEC without involving the registrant.¶

One extra feature that becomes possible with the use of SVCB-style records is to let the zone manage downgrade attacks. By introducing ds or dnskeyref parameters at different priority level, the zone can signal which algorithm is preferred.¶

This document updates Section 2.1.1 of [RFC4034] in the following way: the sentence "If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and MUST NOT be used to verify RRSIGs that cover RRsets." is replaced by "If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and can be used to verify RRSIGs that cover RRsets if required."¶

This document updates Section 5.3.1 of [RFC4035] and replaces the sentence "The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset." with "The RRSIG RR's Signer's Name field MUST be the name of any DNSKEY RRset that is allowed to sign the zone."¶

2. New parameters

Two new SVCB-style parameters are introduced: ds and dnskeyref.¶

To limit validation resources and avoid accidentally delegating security, these two parameters are not valid after following an SVCB-style record in AliasMode.¶

For DELEG records, these parameters are allowed to be added to DELEG records in AliasMode. To increase flexibility, a DELEG record in ServiceMode can be created with just ds or dnskeyref parameters but without name server delegation. In that case the TargetName has to be set to ".". Unlike SVCB records, for DELEG we allow mixing of AliasMode and ServiceMode records.¶

3. Validator behavior

When following a delegation, a validator MUST first look for an Incremental delegation. If presence or absence is not DNSSEC Secure (i.e., the status is Insecure, Bogus or Indeterminate) then the child is not secure and the algorithm stops here.¶

If absence of an Incremental delegation is proven to be Secure then then validator MAY continue validating using DS records.¶

If a secure Incremental delegation is found then the validator MUST ignore any DS records and solely rely on what is found in the Incremental deleg records.¶

If the Incremental deleg records contain no ds or dnskeyref parameters or these do not lead to any key with an algorithm that the validator supports then the delegation is considered insecure.¶

A validator MUST NOT use any ds or dnskeyref parameters found after following an SVCB-style record in AliasMode. Restricting ds and dnskeyref to the top level is essential in preventing a DNS operator (who is supposed to only serve a zone, not sign it) from adding additional ds or dnskeyref parameters.¶

To support protection against downgrade attacks, a validator SHOULD consider only SVCB-style records with the highest priority that either have a ds parameter that has a least one algrithm supported by the validator or in the case of dnskeyref, a DNSKEY RRset that contains at least one key with an algorithm that is supported.¶

After selecting priority level, the validator uses any ds parameters to validate the DNSKEY RRset the apex of the child zone. The DNSKEY RRsets that dnskeyref paramters refer need to be DNSSEC Secure to be used. Any DNSKEY RRsets that are not DNSSEC Secure according to the validator MUST be ignored.¶

[Note, to be removed for publication. Should the validator check if the Zone Key flag is zero if the DNSKEY RRset is not at the apex. For now assume that it is just like the SEP flag and can be ignored.]¶

To limit validator resources, when validating a name that refers to a DNSKEY RRset, the validator should only use ds parameters (and DS records) and ignore any dnskeyref parameters. Validator SHOULD allow for a DNAME and CNAME chain of reasonable length when resolving a name to a DNSKEY RRset.¶

Now that there are multiple DNSKEY RRsets that may be used to sign an RRset, the validator uses the Signer's Name in a signature to select a DNSKEY RRset to validate the signature. If the name does not match any of the DNSKEY RRset selected in the previous step then the signature MUST be ignored.¶

4. Signer behavior

Signer MUST put ds and dnskeyref parameters only in DELEG records at an Incremental delegation and not in SVCB-style records that follow a DELEG record in AliasMode.¶

The ds parameter affects signers in one small way: the priority system of SVCB-style records can be used to provide protection again downgrades. The signer can put a ds parameter with a more secure algorithm in a DELEG record with a higher priority and expect fallback to the less secure algorithm only if the validator does not understand the more secure algorithm.¶

The dnskeyref parameter requires that the validator puts the name of the DNSKEY RRset in the Signer's Name field of the signature. This is a small but significant change to how signers operate. The DNSKEY RRset MUST be DNSSEC Secure and the validation chain MUST only involve ds parameters or DS records. In addition DNSKEY records that are not at the apex of a zone MUST have the Zone Key flag set to 0 (bit 7 of the flags field, see [RFC4034], Section 2.1.1) The dnskeyref parameter also supports downgrade protection but has a number of additinal features that can be used by signers.¶

The first is that because dnskeyref directly refers to a DNSKEY RRset there is no longer any need for Key Signing Keys (KSK). Those DNSKEY RRsets only contain Zone Signing Keys (ZSK). This means that KSK rollovers are no longer necessary. It is also no longer necessary to coordinate with the parent zone for key rollovers.¶

The second is that dnskeyref can refer to a DNSKEY RRset that is used to sign multiple zones. Zones do no need to have their own copies of key material. Instead a single DNSKEY RRset can be used for as many zones as needed.¶

Third, in a multi-signer setup, each signer can maintain its own DNSKEY RRset independent of other signers. This means that each signer can perform key rollovers without any need to coordinate with other signers.¶

5. Examples

$ORIGIN example.
@                  IN  SOA   ns zonemaster ...
customer1._deleg   IN  DELEG 1 ( ns.customer1
                ipv4hint=198.51.100.1,203.0.113.1
                ipv6hint=2001:db8:1::1,2001:db8:2::1
                ds=60485:5:1:2BB183AF5F22588179A53B0A98631FAD1A292118
                               )

$ORIGIN example.
@                  IN  SOA   ns zonemaster ...
customer2._deleg   IN  DELEG 0 ns.operator1
                   IN  DELEG 1 ( .
                    ds="60485:5:1:2BB183AF5F22588179A53B0A98631FAD1A292118
 370:13:2:BE74359954660069D5C63D200C39F5603827D7DD02B56F120EE9F3A86764247C"
                               )

$ORIGIN example.
@                  IN  SOA   ns zonemaster ...
customer3._deleg   IN  DELEG 0 ns.operator1
                   IN  DELEG 1 ( .
                    dnskeyref=customer3.keys.operator1
                               )

$ORIGIN example.
@                  IN  SOA   ns zonemaster ...
customer4._deleg   IN  DELEG 1 ( ns.operator1
                    dnskeyref=customer4.keys.operator1
                                  )
                   IN  DELEG 1 ( ns.operator2
                    dnskeyref=customer-keys.operator3
                                  )

6. Security Considerations

The ds parameter is a slight improvement over the DS record because it allows SVCB priorities to be used for downgrade protection. Otherwise, the semantics are the same. This relies on the restriction that ds (and dnskeyref) parameters can only appear the top level and not after following an SVCB-style record in AliasMode.¶

The dnskeyref parameter breaks the traditional chain semantics of DNSSEC. With the ds parameter (or the DS record) the validity of a signature depends only on a chain of cryptographic primitives. With dnskeyref, a DNS lookup is inserted. This DNS lookup is protected by a traditional DNSSEC chain, but the presence of the name means that it is no longer a cryptographic chain.¶

This trade-off between struct security and flexibility is left to the zone operator.¶

A new risk that needs to be considered is old and forgotten dnskeyref parameters. Old DS records or ds parameters are mostly safe. An attacker can only assume then if the attacker can obtain the private key that can sign for the public key that the DS record or ds parameter refers to. This is not impossible but very unlikely. And the use of hardware security modules (HSM) can make this almost impossible.¶

In contrast if a dnskeyref refers to a name in a forgotten domain and the registration of the domain is expired then an attacker may register the name and set up a DNSKEY RRset at the name listed in the dnskeyref parameter. The risk of this can be reduced by two operational practices. The first is to put the dnskeyref parameter in the same (AliasMode) DELEG record that provides the name server delegation. This will make it likely that dnskeyref parameter will be removed once the name servers no long serve the zone.¶

The second practice is that domains that allow registrations (mostly top level domains (TLD) but also others) could install a policy that a dnskeyref parameter MUST refer to a DNSSEC Secure DNSKEY RRsets. Additionally each DNSKEY RRset that is referred to by a dnskeyref parameter has to be used to sign the zone as served by at least one of the name servers that serves the zone. This makes it possible to detect forgotten or misconfigured dnskeyref paramters early on.¶

7. IANA Considerations

Per [RFC9460], IANA is requested to add the following entry to the DNS "Service Parameter Keys (SvcParamKeys)" registry:¶

8. References

Acknowledgments

Jens Finkhäuser, Havard Eidnes, Edward Lewis, Petr Špaček, Johan Stenstam¶

Authors' Addresses