]> Internet Systems Consortium, Inc.

PO Box 360 Newmarket NH 03857 USA +1 650 423 1300 ray@isc.org

Internet DNSSD DNS resource record This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the DNSSD Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction A commonly requested DNS feature is the ability to receive multiple related resource records (RRs) in a single DNS response. For example, it may be desirable to receive the A, AAAA and HTTPS records for a domain name together, rather than having to issue multiple queries. The DNS wire protocol in theory supported having multiple questions in a single packet, but in practise this does not work. In , is updated to only permit a single question in a QUERY (OpCode == 0) request. Sending QTYPE=ANY does not guarantee that all RRsets will be returned. specifies that responders may return a single RRset of their choosing. This document provides a solution for those cases where only the QTYPE varies by specifying a new option for the Extension Mechanisms for DNS (EDNS ) that contains an additional list of QTYPE values that the client wishes to receive in addition to the single QTYPE appearing in the question section. A different EDNS option is used in response packets as protection against DNS middleboxes that echo EDNS options verbatim. The specification described herein is applicable both for queries from a stub resolver to recursive servers, and from recursive resolvers to authoritative servers.

Terminology used in this document 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.

Description

Multiple QTYPE EDNS Options Format The overall format of an EDNS option is shown for reference below, per , followed by the option specific data: OPTION-CODE: MQTYPE-Query (TBD1) in queries and MQTYPE-Response (TBD2) in responses. OPTION-LENGTH: Size (in octets) of OPTION-DATA. OPTION-DATA: Option specific, as below: QT: a (potentially empty) list of 2 byte fields (QTx) in network order (MSB first) each specifying a DNS RR type. The RR types MUST be for real resource records, and MUST NOT refer to pseudo RR types such as "OPT", "IXFR", "TSIG", "*", etc.

Server Response Generation A conforming server that receives an MQTYPE-Query option in a query MUST return an MQTYPE-Response option in its response. A server that receives an MQTYPE-Response option in a query MUST return a FORMERR response. On receipt of a valid MQTYPE-Query option the server SHOULD attempt to return any resource records known to it that match the additional (QNAME, QTx, QCLASS) tuples. These records MUST be returned in the Answer Section of the response, but the answer for the primary QTYPE from the Question Section MUST be included first. If any invalid QTx is received in the query (e.g. one corresponding to a meta-RR) the server MUST return a FORMERR response. For any particular QTx in the query, if the server provides additional answers, or has knowledge that the RR type does not exist for that QNAME (a "negative answer"), it MUST include that QTx value in the list of QTYPEs in its MQTYPE-Response option. If the server does not provide an answer (whether positive or negative) for that QTx then that value MUST be omitted from the list of QTYPEs in it MQTYPE-Response option. A negative answer is therefore indicated by the combination of the presence of a QTx value in the Multiple QTYPE Option and the absence of a matching record in the Answer Section. This is necessary (in the absence of DNSSEC) to differentiate between absence of the record from the zone and absence of the record from the response. A server that is authoritative for the specified QNAME on receipt of a Multiple QTYPE Option MUST attempt to return all specified RR types except where that would result in truncation or a risk of a significant DNS amplification attack in which case it MAY omit some (or all) of the records for the additional RR types. A caching recursive server receiving a Multiple QTYPE Option query SHOULD attempt to fill its positive and negative caches with all of the specified RR types before returning its response to the client. It MAY limit itself to a smaller subset of the specified RR types if the processing overhead to fill its caches is too great or if there is a risk of a significant DNS amplification attack. While this document specifies no limit on the number of QTx values that may be specified, the author anticipates that server implementations will provide configuration settings to constrain the response sizes.

DNSSEC If the DNS client sets the "DNSSEC OK" (DO) bit in the query then the server MUST also return the related DNSSEC records that would have been returned in a standalone query for the same QTYPE. A negative answer from a signed zone MUST contain the appropriate authenticated denial of existence records, per and . In a signed zone there is a theoretical risk of valid signatures for one RR type and invalid signatures for another. This is the only case known to the author where the response code for any particular QNAME may be inconsistent across different RR types. Should a validating resolver produce NOERROR for some RR types and SERVFAIL for others it MUST omit the RR types that failed to validate from its response and from the QTx fields on the Multiple QTYPE option.

Client Response Processing Recursive resolvers MAY use this method to obtain multiple records from an authoritative server. For the purposes of Section 5.4.1 of any authoritative answers received MUST be ranked the same as the answer for the primary question. If the response to a query containing an MQTYPE-Query option does not contain an MQTYPE-Response option, or if it erroneously contains an MQTYPE-Query option, the client MUST treat the response as if this option is unsupported by the server and SHOULD process the response as if the MQTYPE-Query option had not been used. The client SHOULD subsequently initiate standalone queries (i.e. without using the MQTYPE-Query option) for any QTx value that did not generate a negative answer.

Security Considerations The method documented here does not change any of the security properties of the DNS protocol itself. It should however be noted that this method does increase the potential amplification factor when the DNS protocol is used as a vector for a denial of service attack.

IANA Considerations NB: to be rewritten once assignments have been made. IANA is requested to assign two new values (TBD1 and TBD2) in the DNS EDNS0 Option Codes registry for MQTYPE-Query and MQTYPE-Response. They should be consecutive, with the -Query option being an even number.

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Internet Systems Consortium, Inc. Cloudflare This document updates RFC 1035 by constraining the allowed value of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum of one, and specifies the required behaviour when values that are not allowed are encountered. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. 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. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] Informative References The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons. The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance. This document updates RFCs 1034 and 1035.

Acknowledgements The author wishes to thank the following for their feedback and reviews during the initial development of this document: Michael Graff, Olafur Gudmundsson, Matthijs Mekking, and Paul Vixie. In addition the author wishes to thank the following for subsequent review during discussion in the DNSSD Working Group: Chris Box, Stuart Cheshire, Esko Dijk, Ted Lemon, and David Schinazi.