Parent-side authoritative DNS records for enhanced delegation

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 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

[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.¶

2. Document work

This document lives on GitHub; 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.¶

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.¶

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.¶

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.¶

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.¶

Authors' Addresses