dnsop P. van Dijk Internet-Draft PowerDNS Updates: 1035, 4035, 5155, 6840 (if approved) P. Spacek Intended status: Standards Track ISC Expires: 13 June 2025 10 December 2024 Parent-side authoritative DNS records for enhanced delegation draft-peetterr-dnsop-parent-side-auth-types-01 Abstract DNS RR types with numbers in the range 0xFA00-0xFDFF are now included in special treatment like DS RR type specified in [RFC4035]. Authoritative servers, DNSSEC signers, and recursive resolvers need to extend the conditions for DS special handling to also include this range. This means: being authoritative on the parent side of a delegation; being signed by the parent; being provided along with delegations by the parent. DNSSEC validators also need to implement downgrade protection described in Section 5.3. 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 13 June 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 van Dijk & Spacek Expires 13 June 2025 [Page 1] Internet-Draft parent-side-auth-types December 2024 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. Document work . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Authoritative servers, Signing software, and Recursive resolvers . . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Validating resolver changes . . . . . . . . . . . . . . . 5 5.2.1. Preventing downgrade attacks . . . . . . . . . . . . 5 5.3. Zone validator changes . . . . . . . . . . . . . . . . . 6 5.4. Stub resolver changes . . . . . . . . . . . . . . . . . . 6 5.5. Domain registry changes . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Document history . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [RFC4035] defines the DS Resource Record, as a type with the special property that it lives at the parent side of a delegation, unlike any other record (if we can briefly ignore NSEC living on both sides of a delegation as an extra special case). In various conversations and posted drafts over the last five years in DPRIVE, DNSOP, and DELEG, a potential desire to publish other kinds of data parent-side has been identified. Some drafts simply proposed a new type, assuming that authoritative DNS servers and registry operations would eventually follow along; other drafts have tried to shoehorn new kinds of data into the DS record. If, when DS was defined, or at any time since then, a range of RRtype numbers would have been specified to have the same behaviour as DS, those drafts, and the experiments that need to go with figuring out the exact definition of a protocol, would have been much more feasible. This document requests that IANA reserve such a range and defines behavior of DNS implementations. van Dijk & Spacek Expires 13 June 2025 [Page 2] Internet-Draft parent-side-auth-types December 2024 2. Document work This document lives on GitHub (https://github.com/PowerDNS/draft- dnsop-parent-side-auth-types); proposed text and editorial changes are very much welcomed there, but any functional changes should always first be discussed on the IETF DNSOP WG mailing list. 3. Conventions and Definitions The term "Parent-Side Types" refers to set of RR types which contains exactly: * Value 43 as defined for DS type by Section 5 of [RFC4034], * The whole range reserved by this document in Section 8. 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. 4. Summary A RR type range reservation in [#iana] is now open for allocation of future Parent-Side Types, but none such types are allocated by this document. Special processing for DS record type related to its inclusion in DNS messages, zone files, DNSSEC signing, etc. is extended to all Parent- Side Types. The only exception are rules which pertain to content of DS resource records, which are not applicable to other Parent-Side Types. In short, authoritative servers serve the types from the parent side of a delegation and resolvers know to ask the parent side of a delegation. Having these type numbers reserved with defined processing rules allows for future extension of parent-side publication of data, without having to wait for implementations to catch up. 5. Implementation 'Implementation' is understood to mean both 'code changes' and 'operational changes' here. van Dijk & Spacek Expires 13 June 2025 [Page 3] Internet-Draft parent-side-auth-types December 2024 This specification extends special handling previously defined exclusively to DS RR type to apply to all Parent-Side Types. In short, implementations need to modify their hardcoded condition (if RRTYPE equals DS) to (if RRTYPE is Parent-Side Type) as defined in Section 3. 5.1. Authoritative servers, Signing software, and Recursive resolvers Updates to existing specifications: * Section 2.4 of [RFC4035] - All Parent-Side Types in a zone MUST be signed, and MUST NOT appear at a zone's apex. - Unless specified otherwise by a future specification, only DS RR type defined in Section 5 of [RFC4034] establish authentication chains between DNS zones. - TTL of Parent-Side Types is NOT tied to NS TTL. * Section 2.6 of [RFC4035]: All Parent-Side Types are allowed at the parent side of a zone cut, and NSEC RR type continues to be allowed as well. * Section 3.1.4 of [RFC4035]: Fully applicable. When responding to a query that has the DO bit set, all Parent-Side Types or a relevant proof-of-nonexistence MUST be returned. In practice it is extremely unlikely that all Parent-Side Types would be present and thus the proof-of-nonexistence will be always present. * Section 3.1.4.1 of [RFC4035]: Special rules applicable. When responding to a query that has the DO bit set, all Parent-Side Types or a relevant proof-of-nonexistence MUST be returned. In practice it is extremely unlikely that all Parent-Side Types would be present and thus the proof-of-nonexistence will be always present. * Section 7.2 of [RFC5155]: References to DS RR type are replaced by All Parent-Side Types. * [RFC5155]: Opt-out feature of NSEC3 applies only if no Parent-Side Type is present at the delegation point. FIXME How to deal with these places which were not updated by the RFC4033-4035? Close eyes and pretend we also forgot? * rfc2181#section-6.2 van Dijk & Spacek Expires 13 June 2025 [Page 4] Internet-Draft parent-side-auth-types December 2024 * rfc2181#section-6.1 * rfc2181#section-5.4.1 * rfc1034#section-4.3.2 / rfc6672#section-3.2 5.2. Validating resolver changes * Section 6 of [RFC5155] - Security status of the child zone is determined by the presence or absence of DS RRSet, which is not changed by this document. - All Parent-Side Types require proof-of-nonexistence and thus NSEC3 Opt-out feature applies only if no Parent-Side Type is present at the delegation point. * Section 8 of [RFC5155]: References to DS RR type are replaced by All Parent-Side Types. * Section 4.1 of [RFC6840]: Reference to DS RR type is replaced by all Parent-Side Types. * Section 4.4 of [RFC6840]: - While proving existence of any Parent-Side Type needs MUST follow rules for NSEC bitmap checks from this section to detect spoofed proofs from the child zone. - Only DS RR type is used for determining presence of a secure delegation. This specification defines changes to query processing in resolvers. FIXME DNSKEY flag for downgrade resistance 5.2.1. Preventing downgrade attacks A flag in the DNSKEY record signing the delegation is used as a backwards compatible, secure signal to indicate to a resolver that Parent Side Types (other than DS) MAY be present or that there is an authenticated denial of parent side types. Legacy resolvers will ignore this flag and use the DNSKEY as is. Without this secure signal an on-path adversary can remove Parent Side records and their RRSIGs from a response and effectively downgrade this to a legacy DNSSEC signed response. van Dijk & Spacek Expires 13 June 2025 [Page 5] Internet-Draft parent-side-auth-types December 2024 5.3. Zone validator changes This specification defines changes to zone validation in zone validators. RR types from the new parent-side range in Section 8 must conform to the same signing rules as DS RR type. See [RFC4035] 5.4. Stub resolver changes This specification defines no changes to query processing in stub resolvers. FIXME 5.5. Domain registry changes Domain registries MAY decide to allow children to publish records of any type from the range defined in this document in the parent zone. Alternatively, they MAY decide to only allow such publication for types that actually get allocated a name and a semantic. Ideally, domain registries would allow anything in the experimental subrange. 6. Security Considerations TODO: definitely need words about the downgrade protection here. 7. Implementation Status [RFC Editor: please remove this section before publication] 8. IANA Considerations IANA is requested to change reservations in the DNS Parameters RR TYPEs registry, with this document as the Reference. * Range 0xFA00-0xFDFF to Registration Procedure "Expert Review or Standards Action" * Range 0xFE00-0xFEFF to Registration Procedure "Private Use" IANA is further requested to assign bit TBD (suggested value: 9) to "Must sign parent types (MSPT)" in the DNSKEY RR Flags registry, with this document as the Reference. van Dijk & Spacek Expires 13 June 2025 [Page 6] Internet-Draft parent-side-auth-types December 2024 9. Acknowledgements This idea was initially proposed by Petr Spacek. His contribution is rewarded by listing him as an author so he can take equal parts credit and blame. 10. References 10.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, . 10.2. Informative References [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Document history * 01 - Specific range of type numbers (subset of former "Reserved for future use") was added to IANA considerations. - Some words on downgrade protection were added. van Dijk & Spacek Expires 13 June 2025 [Page 7] Internet-Draft parent-side-auth-types December 2024 Authors' Addresses Peter van Dijk PowerDNS Den Haag Netherlands Email: peter.van.dijk@powerdns.com Petr Spacek ISC Brno Czech Republic Email: pspacek@isc.org van Dijk & Spacek Expires 13 June 2025 [Page 8]