]> 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 (OpCode=0). 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. It does not apply to Multicast DNS queries , which are already designed to allow requesting multiple records in a single query.

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 (20) in queries and MQTYPE-Response (21) 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 RRTYPE that must be for a data RRTYPE as described in Section 3.1 of .

Server Handling

Request Parsing If MQTYPE-Query is received in any inbound DNS message with an OpCode other than QUERY (0) the server MUST return a FORMERR response. A server that receives an MQTYPE-Response option in any inbound DNS message MUST return a FORMERR response. A server that receives more than one MQTYPE-Query option in a query MUST return a FORMERR response. If an MQTYPE-Query option is received in a query that contains no primary question (i.e. QDCOUNT=0) the server MUST return a FORMERR response. If an MQTYPE-Query option is received in a query where the primary question is a non-data RRTYPE (e.g. ANY, AXFR, etc.) the server MUST return a FORMERR response. If any invalid QTx is received in the query (e.g. one corresponding to a Meta RRTYPE) the server MUST return a FORMERR response. If any duplicate QTx (or one duplicating the primary QTYPE field) is contained in a query the server MUST return a FORMERR response.

Response Generation A conforming server that receives an MQTYPE-Query option in a query MUST return an MQTYPE-Response option in its response, even if that response is truncated (TC=1). The server MUST first start constructing a response for the primary (QNAME, QCLASS, QTYPE) tuple specified in the Question section per the existing DNS sections. The RCODE and all other flags (e.g. AA, AD, etc) MUST be determined at this time. If this initial response results in truncation (TC=1) then the additional queries specified in the MQTYPE-Query option MUST NOT be processed. After the initial response is prepared, the server MUST attempt to combine the responses for individual (QNAME, QCLASS, QTx) combinations into the response for the first query. If a recursive server does not yet have those responses available it MUST first make appropriate outbound queries to populate its caches. For each individual combination the server MUST evaluate the resulting RCODE and other flags and check that they all match the values generated from the primary query. If any mismatch is detected the mismatching additional response MUST NOT be included in the final combined response and its QTx value MUST NOT be included in the MQTYPE-Response option's list. This might happen, for example, if the primary query resulted in a NOERROR response but a QTx query resulted in a SERVFAIL, or if the primary response has AA=0 but a QTx response has AA=1, such as might happen if the NS and DS records were both requested at the parent side of a zone cut. The server MUST attempt to combine the remaining individual RRs into the same sections in which they would have appeared in a standalone query, i.e. as if each combination had been "the question" per section 4.1 of . The server MUST detect duplicate RRs and keep only a single copy of each RR in its respective section. Duplicates can occur e.g. in the Answer section if a CNAME chain is involved, or in the Authority section if multiple QTYPEs don't exist, etc. Note that RRs can be legitimately duplicated in different sections, e.g. for the (SOA, TYPE12345) combination on apex where TYPE12345 is not present. Handling of an MQTYE-Request option MUST NOT itself trigger a truncated response. If message size (or other) limits do not allow all of the data obtained by querying for an additional QTx to be included in the final response in their entireity (i.e. as complete RRsets) then the server MUST NOT include the respective QTx in the MQTYPE-Response option's list and MAY stop processing further QTx combinations. If all RRs for a single QTx combination fit into the message then the server MUST include the respective QTx in the MQTYPE-Response option's list to indicate that the given query type was completely processed.

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. If the MQTYPE-Response option is present more than once or if a QTx value is duplicated (or duplicates the primary QTYPE field) the client MUST treat the answer as invalid (equivalent to FORMERR) The Question section and the list of types present in the MQTYPE-Response option indicates the list of (QNAME, QCLASS, qtypes) combinations which are completely contained within the received response. The answers to all query combinations share the same RCODE and all other flags. All RRs required by existing DNS specifications are expected to be present in the respective sections of the DNS message, including proofs of nonexistence where required. The client MUST NOT rely on any particular order of RRs in the message sections. Clients MUST take into account that individual RRs might originate from different DNS zones and that proofs of non-existence might have been produced by different signers. Absence of QTx values which were requested by client but are not present in MQTYPE-Response option indicates that:

