Internet-Draft parental-rrtype May 2024
Wouters Expires 23 November 2024 [Page]
Intended Status:
Standards Track
P. Wouters

Updates to the The Delegation Server (DS) Record


This document updates the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms IANA Registry to carry two new non-digest algorithm entries.

The first new type value creates a generic method to embed a Parental RRtype within the DS record. The second new type value creates an Alias DS record to point to the actual DS record published in a different DNSSEC signed zone under DNS Provider change control.

The DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms Registry is renamed to the DNSSEC Delegation Signal Registry.

This document updates [many things which we should figure out].

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

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 23 November 2024.

Table of Contents

1. Introduction

The Delegation Signer (DS) Resource Record Type (RRtype) [RFC4034] has the unique property that the record is stored at the parental side of the delegation instead of at the child side. It is currently the only record with this property. As this property was a significant modification of the existing DNS protocol, it took many years for DNS software and DNS deployment to reliably serve and resolve this RRtype.

A number of proposals have surfaced that want to create similarly behaving Parental RRtypes. This is faciliated by [PARENTAL-RRTYPE]. Like the then-new DS RRtype, it is expected to take many years before Parental RRtypes are supported on the global internet. To facilitate new Parental RRtypes in the immediate future, the only possible interim solution is to use the DS RRtype through special Digest Algorithms values.

Furthermore, DS records are difficult to update for DNS Providers, as only Registrants or Registrars can update these records via the EPP protocol [RFC5730]. While a mechanism for updating DS records by the DNS Provider via CDS records [RFC8078] was created 7 years ago, hardly any TLD support consuming CDS records at this time. An update mechanism under change control of the DNS Provider that not depends on Registry support is needed.

This document adds two special Digest Algorithms. One value is used to embed a Parental RRtype. The second value is used to specify a DS-redirection record that can be pointed to a signed zone under change control by the DNS Provider.

1.1. Requirements Language

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.

1.2. DNS Terminology

This document uses DNS Terminology as described in BCP 219 [RFC8499].

2. Traditional DS RRtype

The traditional DS RRtype Wire Format is defined as follows in [RFC4034] Section 5:

                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |           Key Tag             |  Algorithm    |  Digest Type  |
   /                                                               /
   /                            Digest                             /
   /                                                               /

The Digest length depends on the Digest Type.

3. Parental RRtype inside DS

If the Algorithm field contains the value 253, the DS record MUST be interpreted as an embedded Parental RRtype using the following Wire Format:

                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |      Parental RRtype          | Algorithm=253 |  Reserved     |
   |                           TTL                                 |
   ~                           RRdata                              ~

The CLASS of the embedded RRtype is identical to the CLASS of the DS record that contains it. It is not expected to be anything other than IN.

To avoid ambiguity of RRtypes embedded in the DS RRtype, only RRtypes with the Parental RRtype flag are accepted as embedded RRtype, with the exception of the DS RRtype itself which is disallowed. For example, the currently proposed DELEG RRType [I-D.dnsop-deleg] could be embedded in this DS record.

4. DS redirection

If the Algorithm field contains the value 254, the DS record MUST be interpreted as DS-redirection record using the following Wire Format:

                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |      Reserved (SHOULD be 0)   | Algorithm=254 |  Reserved     |
   ~                           FQDN                                ~

The FQDN MUST NOT use compression.

If the target FQDN does not resolve with Authenticated Data for QTYPE=DS, the resolver should consider its DNSSEC state to have reached the Indeterminate state as defined in [RFC4034] Section 5.

What to say if the DS target itself is an DS-redirection?

5. Operational Considerations

It is expected to still take some time before these two DS type records are widely interpreted to the meaning defined in this document. Until then, classic DS records MUST be used to ensure the domain is properly secured with DNSSEC. However, the two DS type records defined in this document can be deployed by authoritative servers without risk of negatively affecting the DNSSEC status of the domain, as unknown Digest Algorithms are treated the same as if the DS record did not exist.

6. Security Considerations

What to say here?

7. IANA considerations

This document renames the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms Registry to the DNSSEC Delegation Signal (DS) Resource Record (RR) Types Registry.

This document is added to the Reference section.

7.1. DS Type Table

A column "Digest Algorithm" is added to the table after the Description column.

The column "Status" is renamed to "Algorithm Status".

The "Digest Algorithm" colum is populated with "Yes" for all existing assigned values, except 0

The Unassigned entry is updated from "6-255" to "6-252", and a new row for value 255 is marked Unassigned

Two new entries are added to the table:

Table 1
Value Description Algorithm Algorithm Status Reference
253 Parental RRtype - - [this RFC]
254 DS Redirection - - [this RFC]

8. Yang Model Update

update RFC 9108 for yang. TODO

9. References

9.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

9.2. Informative References

April, T., Špaček, P., Weber, R., and Lawrence, "Extensible Delegation for DNS", Work in Progress, Internet-Draft, draft-dnsop-deleg-00, , <>.
Wouters, P. and V. Dukhovni, "Parental Reource Record Types in DNS", .
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, , <>.
Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, , <>.
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, , <>.

Appendix A. Acknowledgments

The idea of using the DS record for other purposes has been suggested by various people in the past

Author's Address

Paul Wouters