DNS Delegation Extensions
Roy Arends
ICANN
roy.arends@icann.org
08 July 2024
deleg
Internet-Draft
New RR types have been proposed that appear only at the parent side of a delegation, similar to the DS resource record (RR) type.
Supporting parent side RR types requires modifications to the DNS Security Extensions (DNSSEC).
Without these modifications, validating resolvers are susceptible to response modification attacks. An on-path adversary could potentially remove the parent-side resource records without being detected.
To detect the removal of a parent-side RR type, an authenticated denial record (such as NSEC or NSEC3) is necessary to confirm presence or absence of a parent-side RR type.
Currently, validating resolver do not expect authenticated denial records in a secure delegation response. Therefore, a secure signal is needed to inform the validating resolver to anticipate authenticated denial records for a delegation.
To support the future deployment of parent-side RR types, this draft designates a range of yet unallocated RR types specifically for parent-side use. Authoritative servers will include these records in a delegation response without requiring upgrades.
Introduction
The DNS Security extensions introduced the Delegation Signer (DS) record. This was a new concept as it was a record type that can only appear at the parent-side of a delegation.
In the future, additional parent-side RR types may be proposed that will need to be protected against deletion.
This document provides future parent-side RRtypes the same protection as DS records already have. This protection is the same for all future parent-side RRtypes, and thus avoids the need for each new future RRtype needs its own signalling. This protection is provided by "authenticated denial records", which currently are NSEC and NSEC3 records.
Authenticated denial records are currently used to prove the presence or absence of DS records. New parent-side RRtypes will need similar protection, and this document proposes to provide the protection using the same mechanism: NSEC and NSEC3 records.
Currently, validating resolvers do not expect an authenticated denial record when a DS is present. Validating resolvers that support parent-side RR types require a secure signal that an authenticated denial record is present in a response, since it can not determine if this response has these records removed by an adversary, or if the response originated from a server that does not support new parent-side records.
To avoid a downgrade attack, secure zones that contain parent-side RR types MUST include a secure signal. This signal is a DNSKEY record with a flag that indicates the secure signal.
To avoid a secure signal for every new parent-side RR type, this document designates a range for parent-side only RR types.
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.
Terminology
DNS Terminology used in this document is from BCP 219 [RFC8499], with these additions:
Parent-side RR type:
DNS RR types that can appear at the parent side of a delegation. These records MUST be signed by the parent. These records MUST NOT exist at the apex of the delegated zone.
Overview
Example
Authoritative Server Considerations
Validating Resolver Considerations
Stub Resolver Considerations
Zone Validator Considerations
Domain Registry Considerations
IANA Considerations
This document reserves the RRtype range xxxx to yyyy for new parent-side RR types.
This document allocate flag X in the DNSKEY flags.
Operational Considerations
Security Considerations
Acknowledgements

Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174

Informative References
[RFC8499]

DNS Terminology
P. Hoffman
A. Sullivan
K. Fujiwara
January 2019
RFC 8499
DOI 10.17487/RFC8499