idnits 2.17.1 draft-yao-dnsop-accompanying-questions-04.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 370 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 (September 17, 2017) is 2412 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 127, but not defined == Missing Reference: 'RFC 6698' is mentioned on line 129, but not defined == Unused Reference: 'RFC5321' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 452, 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: March 21, 2018 N. Kong 6 X. Li 7 CNNIC 8 September 17, 2017 10 A DNS Query including A Main Question with Accompanying Questions 11 draft-yao-dnsop-accompanying-questions-04 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 https://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 March 21, 2018. 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 (https://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 . . . 10 83 10.5. draft-yao-dnsop-accompanying-questions: Version 04 . . . 10 84 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 Sometimes, when DNS lookup of X, an application will lookup Y if X 90 fails. For examples, the initiator may fall back to A record if the 91 lookup of MX record fails. 93 Some initiators do it in sequence, X and after a few seconds, then Y. 94 Although it is simple, this leads to unpleasant waiting whenever X 95 times out or answers negatively. 97 Some initiators use concurrent X/Y lookups and a state machine to 98 decide whether to use X or Y. If an answer to Y arrives but none to 99 X, the initiator needs to wait a little or else fall back to Y 100 inappropriately. Concurrent lookup is faster if the X lookup takes 101 time and falling back to Y is appropriate, but rather complex, with 102 four states to test, and the initiator needs to wait for an answer to 103 X or a timeout before it can use Y. 105 This document enables a quicker, more easily tested failover. There 106 is no need to test different answer sequences, there's no need for a 107 state machine, there's no need for timeouts beyond receiving the 108 reply. This document describes a method by which DNS initiators can 109 send a main question accompanying with several related questions in a 110 single DNS query, and enables DNS responders place all related 111 answers into a single DNS response. This mechanism can reduce the 112 number of DNS round-trips per application work-unit, by carrying 113 several related queries in a single query transaction. It has the 114 following advantages compared to other solutions. 116 o Compared to sequential lookups: It's roughly as simple, but much 117 faster in case a fallback to Y is necessary. 119 o Compared to the concurrent mechanism: It is slightly faster (if 120 the initiator needs to wait for an X timeout) and/or prevents 121 inappropriate fallback (if the answer to X arrives too late), and 122 it has a simpler state machine. 124 This mechanism can also be used in the scenarios when the application 125 needs more records of the same domain name or its sub-domain name. 126 For examples, when asking about a QTYPE=A RRset, a QTYPE=AAAA RRset 127 may also be of use [RFC 5321]; When asking for some RRset of 128 www.example.com about A and AAAA, records of a sub-domain name such 129 as _443._tcp.www.example.com for TLSA may be of interest[RFC 6698]. 131 2. Terminology 133 The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as 135 described in [RFC2119]. 137 The basic DNS terms used in this specification are defined in the 138 documents [RFC1034] and [RFC1035]. 140 3. Mechanism for a main question with accompanying questions 142 The initiator still puts a main question into the question section of 143 the DNS query packet, as described in [RFC1035]. Accompanying 144 questions will be put into the variable part of an OPT RR [RFC6891]. 146 The variable part of an OPT RR is encoded in its RDATA and is 147 structured as the following: 149 +0 (MSB) +1 (LSB) 150 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 151 0: | OPTION-CODE | 152 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 153 2: | OPTION-LENGTH | 154 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 155 4: | | 156 / OPTION-DATA / 157 / / 158 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 160 OPTION-CODE (Assigned by IANA.) 162 OPTION-LENGTH Size (in octets) of OPTION-DATA. 164 OPTION-DATA including at most 6 accompanying questions with AQ-RCODE. 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 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 | Reserved | AQ-RCODE | 183 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 184 | AQ-TYPE | 185 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 186 | AQ-ANCOUNT | 187 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 188 | AQ-NSCOUNT | 189 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 190 | AQ-ARCOUNT | 191 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 192 | | 193 / Prefix / 194 / / 195 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 196 | Reserved | AQ-RCODE | 197 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 198 | AQ-TYPE | 199 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 200 | AQ-ANCOUNT | 201 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 202 | AQ-NSCOUNT | 203 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 204 | AQ-ARCOUNT | 205 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 206 | | 207 / Prefix / 208 / / 209 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 210 | | 211 / ...... / 212 / / 214 o Reserved field is kept for the future use. 216 o AQ-RCODE field will be set to 111111110100 bits when being 217 initialized. The AQ-RCODE with the value of 111111110100 bits 218 means that the mechanism for accompanying has not been 219 implemented, where "0100" in the RCODE value means "not been 220 implemented". The AQ aware responders will put the RCODE value 221 for the query of this question into AQ-RCODE fields. 223 o AQ-ANCOUNT field will indicate the number of resource records in 224 the answer section for this accompanying question. The AQ aware 225 responders will put the ANCOUNT value for the query of this 226 question into AQ-ANCOUNT field. 228 o AQ-NSCOUNT field will indicate the number of name server resource 229 records in the authority records section for this accompanying 230 question. The AQ aware responders will put the NSCOUNT value for 231 the query of this question into AQ-NSCOUNT field. 233 o AQ-ARCOUNT field will indicate the number of resource records in 234 the additional records section for this accompanying question. 235 The AQ aware responders will put the ARCOUNT value for the query 236 of this question into AQ-ARCOUNT field. 238 o Prefix field indicates a domain name with the form of a dot or a 239 sequence of labels ending with a pointer using the message 240 compression defined in section 4.1.4. of RFC 1035. The domain 241 name for accompanying questions MUST be same with the domain name 242 for a main question or be children name of it. For an example, if 243 the main domain name is example.com and the accompanying domain 244 name is mail.example.com., the prefix is "mail." ending with a 245 pointer pointing to "example.com.". 247 4. Responder Processing 249 The AQ aware responder will check the main question first, and put 250 the results into the DNS response packet following RFC 1034. If the 251 AQ OPT is present, the responder assembles the prefix with the main 252 domain name and makes it to be an accompanying question, checks the 253 accompanying questions in order, and put the results into the DNS 254 answer section, authority section or additional records section of 255 the response following RFC 1034; but the response code is placed in 256 the respective AQ-RCODE field in AQ OPT of the response. The RCODE 257 field in the DNS response header refers to the main question only. 258 The AQ aware responders will put the ANCOUNT, NSCOUNT and ARCOUNT 259 value for the query of this accompanying question into the respective 260 AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT fields. The ANCOUNT, NSCOUNT 261 and ARCOUNT fields in the DNS response header refer to the main 262 question and its accompanying questions. Since the value for the 263 accompanying questions' ANCOUNT, NSCOUNT and ARCOUNT can be known 264 from the respective value of AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT, 265 the actual value of the main question's ANCOUNT, NSCOUNT and ARCOUNT 266 can be calculated from the ANCOUNT, NSCOUNT and ARCOUNT in the DNS 267 response header. When the answer is negative for the accompanying 268 question, the SOA resource record will be put in the authority 269 section. 271 The mechanism proposed in this document is intended for both between 272 stub resolvers and recursive resolvers, and between recursive 273 resolvers and authoritative servers. If some DNS resource records 274 are needed to be processed at the same time, the DNS administrator 275 may configure it together. In case of that some children domain 276 names are delegated and not in the main domain name's zone, the 277 delegation information will be returned to the recursive resolvers. 278 The recursive resolvers then check the children domain based on the 279 delegation information, and get the answer for the respective 280 children domain names. 282 When a stub resolver sends an AQ query to the recursive resolver, the 283 recursive resolver may have some answers for one or more questions in 284 the cache, but not for all questions. Under that case, the recursive 285 resolver SHOULD forward this AQ query to some relative authoritative 286 servers for full answers instead of using the existing insufficient 287 cache information. 289 An AQ unaware responder is expected to ignore the AQ OPT of the 290 query, and may echo the received OPT back into additional section of 291 the response message. 293 5. Initiator Processing 295 An AQ aware initiator will put the main question into the question 296 section of the DNS query packet, and put each accompanying question 297 into the related accompanying question fields of OPTION-DATA of OPT 298 RR. AQ-RCODE value will be sent as 111111110100 bits. The AQ-TYPE 299 value should be set as the query type related to accompanying 300 questions. The Prefix value should be set as a dot or a sequence of 301 labels ending with a pointer pointing to the the main domain name of 302 the main question for the respective accompanying domain name of the 303 accompanying question. 305 An AQ aware initiator SHOULD set the limitation of what is the 306 maximum number of accompanying questions a AQ query can bring. This 307 document suggests that the maximum number is six since most DNS 308 resource records which need parallel query will not larger than six. 309 The implementers may set six as the defaul value in the 310 implementation. The responder can refuse to answer the AQ query if 311 the maximum number of the accompanying questions is larger than the 312 default maximum value, and return "not been implemented, too many 313 accompanying-questions." information to the initiator. 315 If the initial value of the AQ-RCODE is unchanged in the response or 316 the AQ OPT is not echo back, it indicates that the responder is AQ 317 unaware. In that case, the responder will deal with the main 318 question only. The initiator should sent the accompanying questions 319 one by one via the normal DNS query. In such followup related 320 queries, AQ processing should probably not be attempted, to reduce 321 waste of network resources. 323 6. Query and Response Example 325 Example: one main question with 2 accompanying questions 327 The query would look like: 329 +---------------------------------------------------+ 330 Header | OPCODE=SQUERY | 331 +---------------------------------------------------+ 332 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 333 +---------------------------------------------------+ 335 Answer | | 336 +---------------------------------------------------+ 337 Authority | | 338 +---------------------------------------------------+ 339 Additional | | 340 | AQ-TYPE=AAAA,AQ-RCODE=111111110100, | 341 | Prefix=., | 342 | AQ-TYPE=TLSA,,AQ-RCODE=111111110100, | 343 | Prefix=_443._tcp., | 344 +---------------------------------------------------+ 346 The response from AQ aware responders would be: 348 +---------------------------------------------------+ 349 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 350 | ANCOUNT=3, ARCOUNT=1, NSCOUNT=0 | 351 +---------------------------------------------------+ 352 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 353 +---------------------------------------------------+ 354 Answer | example.com IN A 192.168.0.1 | 355 | example.com. IN AAAA 2001:cc8::1 | 356 | _443._tcp.example.com. IN TLSA | 357 | ( 3 0 0 30820307308201efa003020102020... ) | 358 +---------------------------------------------------+ 359 Authority | | 360 +---------------------------------------------------+ 361 Additional | | 362 | AQ-TYPE=AAAA, AQ-RCODE=NOERROR, AQ-ANCOUNT=1, | 363 | AQ-ARCOUNT=0, AQ-NSCOUNT=0, | 364 | Prefix=., | 365 | AQ-TYPE=TLSA, AQ-RCODE=NOERROR, AQ-ANCOUNT=1, | 366 | AQ-ARCOUNT=0, AQ-NSCOUNT=0, | 367 | Prefix=_443._tcp., | 368 +---------------------------------------------------+ 370 The response from AQ unaware responders would be: 372 +---------------------------------------------------+ 373 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 374 +---------------------------------------------------+ 375 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 376 +---------------------------------------------------+ 377 Answer | example.com. IN A 192.168.0.1 | 378 +---------------------------------------------------+ 379 Authority | | 380 +---------------------------------------------------+ 381 Additional | | 382 | AQ-TYPE=AAAA,AQ-RCODE=111111110100, | 383 | Prefix=., | 384 | AQ-TYPE=TLSA, AQ-RCODE=111111110100, | 385 | Prefix=_443._tcp., | 386 +---------------------------------------------------+ 388 7. IANA Considerations 390 IANA should allocate DNS EDNS0 Option Codes (OPT) following this 391 document. IANA should reserve RCODE with the value of 111111110100 392 bits for this document. 394 8. Security Considerations 396 TBD 398 9. Acknowledgements 400 The authors thank the members in DNSOP mailing list for helpful 401 discussions, and especially thank Kazunori Fujiwara, JINMEI Tatuya, 402 Bob Harold, Arnt Gulbrandsen, Olafur Gudmundsson and Stephane 403 Bortzmeyer for kind comments, suggestions and improvements for the 404 document. The authors also thanks Likun Zhang for helpful discussion 405 about some topics related to implementation. 407 10. Change History 409 RFC Editor: Please remove this section. 411 10.1. draft-yao-dnsop-accompanying-questions: Version 00 413 o A Mechanism for DNS query including one main question with several 414 accompanying questions 416 10.2. draft-yao-dnsop-accompanying-questions: Version 01 418 o Simpilfy the mechanism. 420 10.3. draft-yao-dnsop-accompanying-questions: Version 02 422 o Remove the AQ and Count bits, and add AQ-ANCOUNT AQ-ARCOUNT AQ- 423 NSCOUNT 425 10.4. draft-yao-dnsop-accompanying-questions: Version 03 427 o Improve the introduction and explains the motivation of this draft 429 10.5. draft-yao-dnsop-accompanying-questions: Version 04 431 o Improve the document 433 11. Normative References 435 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 436 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 437 . 439 [RFC1035] Mockapetris, P., "Domain names - implementation and 440 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 441 November 1987, . 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 449 DOI 10.17487/RFC5321, October 2008, 450 . 452 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 453 of Named Entities (DANE) Transport Layer Security (TLS) 454 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 455 2012, . 457 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 458 for DNS (EDNS(0))", STD 75, RFC 6891, 459 DOI 10.17487/RFC6891, April 2013, 460 . 462 Authors' Addresses 464 Jiankang Yao 465 CNNIC-Farsight Joint Laboratory 466 4 South 4th Street,Zhongguancun,Haidian District 467 Beijing, Beijing 100190 468 China 470 Phone: +86 10 5881 3007 471 Email: yaojk@cnnic.cn 472 Paul Vixie 473 CNNIC-Farsight Joint Laboratory 474 4 South 4th Street,Zhongguancun,Haidian District 475 Beijing, Beijing 100190 476 China 478 Phone: +1 650 489 7919 479 Email: vixie@fsi.io 481 Ning Kong 482 CNNIC 483 4 South 4th Street,Zhongguancun,Haidian District 484 Beijing, Beijing 100190 485 China 487 Phone: +86 10 5881 3147 488 Email: nkong@cnnic.cn 490 Xiaodong Li 491 CNNIC 492 4 South 4th Street,Zhongguancun,Haidian District 493 Beijing, Beijing 100190 494 China 496 Phone: +86 10 5881 3020 497 Email: xl@cnnic.cn