idnits 2.17.1 draft-yao-dnsop-accompanying-questions-01.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 271 has weird spacing: '...ponders would...' == 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 24, 2016) is 2741 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 89, but not defined == Unused Reference: 'RFC5321' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 337, but no explicit reference was found in the text Summary: 1 error (**), 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: April 27, 2017 N. Kong 6 X. Li 7 CNNIC 8 October 24, 2016 10 A DNS Query including A Main Question with Accompanying Questions 11 draft-yao-dnsop-accompanying-questions-01 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 April 27, 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 . . . . . . . . . . . . . . . . . . . . 5 72 6. Query and Response Example . . . . . . . . . . . . . . . . . 6 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 76 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 7 77 10.1. draft-yao-dnsop-accompanying-questions: Version 00 . . . 7 78 10.2. draft-yao-dnsop-accompanying-questions: Version 01 . . . 7 79 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 There are many scenarios in which an application must send several 85 related questions to a DNS responder. For examples, when asking 86 about a QTYPE=A RRset, a QTYPE=AAAA RRset may also be of use [RFC 87 5321]; When asking for some RRset of www.example.com about A and 88 AAAA, records of a sub-domain name such as _443._tcp.www.example.com 89 for TLSA may be of interest[RFC 6698]. 91 Query example.com for A and AAAA 93 Query www.example.com for A and AAAA, and _443._tcp.www.example.com 94 for TLSA 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 The variable part of an OPT RR is encoded in its RDATA and is 118 structured as the following: 120 +0 (MSB) +1 (LSB) 121 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 122 0: | OPTION-CODE | 123 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 124 2: | OPTION-LENGTH | 125 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 126 4: | | 127 / OPTION-DATA / 128 / / 129 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 131 OPTION-CODE (Assigned by IANA.) 133 OPTION-LENGTH Size (in octets) of OPTION-DATA. 135 OPTION-DATA including at most 8 accompanying questions with AQ-RCODE. 137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 138 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 139 |AQ | Count | AQ-RCODE | 140 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 141 | AQ-TYPE | 142 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 143 | | 144 / Prefix / 145 / / 146 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 147 |AQ | Seq | AQ-RCODE | 148 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 149 | AQ-TYPE | 150 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 151 | | 152 / Prefix / 153 / / 154 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 155 |AQ | Seq | AQ-RCODE | 156 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 157 | AQ-TYPE | 158 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 159 | | 160 / Prefix / 161 / / 162 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 163 | | 164 / ...... / 165 / / 167 o AQ field indicates whether this accompanying question is the first 168 question. If it is set as 1, this question is the first question. 170 o Count field represents the total numbers of all accompanying 171 questions. Seq field represents the sequence number of 172 accompanying questions from 1 to 7 There will have at most 8 173 accompanying questions. 175 o AQ-RCODE field will be set to 111111110100 bits when being 176 initialized. The AQ-RCODE with the value of 111111110100 bits 177 means that the mechanism for accompanying has not been 178 implemented, where "0100" in the RCODE value is "not been 179 implemented". The AQ aware responders will put the RCODE value 180 for the query of this question into AQ-RCODE fields. 182 o Prefix field is a substring between the main domain name of the 183 main quesiton and the accompanying domain name of the accompanying 184 question. That is, if the main domain name is string S and the 185 accompanying domain name is string S1, the prefix is (S-S1). For 186 an example, if the main domain name is example.com and the 187 accompanying domain name is mail.example.com, the prefix is 188 "mail.". 190 4. Responder Processing 192 The AQ aware responder will check the main question first, and put 193 the results into the DNS response packet. If the AQ OPT is present, 194 the responder assembles the prefix with the main domain name and make 195 it to be an accompanying question, checks the accompanying questions 196 in order, and put the results into the DNS answer section of the 197 response following RFC 1034; but the response code is placed in the 198 respective AQ-RCODE field in AQ OPT of the response. The RCODE field 199 in the DNS response header refers to the main question only. An AQ 200 unaware responder is expected to ignore the AQ OPT of the query, and 201 may echo the received OPT back into additional section of the 202 response message. 204 5. Initiator Processing 206 An AQ aware initiator will put the main question into the question 207 section of the DNS query packet, and put related accompanying 208 questions into the Accompanying Question fields of OPTION-DATA of OPT 209 RR. AQ-RCODE value will be sent as 111111110100 bits. The AQ value 210 should be set to 1 and Count value should be set to total number of 211 accompanying questions, if the accompanying question is the first 212 one; For the remain accompanying questions, the AQ value should be 213 set to 0 and Seq value should be set to the sequence of the 214 corresponding accompanying questions. The AQ-TYPE value should be 215 set as the query type related accomanying questions. The Prefix 216 should be set as the substring between the main domain name of the 217 main quesiton and the accompanying domain name of the accompanying 218 question. If the main domain name and the accompanying domain name 219 are same, the Prefix should be set as all zero bits. 221 If the initial value of the AQ-RCODE is unchanged in the response, it 222 indicates that the responder is AQ unaware. In that case, the 223 responder will deal with the main question only. The initiator 224 should sent the accompanying questions one by one via the normal DNS 225 query. In such followup related queries, AQ processing should 226 probably not be attempted, to reduce waste of network resources. 228 6. Query and Response Example 230 Example: one main question with 2 accompanying questions 232 The query would look like: 234 +---------------------------------------------------+ 235 Header | OPCODE=SQUERY | 236 +---------------------------------------------------+ 237 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 238 +---------------------------------------------------+ 239 Answer | | 240 +---------------------------------------------------+ 241 Authority | | 242 +---------------------------------------------------+ 243 Additional | | 244 | AQ=1,Count=2,AQ-TYPE=AAAA,AQ-RCODE=111111110100, | 245 | Prefix=0, | 246 | AQ=0, SEQ=1,AQ-TYPE=TLSA,,AQ-RCODE=111111110100, | 247 | Prefix=_443._tcp., | 248 +---------------------------------------------------+ 250 The response from AQ aware responders would be: 252 +---------------------------------------------------+ 253 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 254 +---------------------------------------------------+ 255 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 256 +---------------------------------------------------+ 257 Answer | example.com IN A 192.168.0.1 | 258 | example.com. IN AAAA 2001:cc8::1 | 259 | _443._tcp.example.com. IN TLSA | 260 | ( 3 0 0 30820307308201efa003020102020... ) | 261 +---------------------------------------------------+ 262 Authority | | 263 +---------------------------------------------------+ 264 Additional | | 265 | AQ=1, COUNT=2, AQ-TYPE=AAAA, AQ-RCODE=NOERROR, | 266 | Prefix=0, | 267 | AQ=0, SEQ=1, AQ-TYPE=TLSA, AQ-RCODE=NOERROR, | 268 | Prefix=443._tcp., | 269 +---------------------------------------------------+ 271 The response from AQ unaware responders would be: 273 +---------------------------------------------------+ 274 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NOERROR | 275 +---------------------------------------------------+ 276 Question | QNAME=EXAMPLE.COM., QCLASS=IN, QTYPE=A | 277 +---------------------------------------------------+ 278 Answer | example.com IN A 192.168.0.1 | 279 +---------------------------------------------------+ 280 Authority | | 281 +---------------------------------------------------+ 282 Additional | | 283 | AQ=1, COUNT=2, AQ-TYPE=AAAA,AQ-RCODE=111111110100,| 284 | Prefix=0, | 285 | AQ=0, SEQ=1, AQ-TYPE=TLSA, AQ-RCODE=111111110100, | 286 | Prefix=443._tcp., | 287 +---------------------------------------------------+ 289 7. IANA Considerations 291 IANA should allocate DNS EDNS0 Option Codes (OPT) following this 292 document. IANA should reserve RCODE with the value of 111111110100 293 bits for this document. 295 8. Security Considerations 297 TBD 299 9. Acknowledgements 301 The authors thank the members in DNSOP mailing list for helpful 302 discussions, and especially thank Kazunori Fujiwara for kind 303 comments, suggestions and improvments for the document. 305 10. Change History 307 RFC Editor: Please remove this section. 309 10.1. draft-yao-dnsop-accompanying-questions: Version 00 311 o A Mechanism for DNS query including one main question with several 312 accompanying questions 314 10.2. draft-yao-dnsop-accompanying-questions: Version 01 316 o Simpilfy the mechanism. 318 11. Normative References 320 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 321 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 322 . 324 [RFC1035] Mockapetris, P., "Domain names - implementation and 325 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 326 November 1987, . 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 334 DOI 10.17487/RFC5321, October 2008, 335 . 337 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 338 of Named Entities (DANE) Transport Layer Security (TLS) 339 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 340 2012, . 342 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 343 for DNS (EDNS(0))", STD 75, RFC 6891, 344 DOI 10.17487/RFC6891, April 2013, 345 . 347 Authors' Addresses 349 Jiankang Yao 350 CNNIC-Farsight Joint Laboratory 351 4 South 4th Street,Zhongguancun,Haidian District 352 Beijing, Beijing 100190 353 China 355 Phone: +86 10 5881 3007 356 Email: yaojk@cnnic.cn 357 Paul Vixie 358 CNNIC-Farsight Joint Laboratory 359 4 South 4th Street,Zhongguancun,Haidian District 360 Beijing, Beijing 100190 361 China 363 Phone: +1 650 489 7919 364 Email: vixie@fsi.io 366 Ning Kong 367 CNNIC 368 4 South 4th Street,Zhongguancun,Haidian District 369 Beijing, Beijing 100190 370 China 372 Phone: +86 10 5881 3147 373 Email: nkong@cnnic.cn 375 Xiaodong Li 376 CNNIC 377 4 South 4th Street,Zhongguancun,Haidian District 378 Beijing, Beijing 100190 379 China 381 Phone: +86 10 5881 3020 382 Email: xl@cnnic.cn