idnits 2.17.1 draft-yao-dnsop-accompanying-questions-02.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 335 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 (October 30, 2016) is 2734 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) == Missing Reference: 'RFC 6698' is mentioned on line 90, but not defined == Unused Reference: 'RFC5321' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 408, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 9 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: May 3, 2017 N. Kong 6 X. Li 7 CNNIC 8 October 30, 2016 10 A DNS Query including A Main Question with Accompanying Questions 11 draft-yao-dnsop-accompanying-questions-02 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 May 3, 2017. 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 . . . . . . . . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. draft-yao-dnsop-accompanying-questions: Version 00 . . . 9 78 10.2. draft-yao-dnsop-accompanying-questions: Version 01 . . . 9 79 10.3. draft-yao-dnsop-accompanying-questions: Version 02 . . . 9 80 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 There are many scenarios in which an application must send several 86 related questions to a DNS responder. For examples, when asking 87 about a QTYPE=A RRset, a QTYPE=AAAA RRset may also be of use [RFC 88 5321]; When asking for some RRset of www.example.com about A and 89 AAAA, records of a sub-domain name such as _443._tcp.www.example.com 90 for TLSA may be of interest[RFC 6698]. 92 Query example.com for A and AAAA 94 Query www.example.com for A and AAAA, and _443._tcp.www.example.com 95 for TLSA 96 This document describes a method by which DNS initiators can send a 97 main question accompanying with several related questions in a single 98 DNS query, and enables DNS responders place all related answers into 99 a single DNS response. This mechanism can reduce the number of DNS 100 round-trips per application work-unit, by carrying several related 101 queries in a single query transaction. 103 2. Terminology 105 The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as 107 described in [RFC2119]. 109 The basic DNS terms used in this specification are defined in the 110 documents [RFC1034] and [RFC1035]. 112 3. Mechanism for a main question with accompanying questions 114 The initiator still puts a main question into the question section of 115 the DNS query packet, as described in [RFC1035]. Accompanying 116 questions will be put into the variable part of an OPT RR [RFC6891]. 118 The variable part of an OPT RR is encoded in its RDATA and is 119 structured as the following: 121 +0 (MSB) +1 (LSB) 122 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 123 0: | OPTION-CODE | 124 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 125 2: | OPTION-LENGTH | 126 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 127 4: | | 128 / OPTION-DATA / 129 / / 130 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 132 OPTION-CODE (Assigned by IANA.) 134 OPTION-LENGTH Size (in octets) of OPTION-DATA. 136 OPTION-DATA including at most 8 accompanying questions with AQ-RCODE. 138 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 139 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 140 | Reserved | AQ-RCODE | 141 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 142 | AQ-TYPE | 143 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 144 | AQ-ANCOUNT | 145 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 146 | AQ-NSCOUNT | 147 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 148 | AQ-ARCOUNT | 149 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 150 | | 151 / Prefix / 152 / / 153 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 154 | Reserved | AQ-RCODE | 155 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 156 | AQ-TYPE | 157 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 158 | AQ-ANCOUNT | 159 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 160 | AQ-NSCOUNT | 161 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 162 | AQ-ARCOUNT | 163 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 164 | | 165 / Prefix / 166 / / 167 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 168 | Reserved | AQ-RCODE | 169 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 170 | AQ-TYPE | 171 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 172 | AQ-ANCOUNT | 173 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 174 | AQ-NSCOUNT | 175 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 176 | AQ-ARCOUNT | 177 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 178 | | 179 / Prefix / 180 / / 181 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 182 | | 183 / ...... / 184 / / 186 o Reserved field is kept for the future use. 188 o AQ-RCODE field will be set to 111111110100 bits when being 189 initialized. The AQ-RCODE with the value of 111111110100 bits 190 means that the mechanism for accompanying has not been 191 implemented, where "0100" in the RCODE value means "not been 192 implemented". The AQ aware responders will put the RCODE value 193 for the query of this question into AQ-RCODE fields. 195 o AQ-ANCOUNT field will indicate the number of resource records in 196 the answer section for this accompanying question. The AQ aware 197 responders will put the ANCOUNT value for the query of this 198 question into AQ-ANCOUNT field. 200 o AQ-NSCOUNT field will indicate the number of name server resource 201 records in the authority records section for this accompanying 202 question. The AQ aware responders will put the NSCOUNT value for 203 the query of this question into AQ-NSCOUNT field. 205 o AQ-ARCOUNT field will indicate the number of resource records in 206 the additional records section for this accompanying question. 207 The AQ aware responders will put the ARCOUNT value for the query 208 of this question into AQ-ARCOUNT field. 210 o Prefix field indicates a domain name with the form of a pointer or 211 a sequence of labels ending with a pointer using the message 212 compression defined in section 4.1.4. of RFC 1035. The domain 213 name for accompanying questions MUST be same with the domain name 214 for a main question or be children name of it. For an example, if 215 the main domain name is example.com and the accompanying domain 216 name is mail.example.com., the prefix is "mail." ending with a 217 pointer pointing to "example.com.". 219 4. Responder Processing 221 The AQ aware responder will check the main question first, and put 222 the results into the DNS response packet following RFC 1034. If the 223 AQ OPT is present, the responder assembles the prefix with the main 224 domain name and makes it to be an accompanying question, checks the 225 accompanying questions in order, and put the results into the DNS 226 answer section, authority section or additional records section of 227 the response following RFC 1034; but the response code is placed in 228 the respective AQ-RCODE field in AQ OPT of the response. The RCODE 229 field in the DNS response header refers to the main question only. 230 The AQ aware responders will put the ANCOUNT, NSCOUNT and ARCOUNT 231 value for the query of this accompanying question into the respective 232 AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT fields. The ANCOUNT, NSCOUNT 233 and ARCOUNT fields in the DNS response header refer to the main 234 question only. When the answer is negative for the accompanying 235 question, the SOA resource record will be put in the authority 236 section. 238 The mechanism proposed in this document is intended for both between 239 stub resolvers and recursive resolvers, and between recursive 240 resolvers and authoritative servers. Most DNS resource records 241 needed to process parallel query are normally located in the same 242 zone. In case of that some children domain names are delegated and 243 not in the main domain name's zone, the delegation information will 244 be returned to the recursive resolvers. The recursive resolvers then 245 check the children domain based on the delegation information, and 246 get the answer for the respective children domain names. 248 When a stub resolver sends an AQ query to the recursive resolver, the 249 recursive resolver may have some answers for one or more questions in 250 the cache, but not for all questions. Under that case, the recursive 251 resolver SHOULD forward this AQ query to some relative authoritative 252 servers for full answers instead of using the existing insufficient 253 cache information. 255 An AQ unaware responder is expected to ignore the AQ OPT of the 256 query, and may echo the received OPT back into additional section of 257 the response message. 259 5. Initiator Processing 261 An AQ aware initiator will put the main question into the question 262 section of the DNS query packet, and put related accompanying 263 questions into the related accompanying question fields of OPTION- 264 DATA of OPT RR. AQ-RCODE value will be sent as 111111110100 bits. 265 The AQ-TYPE value should be set as the query type related to 266 accompanying questions. The Prefix value should be set as a pointer 267 or a sequence of labels ending with a pointer pointing to the the 268 main domain name of the main question for the respective accompanying 269 domain name of the accompanying question. 271 An AQ aware initiator SHOULD set the limitation of what is the 272 maximum number of accompanying questions a AQ query can bring. This 273 document suggests that the maximum number is six since most DNS 274 resource records which need parallel query will not larger than six. 275 The implementers may set six as the defaul value in the 276 implementation. The responder can refuse to answer the AQ query if 277 the maximum number of the accompanying questions is larger than the 278 default maximum value, and return "not been implemented, too many 279 accompanying-questions." information to the initiator. 281 If the initial value of the AQ-RCODE is unchanged in the response or 282 the AQ OPT is not echo back, it indicates that the responder is AQ 283 unaware. In that case, the responder will deal with the main 284 question only. The initiator should sent the accompanying questions 285 one by one via the normal DNS query. In such followup related 286 queries, AQ processing should probably not be attempted, to reduce 287 waste of network resources. 289 6. Query and Response Example 291 Example: one main question with 2 accompanying questions 293 The query would look like: 295 +---------------------------------------------------+ 296 Header | OPCODE=SQUERY | 297 +---------------------------------------------------+ 298 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 299 +---------------------------------------------------+ 300 Answer | | 301 +---------------------------------------------------+ 302 Authority | | 303 +---------------------------------------------------+ 304 Additional | | 305 | AQ-TYPE=AAAA,AQ-RCODE=111111110100, | 306 | Prefix=EXAMPLE.COM., | 307 | AQ-TYPE=TLSA,,AQ-RCODE=111111110100, | 308 | Prefix=_443._tcp.EXAMPLE.COM., | 309 +---------------------------------------------------+ 311 The response from AQ aware responders would be: 313 +---------------------------------------------------+ 314 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 315 | ANCOUNT=1, ARCOUNT=1, NSCOUNT=0 | 316 +---------------------------------------------------+ 317 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 318 +---------------------------------------------------+ 319 Answer | example.com IN A 192.168.0.1 | 320 | example.com. IN AAAA 2001:cc8::1 | 321 | _443._tcp.example.com. IN TLSA | 322 | ( 3 0 0 30820307308201efa003020102020... ) | 323 +---------------------------------------------------+ 324 Authority | | 325 +---------------------------------------------------+ 326 Additional | | 327 | AQ-TYPE=AAAA, AQ-RCODE=NOERROR, AQ-ANCOUNT=1, | 328 | AQ-ARCOUNT=0, AQ-NSCOUNT=0, | 329 | Prefix=EXAMPLE.COM., | 330 | AQ-TYPE=TLSA, AQ-RCODE=NOERROR, AQ-ANCOUNT=1, | 331 | AQ-ARCOUNT=0, AQ-NSCOUNT=0, | 332 | Prefix=_443._tcp.EXAMPLE.COM., | 333 +---------------------------------------------------+ 335 The response from AQ unaware responders would be: 337 +---------------------------------------------------+ 338 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 339 +---------------------------------------------------+ 340 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 341 +---------------------------------------------------+ 342 Answer | example.com. IN A 192.168.0.1 | 343 +---------------------------------------------------+ 344 Authority | | 345 +---------------------------------------------------+ 346 Additional | | 347 | AQ-TYPE=AAAA,AQ-RCODE=111111110100, | 348 | Prefix=EXAMPLE.COM., | 349 | AQ-TYPE=TLSA, AQ-RCODE=111111110100, | 350 | Prefix=_443._tcp.EXAMPLE.COM., | 351 +---------------------------------------------------+ 353 7. IANA Considerations 355 IANA should allocate DNS EDNS0 Option Codes (OPT) following this 356 document. IANA should reserve RCODE with the value of 111111110100 357 bits for this document. 359 8. Security Considerations 361 TBD 363 9. Acknowledgements 365 The authors thank the members in DNSOP mailing list for helpful 366 discussions, and especially thank Kazunori Fujiwara, JINMEI Tatuya 367 and Bob Harold for kind comments, suggestions and improvements for 368 the document. The authors also thanks Likun Zhang for helpful 369 discussion about some topics related to implementation. 371 10. Change History 373 RFC Editor: Please remove this section. 375 10.1. draft-yao-dnsop-accompanying-questions: Version 00 377 o A Mechanism for DNS query including one main question with several 378 accompanying questions 380 10.2. draft-yao-dnsop-accompanying-questions: Version 01 382 o Simpilfy the mechanism. 384 10.3. draft-yao-dnsop-accompanying-questions: Version 02 386 o Remove the AQ and Count bits, and add AQ-ANCOUNT AQ-ARCOUNT AQ- 387 NSCOUNT 389 11. Normative References 391 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 392 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 393 . 395 [RFC1035] Mockapetris, P., "Domain names - implementation and 396 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 397 November 1987, . 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 405 DOI 10.17487/RFC5321, October 2008, 406 . 408 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 409 of Named Entities (DANE) Transport Layer Security (TLS) 410 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 411 2012, . 413 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 414 for DNS (EDNS(0))", STD 75, RFC 6891, 415 DOI 10.17487/RFC6891, April 2013, 416 . 418 Authors' Addresses 419 Jiankang Yao 420 CNNIC-Farsight Joint Laboratory 421 4 South 4th Street,Zhongguancun,Haidian District 422 Beijing, Beijing 100190 423 China 425 Phone: +86 10 5881 3007 426 Email: yaojk@cnnic.cn 428 Paul Vixie 429 CNNIC-Farsight Joint Laboratory 430 4 South 4th Street,Zhongguancun,Haidian District 431 Beijing, Beijing 100190 432 China 434 Phone: +1 650 489 7919 435 Email: vixie@fsi.io 437 Ning Kong 438 CNNIC 439 4 South 4th Street,Zhongguancun,Haidian District 440 Beijing, Beijing 100190 441 China 443 Phone: +86 10 5881 3147 444 Email: nkong@cnnic.cn 446 Xiaodong Li 447 CNNIC 448 4 South 4th Street,Zhongguancun,Haidian District 449 Beijing, Beijing 100190 450 China 452 Phone: +86 10 5881 3020 453 Email: xl@cnnic.cn