idnits 2.17.1 draft-fujiwara-dnsop-additional-answers-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2017) is 2371 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-dnsop-terminology-bis-07 ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) == Outdated reference: A later version (-08) exists of draft-bellis-dnsext-multi-qtypes-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Fujiwara 3 Internet-Draft JPRS 4 Intended status: Informational October 29, 2017 5 Expires: May 2, 2018 7 Returning additional answers in DNS responses 8 draft-fujiwara-dnsop-additional-answers-00 10 Abstract 12 This document proposes to document the ability to provide multiple 13 answers in single DNS response. For example, authoritative servers 14 may add a NSEC resource record or A/AAAA resource records of the 15 query name. This is especially useful as, in many cases, the entity 16 making the request has no a priori knowledge of what other questions 17 it will need to ask. It is already possible (an authoritative server 18 MAY already sends what it wants in the additional section). This 19 document does not propose any protocol changes, just explanations of 20 an already acceptable practice. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 2, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Returning multiple answers . . . . . . . . . . . . . . . . . 4 60 5. Possible additional answers . . . . . . . . . . . . . . . . . 4 61 6. Stub-Resolver Considerations . . . . . . . . . . . . . . . . 4 62 7. Use of Additional information . . . . . . . . . . . . . . . . 5 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 6 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 12.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Appendix A. Comparisons of multiple response proposals . . . . . 7 71 A.1. draft-wkumari-dnsop-multiple-responses . . . . . . . . . 7 72 A.2. draft-fujiwara-dnsop-additional-answers . . . . . . . . . 7 73 A.3. draft-bellis-dnsext-multi-qtypes . . . . . . . . . . . . 7 74 A.4. draft-yao-dnsop-accompanying-questions . . . . . . . . . 8 75 A.5. QDCOUNT>1 idea . . . . . . . . . . . . . . . . . . . . . 8 76 A.6. Comparison chart . . . . . . . . . . . . . . . . . . . . 8 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 [I-D.wkumari-dnsop-multiple-responses] proposes pseudo resource 82 record that controls resource records added into additional section. 83 It offers any combinations of owner names and record types that are 84 added into additional section. 86 In many cases, combinations are limited and DNS software developers 87 knows well. This document proposes that DNS server software 88 developers choose the combination of additional data. 90 By providing multiple answers in single response, authoritative name 91 servers can assist full-service resolvers in pre-populating their 92 cache before stub resolvers or other clients ask for the subsequent 93 queries. Apart from decreasing the latency for end users [RFC6555], 94 this also decreases the total number of queries that full-service 95 resolvers need to send and authoritative servers need to answer. 97 By providing NSEC/NSEC3 resource record that matches a query name, 98 validating resolvers can generate NODATA or NXDOMAIN responses with 99 Aggressive Use of DNSSEC-validated cache [RFC8198]. 101 Developers of DNS servers know end users' query patterns or full- 102 service resolvers' query patterns well. Authoritative DNS servers 103 may add any authoritative data in the additional section. For 104 example, QTYPE MX queries are followed by mail exchange hosts A/AAAA 105 queries. When an authoritative server receives a QTYPE MX query, 106 some implementations add mail exchange hosts A/AAAA resource records 107 in additional section if the authoritative server have authoritative 108 data of mail exchange hosts. 110 Other typical examples are A and AAAA, SRV and Target A/AAAA, TLSA RR 111 and corresponding server addresses. 113 This technique, described in this document, is purely an optimization 114 and enables authoritative servers to distribute some other related 115 answers that the client is likely to need along with an answer to the 116 original request. Users get a better experience, full-service 117 resolvers need to send less queries, authoritative servers have to 118 answer fewer queries, etc. 120 2. Background 122 The DNS specifications ([RFC1034], for instance section 4.3.2) allow 123 for supplemental information to be included in the "additional" 124 section of the DNS response, but in order to defeat cache poisoning 125 attacks most implementations either ignore or don't trust additional 126 records they didn't ask for. For more background, see [RFC2181]. 128 Some implementations add mail exchange A/AAAA resource records in MX 129 responses (an actual example is given in section 3.7.1 of [RFC1034]). 130 Some implementations add Target A/AAAA resource records in SRV 131 responses. 133 3. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 Many of the specialized terms used in this specification are defined 140 in DNS Terminology [RFC7719] and [I-D.ietf-dnsop-terminology-bis]. 142 Additional records: Additional records are records that the 143 authoritative nameserver has included in the Additional section. 145 4. Returning multiple answers 147 An authoritative nameserver MAY include any additional records that 148 help name resolution. These additional records are appended to the 149 additional section of the response. 151 To increase the probability that these extra data will actually be 152 useful for the resolver, it is suggested to send them only if: 154 o The query has DNSSEC OK bit set. 156 o The authoritative server is authoritative for the additional 157 records, and the records to be returned are DNSSEC signed. The 158 additional records contain RRSIGs. 160 o To prove the non-existence of the resource record type, additional 161 records may be NSEC/NSEC3 resource records for the query name and 162 some other query names (for example, TLSA owner name). Validating 163 resolvers can generate negative NODATA/NXDOMAIN response with 164 Aggressive Use of DNSSEC-validated cache [RFC8198]. 166 o Responses with additional records fit in the required response 167 size. 169 5. Possible additional answers 171 Possible query and additional records pairs are: 173 o NAME A : NAME AAAA (or NAME NSEC/NSEC3) 175 o NAME AAAA : NAME A (or NAME NSEC/NSEC3) 177 o NAME MX : mail exchange A/AAAA (and/or mail exchange NSEC/NSEC3) 179 o NAME SRV : Target host A/AAAA (and/or Target host NSEC/NSEC3) 181 o NAME A/AAAA : _443._tcp.NAME TLSA (and/or NAME NSEC/NSEC3) 183 o _443._tcp.NAME TLSA : NAME A/AAAA (and/or NAME NSEC/NSEC3) 185 TLSA / MX / SRV pairs have different query names. 187 6. Stub-Resolver Considerations 189 No modifications need to be made to stub-resolvers to get the 190 predominate benefit of this protocol, since the majority of the speed 191 gain will take place between the validating recursive resolver and 192 the authoritative name server. However, stub resolvers and full- 193 service resolvers may use this technique if stub-resolvers are 194 validating stub resolvers. 196 7. Use of Additional information 198 When deciding to use additional records in the additional section, a 199 resolver should follow certain rules: 201 o Additional records are validated before being used. 203 o Additional records SHOULD have lower priority in the cache than 204 answers received because they were requested. This is to help 205 evict Additional records from the cache first (to help prevent 206 cache filling attacks). 208 o Recursive resolvers MAY choose to ignore Additional records for 209 any reason, including CPU or cache space concerns, phase of the 210 moon, etc. It may choose to accept all, some or none of the 211 Additional record sets. 213 o Recursive resolvers SHOULD support "Aggressive use of DNSSEC- 214 validated cache" [RFC8198]. 216 These rules are derived from [RFC2181] and DNSSEC RFCs. 218 8. IANA Considerations 220 This document has no IANA actions. 222 9. Security Considerations 224 The use of DNSSEC guarantees that these additional records will be 225 accepted and cached by the resolver only if they can be proved 226 genuine. 228 The technique described in this document makes DNS response size 229 large. If DNS response size exceeds path MTU, the response will be 230 fragmented and the fragmentation may cause problems. Authoritative 231 DNS server software developers and operators need to choose suitable 232 response size limit. 234 10. Acknowledgments 236 The author acknowledges authors of 237 [I-D.wkumari-dnsop-multiple-responses] because many part of idea and 238 texts are copied from the draft. 240 The author would like to specifically thank Stephane Bortzmeyer for 241 extensive review and comments. 243 11. Change History 245 12. References 247 12.1. Normative References 249 [I-D.ietf-dnsop-terminology-bis] 250 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 251 Terminology", draft-ietf-dnsop-terminology-bis-07 (work in 252 progress), October 2017. 254 [I-D.wkumari-dnsop-multiple-responses] 255 Kumari, W., Yan, Z., Hardaker, W., and D. Lawrence, 256 "Returning extra answers in DNS responses.", draft- 257 wkumari-dnsop-multiple-responses-05 (work in progress), 258 July 2017. 260 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 261 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 262 . 264 [RFC1035] Mockapetris, P., "Domain names - implementation and 265 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 266 November 1987, . 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, 270 DOI 10.17487/RFC2119, March 1997, . 273 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 274 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 275 . 277 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 278 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 279 2012, . 281 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 282 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 283 2015, . 285 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 286 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 287 July 2017, . 289 12.2. Informative References 291 [I-D.bellis-dnsext-multi-qtypes] 292 Bellis, R., "DNS Multiple QTYPEs", draft-bellis-dnsext- 293 multi-qtypes-04 (work in progress), July 2017. 295 [I-D.yao-dnsop-accompanying-questions] 296 Yao, J., Vixie, P., Kong, N., and X. Lee, "A DNS Query 297 including A Main Question with Accompanying Questions", 298 draft-yao-dnsop-accompanying-questions-04 (work in 299 progress), September 2017. 301 Appendix A. Comparisons of multiple response proposals 303 A.1. draft-wkumari-dnsop-multiple-responses 305 [I-D.wkumari-dnsop-multiple-responses] proposes pseudo resource 306 record that controls resource records added into additional section. 308 No protocol changes between authoritative servers and full-service 309 resolvers. New authoritative server software required. Zone 310 operators need to configure. Supports different owner names and 311 types. Answer size becomes large if the query matches operators 312 configuration. Requires DNSSEC. 314 A.2. draft-fujiwara-dnsop-additional-answers 316 draft-fujiwara-dnsop-additional-answers proposes that authoritative 317 servers add well used additional records and NSEC/NSEC3 resource 318 records in additional section. 320 No protocol changes between authoritative servers and full-service 321 resolvers. New authoritative server software required. No 322 configuration. Supports different owner names and types. Answer 323 size becomes large (always). Requires DNSSEC and [RFC8198]. 325 A.3. draft-bellis-dnsext-multi-qtypes 327 [I-D.bellis-dnsext-multi-qtypes] proposes new EDNS options that carry 328 additional query types. 330 New authoritative server software required. New full-service 331 resolver software required. No configuration. No support of 332 different owner names. 334 A.4. draft-yao-dnsop-accompanying-questions 336 [I-D.yao-dnsop-accompanying-questions] proposes new EDNS option that 337 carry additional query names, query types and rcodes. 339 New authoritative server software required. New full-service 340 resolver software required. No configuration. 342 A.5. QDCOUNT>1 idea 344 No drafts. QDCOUNT is not limited to 1 in [RFC1035]. 346 No protocol changes between authoritative servers and full-service 347 resolvers, however, some implementations (For example, BIND 9, NSD, 348 Unbound) treats QDCOUNT>1 as FORMERR. New authoritative server 349 software required. New full-service resolver software required. 350 Supports different owner names and types, however, it cannot answer 351 different rcodes. No configuration. A database that each IP address 352 support QDCOUNT>1 is required in full-service resolvers. 354 A.6. Comparison chart 356 ------------------+---------+----------+----------+----------+--------- 357 Draft | wkumari | fujiawra | bellis | yao |QDCOUNT>1 358 ------------------+---------+----------+----------+----------+--------- 359 Protocol change | No | No | Yes | Yes | Yes 360 New Auth soft | Yes | Yes | Yes | Yes | Yes 361 code size | some | little | large? | large? | large? 362 New Resolver soft | No | No | Required | Required | Required 363 Config complexity | Yes | No | No | No | No 364 Multiple names | Yes | Yes | No | Yes | maybe 365 Multiple types | Yes | Yes | Yes | Yes | Yes 366 Multiple rcodes | --- | --- | need not | Yes | No 367 Require DNSSEC | (Yes) | (Yes) | No | No | No 368 Response fat if | config | always | query | query | query 369 Stub support ? | No | No | possible | possible | possible 370 IP addr Database | No | No | EDNS | EDNS | New 371 Deploy? | Easy | Easy | Yes? | Yes? | No? 372 ------------------+---------+----------+----------+----------+--------- 374 Author's Address 375 Kazunori Fujiwara 376 Japan Registry Services Co., Ltd. 377 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 378 Chiyoda-ku, Tokyo 101-0065 379 Japan 381 Phone: +81 3 5215 8451 382 Email: fujiwara@jprs.co.jp