Internet-Draft auth-delegation-types July 2025
van Dijk, et al. Expires 8 January 2026 [Page]
Workgroup:
deleg
Internet-Draft:
draft-ppr-dd-auth-delegation-types-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
P. van Dijk
PowerDNS
P. Spacek
ISC
R. Arends
ICANN

DNS Protocol Modifications for Authoritative Delegation Point DNS Records

Abstract

This document proposes modifications to the Domain Name System (DNS) protocol to support a range of authoritative resource record types at delegation points. Currently, the DNS only allows DS (Delegation Signer) records at a delegation point as authoritative data. This draft extends that model by enabling the inclusion of a range of RRtypes at delegation points. The proposed modifications preserve compatibility with existing DNS resolution behavior while providing a clear framework for identifying and processing these records as authoritative data at delegation points.

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 8 January 2026.

Table of Contents

1. Introduction

[RFC4035] defines the DS (Delegation Signer) resource record as having a unique property: it resides solely at a delegation as authoritative data. Discussions and drafts within the DPRIVE, DNSOP, and DELEG working groups have highlighted interest in allowing additional types of data to be published at delegation points. Some proposals have introduced new RRtypes with the assumption that authoritative servers and registry systems would eventually support them. Others have attempted to repurpose the DS record format for unrelated data. Had a range of RRtypes been designated early on to behave similarly to DS, these proposals and their associated protocols could have been more easily developed and evaluated. This document proposes reserving such a range of RRtype codes and defines the expected behavior of DNS implementations that support them.

This document requests that IANA reserve such a range and defines behavior of DNS implementations.

2. Conventions and Definitions

The term "Authoritative Delegation Types" refers to set of RR types which contains exactly:

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. Relationship with the DELEG draft

The DELEG draft specifies one new resource record type (DELEG) that is authoritative at a delegation point and proposes protocol modifications to support DELEG.

The sole purpose of this document is to make sure that the protocol modifications are generic for a range of types instead of just DELEG.

If the WG decides to seperate the DELEG type specification from the Protocol Modifications needed to support authoritative delegation types, we can incorporate all the necessary parts in this document.

4. Security Considerations

To be added.

5. IANA Considerations

IANA is requested to change reservations in the DNS Parameters RR TYPEs registry, with this document as the Reference.

6. Acknowledgements

This idea was initially proposed by Petr Spacek.

7. References

7.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[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, , <https://www.rfc-editor.org/info/rfc4035>.

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

Authors' Addresses

Peter van Dijk
PowerDNS
Den Haag
Netherlands
Petr Spacek
ISC
Brno
Czech Republic
Roy Arends
ICANN
St Peter Port
Guernsey