Internet-Draft DNS-DD-EXT July 2024
Arends Expires 9 January 2025 [Page]
Intended Status:
Standards Track
R. Arends

DNS Delegation Extensions


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

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.

Table of Contents

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.

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.

4. Overview

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

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

9.2. Informative References

Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, , <>.

Author's Address

Roy Arends