deleg R. Arends Internet-Draft ICANN Intended status: Standards Track 8 July 2024 Expires: 9 January 2025 DNS Delegation Extensions draft-arends-parent-only-record-signalling-00 Abstract 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. 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/. Arends Expires 9 January 2025 [Page 1] Internet-Draft DNS-DD-EXT July 2024 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Authoritative Server Considerations . . . . . . . . . . . 4 4.3. Validating Resolver Considerations . . . . . . . . . . . 4 4.4. Stub Resolver Considerations . . . . . . . . . . . . . . 4 4.5. Zone Validator Considerations . . . . . . . . . . . . . . 4 4.6. Domain Registry Considerations . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Operational Considerations . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 9.2. Informative References . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. 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. Arends Expires 9 January 2025 [Page 2] Internet-Draft DNS-DD-EXT July 2024 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. 2. 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. 3. 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. Arends Expires 9 January 2025 [Page 3] Internet-Draft DNS-DD-EXT July 2024 4. Overview 4.1. Example 4.2. Authoritative Server Considerations 4.3. Validating Resolver Considerations 4.4. Stub Resolver Considerations 4.5. Zone Validator Considerations 4.6. Domain Registry Considerations 5. 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. 6. Operational Considerations 7. Security Considerations 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, January 2019, . Author's Address Arends Expires 9 January 2025 [Page 4] Internet-Draft DNS-DD-EXT July 2024 Roy Arends ICANN Email: roy.arends@icann.org Arends Expires 9 January 2025 [Page 5]