idnits 2.17.1 draft-yao-dnsop-accompanying-questions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 268 has weird spacing: '...ponders would...' == Line 289 has weird spacing: '...ponders would...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 28, 2016) is 2920 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1321' is defined on line 336, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop J. Yao 3 Internet-Draft P. Vixie 4 Intended status: Standards Track CNNIC-Farsight Joint Laboratory 5 Expires: October 30, 2016 N. Kong 6 X. Li 7 CNNIC 8 April 28, 2016 10 A DNS Query including A Main Question with Accompanying Questions 11 draft-yao-dnsop-accompanying-questions-00 13 Abstract 15 This document enables DNS initiators to send a main question 16 accompanying with several related questions in a single DNS query, 17 and enables DNS responders to put the answers into a single DNS 18 response. This mechanism can reduce the number of DNS round-trips 19 per application work-unit. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 30, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Mechanism for a main question with accompanying questions . . 3 70 4. Responder Processing . . . . . . . . . . . . . . . . . . . . 5 71 5. Initiator Processing . . . . . . . . . . . . . . . . . . . . 6 72 6. Query and Response Example . . . . . . . . . . . . . . . . . 6 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 7 76 9.1. draft-yao-dnsop-accompanying-questions: Version 00 . . . 8 77 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 There are many scenarios in which an application must send several 83 related questions to a DNS responder. For examples, when asking 84 about a QTYPE=A RRset, a QTYPE=AAAA RRset may also be of use; When 85 asking for an A RRset, an MX RRset might also be of interest; When 86 asking for some RRset of example.com, records of a sub-domain name 87 such as www.example.com may be of interest. 89 Query example.com for A and AAAA 91 Query example.com for A and MX 93 Query example.com for A and www.example.com for A 95 This document describes a method by which DNS initiators can send a 96 main question accompanying with several related questions in a single 97 DNS query, and enables DNS responders place all related answers into 98 a single DNS response. This mechanism can reduce the number of DNS 99 round-trips per application work-unit, by carrying several related 100 queries in a single query transaction. 102 2. Terminology 104 The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as 106 described in [RFC2119]. 108 The basic DNS terms used in this specification are defined in the 109 documents [RFC1034] and [RFC1035]. 111 3. Mechanism for a main question with accompanying questions 113 The initiator still puts a main question into the question section of 114 the DNS query packet, as described in [RFC1035]. Accompanying 115 questions will be put into the variable part of an OPT RR [RFC6891]. 117 A new UAQ (Understand Accompanying Questions) bit in the EDNS flags 118 field [RFC6891] signals that the initiator may have included 119 accompanying questions in OPT RR of EDNS0. 121 If the query has accompanying questions, the accompanying questions 122 enabled initiators MUST set the UAQ bit in the query. The AQ aware 123 responder receiving the UAQ bit will indicate in the UAQ bit of the 124 response whether it implements this specification. [EDIT: Should we 125 just use the presence of an AQ OPT, without also adding a UAQ flag 126 bit, to indicate the use of the AQ feature? We can discuss it in WG 127 if this document is adopted.] 129 Below are Updated EDNS extended RCODE and Flags fields [RFC6891]: 131 +0 (MSB) +1 (LSB) 132 +--+---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 133 0: | EXTENDED-RCODE | VERSION | 134 +--+---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 135 2: |DO|UAQ| Z | 136 +--+---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 138 The variable part of an OPT RR is encoded in its RDATA and is 139 structured as the following: 141 +0 (MSB) +1 (LSB) 142 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 143 0: | OPTION-CODE | 144 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 145 2: | OPTION-LENGTH | 146 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 147 4: | | 148 / OPTION-DATA / 149 / / 150 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 152 OPTION-CODE (Assigned by IANA.) 154 OPTION-LENGTH Size (in octets) of OPTION-DATA. 156 OPTION-DATA including at most 8 accompanying questions with AQ-RCODE. 158 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 159 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 160 |AQ | Count/Seq | AQ-RCODE | 161 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 162 | | 163 / Accompanying Question / 164 / / 165 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 166 |AQ | Count/Seq | AQ-RCODE | 167 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 168 | | 169 / Accompanying Question / 170 / / 171 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 172 |AQ | Count/Seq | AQ-RCODE | 173 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 174 | | 175 / Accompanying Question / 176 / / 177 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 178 | | 179 / ...... / 180 / / 182 o AQ field indicates whether this accompanying question is the first 183 question. If it is set as 1, this question is the first question. 185 o Count/Seq field represents the sequence number of accompanying 186 questions from 1 to 7 or the total numbers of all accompanying 187 questions. If AQ is set as 0, the Count/Seq will represent the 188 sequence number of this accompanying question. If AQ is set as 1, 189 the Count/Seq will represent the total numbers of all accompanying 190 questions. There will have at most 8 accompanying questions. 192 o AQ-RCODE field will be set to 111111110100 bits when being 193 initialized. The AQ-RCODE with the value of 111111110100 bits 194 means that the mechanism for accompanying has not been 195 implemented. The AQ aware responders will put the RCODE value for 196 the query of this question into AQ-RCODE fields. 198 o Accompanying Question field is a question, in the format of a 199 "question" as defined in section 4.1.2 of RFC1035, shown below. 200 Within the QNAME, label compression pointers may be used. 202 1 1 1 1 1 1 203 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 204 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 | | 206 / QNAME / 207 / / 208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 209 | QTYPE | 210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 | QCLASS | 212 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 4. Responder Processing 216 The AQ aware responder will check the main question first, and put 217 the results into the DNS response packet. If the UAQ bit is set 218 [EDIT: or perhaps, if the AQ OPT is present], the responder checks 219 the accompanying questions in order, and put the results into the DNS 220 answer section of the response following RFC 1034; but the response 221 code is placed in the respective AQ-RCODE field in AQ OPT of the 222 response. The RCODE field in the DNS response header refers to the 223 main question only. An AQ unaware responder is expected to ignore 224 the UAQ bit and the AQ OPT of the query, and may echo the received 225 OPT back into additional section of the response message. 227 5. Initiator Processing 229 An AQ aware initiator will put the main question into the question 230 section of the DNS query packet, and put related accompanying 231 questions into the Accompanying Question fields of OPTION-DATA of OPT 232 RR. AQ-RCODE value will be sent as 111111110100 bits. The AQ value 233 should be set to 1 and Count/Seq value should be set to total number 234 of accompanying questions if the accompanying question is the first 235 one; For other accompanying questions, the AQ value should be set to 236 0 and Count/Seq value should be set to the sequence of the 237 accompanying questions. The UAQ bit should also be set when 238 sending accompanying questions. If the initial value of the AQ- 239 RCODE is unchanged in the response, it indicates that the responder 240 is AQ unaware. In that case, the responder will deal with the main 241 question only. The initiator should sent the accompanying questions 242 one by one via the normal DNS query. In such followup related 243 queries, AQ processing should probably not be attempted, to reduce 244 waste of network resources. 246 6. Query and Response Example 248 Example: one main question with 2 accompanying questions 250 The query would look like: 252 +---------------------------------------------------+ 253 Header | OPCODE=SQUERY | 254 +---------------------------------------------------+ 255 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 256 +---------------------------------------------------+ 257 Answer | | 258 +---------------------------------------------------+ 259 Authority | | 260 +---------------------------------------------------+ 261 Additional | UAQ=1 | 262 | AQ=1, COUNT/SEQ=2,AQ-RCODE=111111110100, | 263 | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=AAAA | 264 | AQ=0, COUNT/SEQ=1,AQ-RCODE=111111110100, | 265 | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=MX | 266 +---------------------------------------------------+ 268 The response from AQ aware responders would be: 270 +---------------------------------------------------+ 271 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 272 +---------------------------------------------------+ 273 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 274 +---------------------------------------------------+ 276 Answer | example.com IN A 192.168.0.1 | 277 | example.com. IN AAAA 2001:cc8::1 | 278 | example.com. IN MX MAIL.EXAMPLE.COM. | 279 +---------------------------------------------------+ 280 Authority | | 281 +---------------------------------------------------+ 282 Additional | UAQ=1 | 283 | AQ=1, COUNT/SEQ=2,AQ-RCODE=NOERROR, | 284 | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=AAAA | 285 | AQ=0, COUNT/SEQ=1,AQ-RCODE=NOERROR, | 286 | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=MX | 287 +---------------------------------------------------+ 289 The response from AQ unaware responders would be: 291 +---------------------------------------------------+ 292 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 293 +---------------------------------------------------+ 294 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 295 +---------------------------------------------------+ 296 Answer | example.com IN A 192.168.0.1 | 297 +---------------------------------------------------+ 298 Authority | | 299 +---------------------------------------------------+ 300 Additional | UAQ=1 | 301 | AQ=1, COUNT/SEQ=2,AQ-RCODE=111111110100, | 302 | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=AAAA | 303 | AQ=0, COUNT/SEQ=1,AQ-RCODE=111111110100, | 304 | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=MX | 305 +---------------------------------------------------+ 307 7. IANA Considerations 309 IANA should allocate DNS EDNS0 Option Codes (OPT) following this 310 document. IANA should reserve RCODE with the value of 111111110100 311 bits for this document. 313 8. Security Considerations 315 TBD 317 9. Change History 319 RFC Editor: Please remove this section. 321 9.1. draft-yao-dnsop-accompanying-questions: Version 00 323 o A Mechanism for DNS query including one main question with several 324 accompanying questions 326 10. Normative References 328 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 329 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 330 . 332 [RFC1035] Mockapetris, P., "Domain names - implementation and 333 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 334 November 1987, . 336 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 337 DOI 10.17487/RFC1321, April 1992, 338 . 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, 342 DOI 10.17487/RFC2119, March 1997, 343 . 345 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 346 for DNS (EDNS(0))", STD 75, RFC 6891, 347 DOI 10.17487/RFC6891, April 2013, 348 . 350 Authors' Addresses 352 Jiankang Yao 353 CNNIC-Farsight Joint Laboratory 354 4 South 4th Street,Zhongguancun,Haidian District 355 Beijing, Beijing 100190 356 China 358 Phone: +86 10 5881 3007 359 Email: yaojk@cnnic.cn 360 Paul Vixie 361 CNNIC-Farsight Joint Laboratory 362 4 South 4th Street,Zhongguancun,Haidian District 363 Beijing, Beijing 100190 364 China 366 Phone: +1 650 489 7919 367 Email: vixie@fsi.io 369 Ning Kong 370 CNNIC 371 4 South 4th Street,Zhongguancun,Haidian District 372 Beijing, Beijing 100190 373 China 375 Phone: +86 10 5881 3147 376 Email: nkong@cnnic.cn 378 Xiaodong Li 379 CNNIC 380 4 South 4th Street,Zhongguancun,Haidian District 381 Beijing, Beijing 100190 382 China 384 Phone: +86 10 5881 3020 385 Email: xl@cnnic.cn