DNS Protocol Modifications for Delegation Extensions

Introduction defines the Delegation Signer (DS) resource record as having a unique property: it resides 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 present at delegation points. This document reserves a range of Resource Record (RR) types allowed at delegation points and describes the protocol modifications for DNS implementations that support them. To shield implementations that do not implement these modifications, a new EDNS(0) option is introduced to indicate support for this range of RR types. To protect against downgrade attacks, a new DNSKEY flag is introduced.

Conventions and Definitions The term Delegation Types designates the set of RR types consisting of the range of RR types reserved in of this document.

Delegation-Extension-aware name server or resolver: A server that implements this specification.

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.

Relationship with the DELEG draft The DELEG draft specifies a new resource record type (DELEG) that is authoritative at a delegation point and proposes protocol modifications to support DELEG. The purpose of this document is to make sure that protocol modifications are generic for a range of types.

Relationship with NS and DS records The use of DS and delegation-point NS records is orthogonal to the use of Delegation Types. Both types MAY coexist with Delegation Types.

Services Provided by Delegation Types Services provided by Delegation Types consist of information useful to a resolver when connecting to servers responsible for the delegated namespace. This can include, but is not limited to, secure transport parameters, policy information about zones, and DNSSEC security parameters.

Delegation Types contains three subcategories of RR type numbers: Data Types, Q-Types, and Meta-Types. This specification adds a fourth subcategory: Delegation Types. Considerations for the allocation of Delegation Types are as follows:

Updates to allocation policy This section is to be written with guidance from the RFC6895 Experts Pool.

Resolver Requirements To indicate Delegation Types support, the resolver sets the Delegation Extensions (DE) flag in the EDNS(0) Flags field when sending a DNS request message.

The EDNS(0) DE Flag The DE flag is carried in the OPT RR TTL field.

Referrals Delegation Types in the authority section of a DNS response message indicate that the response contains a referral. Delegation Types are expected to contain all the information needed for a resolver to act on. Therefore, NS records that appear in addition to Delegation Types MUST be ignored. These NS records MUST NOT be validated or cached. The purpose of this restriction is to avoid leakage of DNS messages over unencrypted transport when servers, indicated by Delegation Types, fail to respond. When no Delegation Types exist, the resolver MAY use NS records. Note that the use of DNSSEC can prove the presence and absence of Delegation Types for a delegation.

Name Server Requirements Delegation-Extension-aware name servers MUST copy the value of the EDNS(0) DE flag from the request to the response.

Including Delegation Types in a Referral Response When the DE flag is set, the server includes Delegation Types in referrals and ignores NS types. When there are no Delegation Types for a referral, it includes NS types. The proof of existence of types for the delegated name MUST be included. When the DE flag is clear, and no NS records exist for a referral, there is no facility for the resolver to continue resolving the delegated namespace. A name error SHOULD be returned in this case. While this may seem counterintuitive, since the name does exist, it is the only response code that stops the resolver from asking other authoritative name servers for the same information. Authoritative servers SHOULD include an Extended DNS Error to clarify the reason.

Explicit queries for Delegation Types When the DE flag is set, a query for a Delegation Type SHOULD result in an authoritative answer if the Delegation Type exists, or a NODATA response (AA flag set, RCODE=0, empty answer section). When the DE flag is clear, a query for a Delegation Type SHOULD result in an authoritative answer if the Delegation Type exists; in a referral with NS types if NS types exist, or in a NODATA response if other Delegation Types exist.

DNSSEC Requirements In a DNSSEC-signed zone, Delegation Type RRsets MUST be signed. To avoid a downgrade attack, where the Delegation Types and NSEC (or NSEC3) records can be replaced by unsigned NS records, causing the resolver to use unencrypted transport, a secure signal in the form of a DNSKEY flag is introduced. This secure signal indicates that NSEC or NSEC3 records MUST be present in a referral response.

The DNSKEY-ADT flag The DNSKEY Flags field consists of 16 bits: Bit 14 is the Authoritative Delegation Types (ADT) flag. It indicates to a validator that a referral MUST contain an NSEC or NSEC3 record to prove presence or absence of types for the delegated name.

Validating a Referral When the DNSKEY-ADT flag is set in any DNSKEY from the DNSKEY RRset of the delegating zone, the validator MUST check the Delegation Types in the authority section of the referral against the Type Bit Maps of the NSEC or NSEC3 record that matches the delegated name. If any are absent, the referral MUST be considered tampered with, and the response MUST be ignored.

Security Considerations This section discusses security considerations, including downgrade attacks and resolver behavior. Further details will be added.

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

Range 0xF000-0xF1EF to Registration Procedure "Expert Review or Standards Action"
Range 0xF1F0-0xF1FF to Registration Procedure "Private Use"

Acknowledgments This idea was initially proposed by Petr Špaček, and independently by Paul Wouters.