Parent-side authoritative DNS records for enhanced delegation
draft-peetterr-dnsop-parent-side-auth-types-01

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,
              <https://www.rfc-editor.org/info/rfc2119>.

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,
              <https://www.rfc-editor.org/info/rfc4034>.

   [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,
              <https://www.rfc-editor.org/info/rfc4035>.

   [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,
              <https://www.rfc-editor.org/info/rfc5155>.

   [RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
              Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
              DOI 10.17487/RFC6840, February 2013,
              <https://www.rfc-editor.org/info/rfc6840>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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]