Updates to the The Delegation Server (DS) Record

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

Copyright Notice

Copyright (c) 2024 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

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.¶

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.¶

8. Yang Model Update

update RFC 9108 for yang. TODO¶

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