idnits 2.17.1 draft-yao-dnsop-accompanying-questions-03.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 362 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 (June 23, 2017) is 2498 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 5321' is mentioned on line 126, but not defined == Missing Reference: 'RFC 6698' is mentioned on line 128, but not defined == Unused Reference: 'RFC5321' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 440, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 10 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: December 25, 2017 N. Kong 6 X. Li 7 CNNIC 8 June 23, 2017 10 A DNS Query including A Main Question with Accompanying Questions 11 draft-yao-dnsop-accompanying-questions-03 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 extension enables a range of initiators to look up 19 "X, or failing that, Y" in a better way than both current 20 alternatives. This mechanism can reduce the number of DNS round- 21 trips per application work-unit. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 25, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Mechanism for a main question with accompanying questions . . 3 72 4. Responder Processing . . . . . . . . . . . . . . . . . . . . 6 73 5. Initiator Processing . . . . . . . . . . . . . . . . . . . . 7 74 6. Query and Response Example . . . . . . . . . . . . . . . . . 7 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 9 79 10.1. draft-yao-dnsop-accompanying-questions: Version 00 . . . 9 80 10.2. draft-yao-dnsop-accompanying-questions: Version 01 . . . 9 81 10.3. draft-yao-dnsop-accompanying-questions: Version 02 . . . 9 82 10.4. draft-yao-dnsop-accompanying-questions: Version 03 . . . 9 83 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 Sometimes, when DNS lookup of X, an application will lookup Y if X 89 fails. For examples, the initiator may fall back to A record if the 90 lookup of MX record fails. 92 Some initiators do it in sequence, X and after a few seconds, then Y. 93 Although it is simple, this leads to unpleasant waiting whenever X 94 times out or answers negatively. 96 Some initiators use concurrent X/Y lookups and a state machine to 97 decide whether to use X or Y. If an answer to Y arrives but none to 98 X, the initiator needs to wait a little or else fall back to Y 99 inappropriately. Concurrent lookup is faster if the X lookup takes 100 time and falling back to Y is appropriate, but rather complex, with 101 four states to test, and the initiator needs to wait for an answer to 102 X or a timeout before it can use Y. 104 This document enables a quicker, more easily tested failover. There 105 is no need to test different answer sequences, there's no need for a 106 state machine, there's no need for timeouts beyond receiving the 107 reply. This document describes a method by which DNS initiators can 108 send a main question accompanying with several related questions in a 109 single DNS query, and enables DNS responders place all related 110 answers into a single DNS response. This mechanism can reduce the 111 number of DNS round-trips per application work-unit, by carrying 112 several related queries in a single query transaction. It has the 113 following advantages compared to other solutions. 115 o Compared to sequential lookups: It's roughly as simple, but much 116 faster in case a fallback to Y is necessary. 118 o Compared to the concurrent mechanism: It is slightly faster (if 119 the initiator needs to wait for an X timeout) and/or prevents 120 inappropriate fallback (if the answer to X arrives too late), and 121 it has a simpler state machine. 123 This mechanism can also be used in the scenarios when the application 124 needs more records of the same domain name or its sub-domain name. 125 For examples, when asking about a QTYPE=A RRset, a QTYPE=AAAA RRset 126 may also be of use [RFC 5321]; When asking for some RRset of 127 www.example.com about A and AAAA, records of a sub-domain name such 128 as _443._tcp.www.example.com for TLSA may be of interest[RFC 6698]. 130 2. Terminology 132 The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as 134 described in [RFC2119]. 136 The basic DNS terms used in this specification are defined in the 137 documents [RFC1034] and [RFC1035]. 139 3. Mechanism for a main question with accompanying questions 141 The initiator still puts a main question into the question section of 142 the DNS query packet, as described in [RFC1035]. Accompanying 143 questions will be put into the variable part of an OPT RR [RFC6891]. 145 The variable part of an OPT RR is encoded in its RDATA and is 146 structured as the following: 148 +0 (MSB) +1 (LSB) 149 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 150 0: | OPTION-CODE | 151 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 152 2: | OPTION-LENGTH | 153 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 154 4: | | 155 / OPTION-DATA / 156 / / 157 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 159 OPTION-CODE (Assigned by IANA.) 161 OPTION-LENGTH Size (in octets) of OPTION-DATA. 163 OPTION-DATA including at most 8 accompanying questions with AQ-RCODE. 165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 166 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 167 | Reserved | AQ-RCODE | 168 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 169 | AQ-TYPE | 170 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 171 | AQ-ANCOUNT | 172 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 173 | AQ-NSCOUNT | 174 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 175 | AQ-ARCOUNT | 176 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 177 | | 178 / Prefix / 179 / / 180 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 181 | Reserved | AQ-RCODE | 182 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 183 | AQ-TYPE | 184 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 185 | AQ-ANCOUNT | 186 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 187 | AQ-NSCOUNT | 188 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 189 | AQ-ARCOUNT | 190 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 191 | | 192 / Prefix / 193 / / 194 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 195 | Reserved | AQ-RCODE | 196 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 197 | AQ-TYPE | 198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 199 | AQ-ANCOUNT | 200 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 201 | AQ-NSCOUNT | 202 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 203 | AQ-ARCOUNT | 204 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 | | 206 / Prefix / 207 / / 208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 209 | | 210 / ...... / 211 / / 213 o Reserved field is kept for the future use. 215 o AQ-RCODE field will be set to 111111110100 bits when being 216 initialized. The AQ-RCODE with the value of 111111110100 bits 217 means that the mechanism for accompanying has not been 218 implemented, where "0100" in the RCODE value means "not been 219 implemented". The AQ aware responders will put the RCODE value 220 for the query of this question into AQ-RCODE fields. 222 o AQ-ANCOUNT field will indicate the number of resource records in 223 the answer section for this accompanying question. The AQ aware 224 responders will put the ANCOUNT value for the query of this 225 question into AQ-ANCOUNT field. 227 o AQ-NSCOUNT field will indicate the number of name server resource 228 records in the authority records section for this accompanying 229 question. The AQ aware responders will put the NSCOUNT value for 230 the query of this question into AQ-NSCOUNT field. 232 o AQ-ARCOUNT field will indicate the number of resource records in 233 the additional records section for this accompanying question. 234 The AQ aware responders will put the ARCOUNT value for the query 235 of this question into AQ-ARCOUNT field. 237 o Prefix field indicates a domain name with the form of a pointer or 238 a sequence of labels ending with a pointer using the message 239 compression defined in section 4.1.4. of RFC 1035. The domain 240 name for accompanying questions MUST be same with the domain name 241 for a main question or be children name of it. For an example, if 242 the main domain name is example.com and the accompanying domain 243 name is mail.example.com., the prefix is "mail." ending with a 244 pointer pointing to "example.com.". 246 4. Responder Processing 248 The AQ aware responder will check the main question first, and put 249 the results into the DNS response packet following RFC 1034. If the 250 AQ OPT is present, the responder assembles the prefix with the main 251 domain name and makes it to be an accompanying question, checks the 252 accompanying questions in order, and put the results into the DNS 253 answer section, authority section or additional records section of 254 the response following RFC 1034; but the response code is placed in 255 the respective AQ-RCODE field in AQ OPT of the response. The RCODE 256 field in the DNS response header refers to the main question only. 257 The AQ aware responders will put the ANCOUNT, NSCOUNT and ARCOUNT 258 value for the query of this accompanying question into the respective 259 AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT fields. The ANCOUNT, NSCOUNT 260 and ARCOUNT fields in the DNS response header refer to the main 261 question only. When the answer is negative for the accompanying 262 question, the SOA resource record will be put in the authority 263 section. 265 The mechanism proposed in this document is intended for both between 266 stub resolvers and recursive resolvers, and between recursive 267 resolvers and authoritative servers. Most DNS resource records 268 needed to process parallel query are normally located in the same 269 zone. In case of that some children domain names are delegated and 270 not in the main domain name's zone, the delegation information will 271 be returned to the recursive resolvers. The recursive resolvers then 272 check the children domain based on the delegation information, and 273 get the answer for the respective children domain names. 275 When a stub resolver sends an AQ query to the recursive resolver, the 276 recursive resolver may have some answers for one or more questions in 277 the cache, but not for all questions. Under that case, the recursive 278 resolver SHOULD forward this AQ query to some relative authoritative 279 servers for full answers instead of using the existing insufficient 280 cache information. 282 An AQ unaware responder is expected to ignore the AQ OPT of the 283 query, and may echo the received OPT back into additional section of 284 the response message. 286 5. Initiator Processing 288 An AQ aware initiator will put the main question into the question 289 section of the DNS query packet, and put related accompanying 290 questions into the related accompanying question fields of OPTION- 291 DATA of OPT RR. AQ-RCODE value will be sent as 111111110100 bits. 292 The AQ-TYPE value should be set as the query type related to 293 accompanying questions. The Prefix value should be set as a pointer 294 or a sequence of labels ending with a pointer pointing to the the 295 main domain name of the main question for the respective accompanying 296 domain name of the accompanying question. 298 An AQ aware initiator SHOULD set the limitation of what is the 299 maximum number of accompanying questions a AQ query can bring. This 300 document suggests that the maximum number is six since most DNS 301 resource records which need parallel query will not larger than six. 302 The implementers may set six as the defaul value in the 303 implementation. The responder can refuse to answer the AQ query if 304 the maximum number of the accompanying questions is larger than the 305 default maximum value, and return "not been implemented, too many 306 accompanying-questions." information to the initiator. 308 If the initial value of the AQ-RCODE is unchanged in the response or 309 the AQ OPT is not echo back, it indicates that the responder is AQ 310 unaware. In that case, the responder will deal with the main 311 question only. The initiator should sent the accompanying questions 312 one by one via the normal DNS query. In such followup related 313 queries, AQ processing should probably not be attempted, to reduce 314 waste of network resources. 316 6. Query and Response Example 318 Example: one main question with 2 accompanying questions 320 The query would look like: 322 +---------------------------------------------------+ 323 Header | OPCODE=SQUERY | 324 +---------------------------------------------------+ 325 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 326 +---------------------------------------------------+ 327 Answer | | 328 +---------------------------------------------------+ 329 Authority | | 330 +---------------------------------------------------+ 331 Additional | | 332 | AQ-TYPE=AAAA,AQ-RCODE=111111110100, | 333 | Prefix=EXAMPLE.COM., | 334 | AQ-TYPE=TLSA,,AQ-RCODE=111111110100, | 335 | Prefix=_443._tcp.EXAMPLE.COM., | 336 +---------------------------------------------------+ 338 The response from AQ aware responders would be: 340 +---------------------------------------------------+ 341 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 342 | ANCOUNT=1, ARCOUNT=1, NSCOUNT=0 | 343 +---------------------------------------------------+ 344 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 345 +---------------------------------------------------+ 346 Answer | example.com IN A 192.168.0.1 | 347 | example.com. IN AAAA 2001:cc8::1 | 348 | _443._tcp.example.com. IN TLSA | 349 | ( 3 0 0 30820307308201efa003020102020... ) | 350 +---------------------------------------------------+ 351 Authority | | 352 +---------------------------------------------------+ 353 Additional | | 354 | AQ-TYPE=AAAA, AQ-RCODE=NOERROR, AQ-ANCOUNT=1, | 355 | AQ-ARCOUNT=0, AQ-NSCOUNT=0, | 356 | Prefix=EXAMPLE.COM., | 357 | AQ-TYPE=TLSA, AQ-RCODE=NOERROR, AQ-ANCOUNT=1, | 358 | AQ-ARCOUNT=0, AQ-NSCOUNT=0, | 359 | Prefix=_443._tcp.EXAMPLE.COM., | 360 +---------------------------------------------------+ 362 The response from AQ unaware responders would be: 364 +---------------------------------------------------+ 365 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 366 +---------------------------------------------------+ 367 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 368 +---------------------------------------------------+ 369 Answer | example.com. IN A 192.168.0.1 | 370 +---------------------------------------------------+ 371 Authority | | 372 +---------------------------------------------------+ 373 Additional | | 374 | AQ-TYPE=AAAA,AQ-RCODE=111111110100, | 375 | Prefix=EXAMPLE.COM., | 376 | AQ-TYPE=TLSA, AQ-RCODE=111111110100, | 377 | Prefix=_443._tcp.EXAMPLE.COM., | 378 +---------------------------------------------------+ 380 7. IANA Considerations 382 IANA should allocate DNS EDNS0 Option Codes (OPT) following this 383 document. IANA should reserve RCODE with the value of 111111110100 384 bits for this document. 386 8. Security Considerations 388 TBD 390 9. Acknowledgements 392 The authors thank the members in DNSOP mailing list for helpful 393 discussions, and especially thank Kazunori Fujiwara, JINMEI Tatuya, 394 Bob Harold, Arnt Gulbrandsen and Olafur Gudmundsson for kind 395 comments, suggestions and improvements for the document. The authors 396 also thanks Likun Zhang for helpful discussion about some topics 397 related to implementation. 399 10. Change History 401 RFC Editor: Please remove this section. 403 10.1. draft-yao-dnsop-accompanying-questions: Version 00 405 o A Mechanism for DNS query including one main question with several 406 accompanying questions 408 10.2. draft-yao-dnsop-accompanying-questions: Version 01 410 o Simpilfy the mechanism. 412 10.3. draft-yao-dnsop-accompanying-questions: Version 02 414 o Remove the AQ and Count bits, and add AQ-ANCOUNT AQ-ARCOUNT AQ- 415 NSCOUNT 417 10.4. draft-yao-dnsop-accompanying-questions: Version 03 419 o Improve the introduction and explains the motivation of this draft 421 11. Normative References 423 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 424 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 425 . 427 [RFC1035] Mockapetris, P., "Domain names - implementation and 428 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 429 November 1987, . 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 437 DOI 10.17487/RFC5321, October 2008, 438 . 440 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 441 of Named Entities (DANE) Transport Layer Security (TLS) 442 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 443 2012, . 445 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 446 for DNS (EDNS(0))", STD 75, RFC 6891, 447 DOI 10.17487/RFC6891, April 2013, 448 . 450 Authors' Addresses 452 Jiankang Yao 453 CNNIC-Farsight Joint Laboratory 454 4 South 4th Street,Zhongguancun,Haidian District 455 Beijing, Beijing 100190 456 China 458 Phone: +86 10 5881 3007 459 Email: yaojk@cnnic.cn 461 Paul Vixie 462 CNNIC-Farsight Joint Laboratory 463 4 South 4th Street,Zhongguancun,Haidian District 464 Beijing, Beijing 100190 465 China 467 Phone: +1 650 489 7919 468 Email: vixie@fsi.io 469 Ning Kong 470 CNNIC 471 4 South 4th Street,Zhongguancun,Haidian District 472 Beijing, Beijing 100190 473 China 475 Phone: +86 10 5881 3147 476 Email: nkong@cnnic.cn 478 Xiaodong Li 479 CNNIC 480 4 South 4th Street,Zhongguancun,Haidian District 481 Beijing, Beijing 100190 482 China 484 Phone: +86 10 5881 3020 485 Email: xl@cnnic.cn