Aiven

paul.wouters@aiven.io

Operations dnsop dnssec ds rrtypes 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].

The Delegation Signer (DS) Resource Record Type (RRtype) 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 . 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 . While a mechanism for updating DS records by the DNS Provider via CDS records 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.

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 when, and only when, they appear in all capitals, as shown here.

This document uses DNS Terminology as described in BCP 219 .

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

The Digest length depends on the Digest Type.

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

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 could be embedded in this DS record.

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

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 Section 5. What to say if the DS target itself is an DS-redirection?

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.

What to say here?

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.

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: Value Description Algorithm Algorithm Status Reference 253Parental RRtype--[this RFC] 254DS Redirection--[this RFC]

update RFC 9108 for yang. TODO

Aiven Google DNS This document updates the DNS Parameters' Resource Record (RR) TYPEs registry by adding a field denotating "Parental RRtype" that instructs DNS name servers to store or query RRtypes that have this new field set at the parent side of a delegation instead of at the child side.

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