| Internet-Draft | DNS-DD-EXT | July 2024 |
| Arends | Expires 9 January 2025 | [Page] |
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.¶
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 9 January 2025.¶
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.¶
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.¶
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.¶
DNS Terminology used in this document is from BCP 219 [RFC8499], with these additions:¶
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.¶
This document reserves the RRtype range xxxx to yyyy for new parent-side RR types.¶
This document allocate flag X in the DNSKEY flags.¶