]> ICANN

roy.arends@icann.org

deleg Internet-Draft 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.

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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology DNS Terminology used in this document is from BCP 219 , 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.

Overview

Example

Authoritative Server Considerations

Validating Resolver Considerations

Stub Resolver Considerations

Zone Validator Considerations

Domain Registry Considerations

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.

Operational Considerations

Security Considerations

Acknowledgements

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308.