• the server was unwilling to process the request (e.g. because a limit was exceeded), and/or
• the individual responses could not be combined into one message because of RCODE or other flag mismatches, and/or
• the message size limit would be exceeded

The client SHOULD subsequently initiate standalone queries (e.g. without using the MQTYPE-Query option) for any QTx value which was requested but is missing in the response.

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. Implementors SHOULD allow operators to configure limits on the number of QTx values specified and/or the resulting response size.

IANA Considerations IANA has assigned the following in the "DNS EDNS0 Option Codes (OPT)" registry:

Value	Name	Status	Reference
20	MQTYPE-Query	Optional	RFC TBD
21	MQTYPE-Response	Optional	RFC TBD

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, David Schinazi and Petr Spacek.

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. 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 it specifies the required behavior 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 specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. 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. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.

 Examples The examples below are shown as might be reported by the ISC Dig utility. For the purposes of brevity irrelevant content is omitted.

Stub query for A with MQType-Request for AAAA + HTTPS In this example a stub resolver has requested the A record for www.example.com, along with an MQTYPE-Request option requesting AAAA and HTTPS records. The stub resolver has also set the DO bit, indicating DNSSEC support. The presence of the HTTPS QTYPE in the MQTYPE-Response option of the response coupled with its absence from the answer section indicates that the recursive server currently holds no data for this QTYPE. The corresponding type fields in the NSEC3 record further provide a cryptographic proof of non-existence for the HTTPS QTYPE and the SOA record also indicates a "negative answer".

A + AAAA + HTTPS >HEADER<<- opcode: QUERY, status: NOERROR, id: 11111 ;; flags: qr rd ra ad ;; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; MQTYPE-Response: AAAA HTTPS ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 2849 IN A 192.0.2.1 www.example.com. 2849 IN RRSIG A [...] www.example.com. 3552 IN AAAA 3fff::1234 www.example.com. 3552 IN RRSIG AAAA [...] ;; AUTHORITY SECTION: example.com. 2830 IN SOA ns.example.com. [...] example.com. 2830 IN RRSIG SOA 13 2 [...] [...].example.com. 2830 IN NSEC3 [...] A TXT AAAA RRSIG [...].example.com. 2830 IN RRSIG NSEC3 [...] ]]>

Stub query for DS with MQType-Request for DNSKEY In this similar example, the primary QTYPE is for DS and the MQTYPE-Request field only contains DNSKEY. Both the DS and DNSKEY records are returned, along with their corresponding RRSIG records.

Stub DS + DNSKEY >HEADER<<- opcode: QUERY, status: NOERROR, id: 33333 ;; flags: qr rd ra ad ;; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; MQTYPE-Response: DNSKEY ;; QUESTION SECTION: ;example.com. IN DS ;; ANSWER SECTION: example.com. 625 IN DNSKEY 256 3 13 [...] example.com. 625 IN DNSKEY 257 3 13 [...] example.com. 625 IN RRSIG DNSKEY [...] example.com. [...] example.com. 86185 IN DS 370 13 2 [...] example.com. 86185 IN RRSIG DS [...] com. [...] ]]>

Recursive query for DS with MQType-Request for NS In this instance, a recursive resolver is sending a DS record query to the parent zone's authoritative server and simultaneously requesting the NS records for the zone. Since the DS record response is marked as authoritative (AA = 1) but the NS record data on the parent side of a zone cut is not authoritative (AA = 0) the server is unable to merge the responses, and the NS QTYPE is omitted from the MQTYPE-Response field.

Recursive DS + NS >HEADER<<- opcode: QUERY, status: NOERROR, id: 33333 ;; flags: qr aa ;; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; MQTYPE-Response: [empty] ;; QUESTION SECTION: ;example.com. IN DS ;; ANSWER SECTION: example.com. 86185 IN DS 370 13 2 [...] example.com. 86185 IN RRSIG DS [...] com. [...] ]]>