idnits 2.17.1 draft-ietf-dnsop-rfc7816bis-10.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 389 has weird spacing: '...ple.org exam...' == Line 406 has weird spacing: '...ple.org exam...' -- The document date (July 2, 2021) is 1019 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) ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7816 (Obsoleted by RFC 9156) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Obsoletes: 7816 (if approved) R. Dolmans 5 Intended status: Standards Track NLnet Labs 6 Expires: January 3, 2022 P. Hoffman 7 ICANN 8 July 2, 2021 10 DNS Query Name Minimisation to Improve Privacy 11 draft-ietf-dnsop-rfc7816bis-10 13 Abstract 15 This document describes a technique called "QNAME minimisation" to 16 improve DNS privacy, where the DNS resolver no longer always sends 17 the full original QNAME and original QTYPE to the upstream name 18 server. This document obsoletes RFC 7816. 20 This document is part of the IETF DNSOP (DNS Operations) Working 21 Group. The source of the document, as well as a list of open issues, 22 is at 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 3, 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction and Background . . . . . . . . . . . . . . . . . 2 59 1.1. Experience From RFC 7816 . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Description of QNAME Minimisation . . . . . . . . . . . . . . 4 62 2.1. QTYPE Selection . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. QNAME Selection . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Limit Number of Queries . . . . . . . . . . . . . . . . . 5 65 2.4. Stub and Forwarding Resolvers . . . . . . . . . . . . . . 7 66 3. Algorithm to Perform QNAME Minimisation . . . . . . . . . . . 7 67 4. QNAME Minimisation Examples . . . . . . . . . . . . . . . . . 8 68 5. Performance Considerations . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 7.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Changes from RFC 7816 . . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction and Background 79 The problem statement for this document is described in [RFC7626]. 80 This specific solution is not intended to fully solve the DNS privacy 81 problem; instead, it should be viewed as one tool amongst many. 83 QNAME minimisation follows the principle explained in Section 6.1 of 84 [RFC6973]: the less data you send out, the fewer privacy problems 85 you have. 87 Before QNAME minimisation, when a resolver received the query "What 88 is the AAAA record for www.example.com?", it sent to the root 89 (assuming a resolver whose cache is empty) the very same question. 90 Sending the full QNAME to the authoritative name server was a 91 tradition, not a protocol requirement. In a conversation with one of 92 the authors in January 2015, Paul Mockapetris explained that this 93 tradition comes from a desire to optimise the number of requests, 94 when the same name server is authoritative for many zones in a given 95 name (something that was more common in the old days, where the same 96 name servers served .com and the root) or when the same name server 97 is both recursive and authoritative (something that is strongly 98 discouraged now). Whatever the merits of this choice at this time, 99 the DNS is quite different now. 101 QNAME minimisation is compatible with the current DNS system and 102 therefore can easily be deployed. Because it is only a change to the 103 way that the resolver operates, it does not change the DNS protocol 104 itself. The behaviour suggested here (minimising the amount of data 105 sent in QNAMEs from the resolver) is allowed by Section 5.3.3 of 106 [RFC1034] and Section 7.2 of [RFC1035]. 108 1.1. Experience From RFC 7816 110 This document obsoletes [RFC7816]. RFC 7816 was labelled 111 "experimental", but ideas from it were widely deployed since its 112 publication. Many resolver implementations now support QNAME 113 minimisation. The lessons learned from implementing QNAME 114 minimisation were used to create this new revision. 116 Data from DNSThought [dnsthought-qnamemin], Verisign 117 [verisign-qnamemin] and APNIC [apnic-qnamemin] shows that a large 118 percentage of the resolvers deployed on the Internet already support 119 QNAME minimisation in some way. 121 Academic research has been performed on QNAME minimisation 122 [devries-qnamemin]. This work shows that QNAME minimisation in 123 relaxed mode causes almost no problems. The paper recommends using 124 the A QTYPE, and limiting the number of queries in some way. Some of 125 the issues that the paper found are covered in Section 5. 127 1.2. Terminology 129 The terminology used in this document is defined in [RFC8499]. 131 In this document, a "cold" cache is one that is empty, having 132 literally no entries in it. A "warm" cache is one that has some 133 entries in it. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 2. Description of QNAME Minimisation 143 The idea behind QNAME minimisation is to minimise the amount of 144 privacy sensitive data sent from the DNS resolver to the 145 authoritative name server. This section describes how to do QNAME 146 minimisation. The algorithm is summarised in Section 3. 148 When a resolver is not able to answer a query from cache it has to 149 send a query to an authoritative nameserver. Traditionally these 150 queries would contain the full QNAME and the original QTYPE as 151 received in the client query. 153 The full QNAME and original QTYPE are only needed at the nameserver 154 that is authoritative for the record requested by the client. All 155 other nameservers queried while resolving the query only need to 156 receive enough of the QNAME to be able to answer with a delegation. 157 The QTYPE in these queries is not relevant, as the nameserver is not 158 able to authoritatively answer the records the client is looking for. 159 Sending the full QNAME and original QTYPE to these nameservers 160 therefore exposes more privacy sensitive data than necessary to 161 resolve the client's request. 163 A resolver that implements QNAME minimisation obscures the QNAME and 164 QTYPE in queries directed to an authoritative nameserver that is not 165 known to be responsible for the original QNAME. These queries 166 contain: 168 o a QTYPE selected by the resolver to possibly obscure the original 169 QTYPE 171 o the QNAME that is the original QNAME, stripped to just one label 172 more than the longest matching domain name for which the 173 nameserver is known to be authoritative 175 2.1. QTYPE Selection 177 Note that this document relaxes the recommendation in RFC 7816 to use 178 the NS QTYPE to hide the original QTYPE. Using the NS QTYPE is still 179 allowed. The authority of NS records lies at the child side. The 180 parent side of the delegation will answer using a referral, like it 181 will do for queries with other QTYPEs. Using the NS QTYPE therefore 182 has no added value over other QTYPEs. 184 The QTYPE to use while minimising queries can be any possible data 185 type (as defined in [RFC6895] Section 3.1) for which the authority 186 always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG, 187 TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no 188 relation between the incoming QTYPE and the selection of the QTYPE to 189 use while minimising. A good candidate is to always use the "A" 190 QTYPE because this is the least likely to raise issues in DNS 191 software and middleboxes that do not properly support all QTYPEs. 192 The QTYPE=A queries will also blend into traffic from non-minimising 193 resolvers, making it in some cases harder to observe that the 194 resolver is using QNAME minimisation. Using the QTYPE that occurs 195 most in incoming queries will slightly reduce the number of queries, 196 as there is no extra check needed for delegations on non-apex 197 records. Another potential benefit of using QTYPE=A is that 198 [RFC8305] clients that need answers for both the A and AAAA types 199 will send the AAAA query first. When minimising using QTYPE=A the 200 minimised query might be useful, and now already in the cache, for 201 the happy eyeballs query for the A QTYPE. 203 2.2. QNAME Selection 205 The minimising resolver works perfectly when it knows the zone cut 206 (zone cuts are described in Section 6 of [RFC2181]). But zone cuts 207 do not necessarily exist at every label boundary. In the name 208 www.foo.bar.example, it is possible that there is a zone cut between 209 "foo" and "bar" but not between "bar" and "example". So, assuming 210 that the resolver already knows the name servers of example, when it 211 receives the query "What is the AAAA record of www.foo.bar.example?", 212 it does not always know where the zone cut will be. To find the 213 zone cut, it will query the example name servers for a record for 214 bar.example. It will get a non-referral answer, it has to query the 215 example name servers again with one more label, and so on. 216 (Section 3 describes this algorithm in deeper detail.) 218 2.3. Limit Number of Queries 220 When using QNAME minimisation, the number of labels in the received 221 QNAME can influence the number of queries sent from the resolver. 222 This opens an attack vector and can decrease performance. Resolvers 223 supporting QNAME minimisation MUST implement a mechanism to limit the 224 number of outgoing queries per user request. 226 Take for example an incoming QNAME with many labels, like 227 www.host.group.department.example.com, where 228 host.group.department.example.com is hosted on example.com's 229 name servers. (Such deep domains are especially common under 230 ip6.arpa.) Assume a resolver that knows only the name servers of 231 example.com. Without QNAME minimisation, it would send these 232 example.com name servers a query for 233 www.host.group.department.example.com and immediately get a specific 234 referral or an answer, without the need for more queries to probe for 235 the zone cut. For such a name, a cold resolver with QNAME 236 minimisation will send more queries, one per label. Once the cache 237 is warm, there will be less difference with a traditional resolver. 238 Testing of this is described in [Huque-QNAME-Min]. 240 The behaviour of sending multiple queries can be exploited by sending 241 queries with a large number of labels in the QNAME that will be 242 answered using a wildcard record. Take for example a record for 243 *.example.com, hosted on example.com's name servers. An incoming 244 query containing a QNAME with more than 100 labels, ending in 245 example.com, will result in a query per label. By using random 246 labels, the attacker can bypass the cache and always require the 247 resolver to send many queries upstream. Note that [RFC8198] can 248 limit this attack in some cases. 250 One mechanism that MAY be used to reduce this attack vector is by 251 appending more than one label per iteration for QNAMEs with a large 252 number of labels. To do this, a maximum number of QNAME minimisation 253 iterations MUST be selected (MAX_MINIMISE_COUNT); a RECOMMENDED value 254 is 10. Optionally, a value for the number of queries that should 255 only have one label appended MAY be selected (MINIMISE_ONE_LAB), a 256 good value is 4. The assumption here is that the number of labels on 257 delegations higher in the hierarchy are rather small, therefore not 258 exposing too many labels early on has the most privacy benefit. 260 Another potential, optional mechanism for limiting the number of 261 queries is to assume that labels that begin with an underscore (_) 262 character do not represent privacy-relevant administrative 263 boundaries. For example, if the QNAME is "_25._tcp.mail.example.org" 264 and the algorithm has already searched for "mail.example.org", the 265 next query can be for all the underscore-prefixed names together, 266 namely "_25._tcp.mail.example.org". 268 When a resolver needs to send out a query, it will look for the 269 closest known delegation point in its cache. The number of not yet 270 exposed labels is the difference between this closest nameserver and 271 the incoming QNAME. The first MINIMISE_ONE_LAB labels will be 272 handled as described in Section 2. The number of labels that are 273 still not exposed now need to be divided proportionally over the 274 remaining iterations (MAX_MINIMISE_COUNT - MINIMISE_ONE_LAB). If the 275 not yet exposed labels can not be equally divided over the remaining 276 iterations, the remainder of the division should be added to the last 277 iterations. For example, when resolving a QNAME with 18 labels with 278 MAX_MINIMISE_COUNT set to 10 and MINIMISE_ONE_LAB set to 4, the 279 number of labels added per iteration are: 1,1,1,1,2,2,2,2,3,3. 281 2.4. Stub and Forwarding Resolvers 283 Stub and forwarding resolvers MAY implement QNAME minimisation. 284 Minimising queries that will be sent to an upstream resolver does not 285 help in hiding data from the upstream resolver because all 286 information will end up there anyway. It might, however, limit the 287 data exposure between the upstream resolver and the authoritative 288 nameserver in the situation where the upstream resolver does not 289 support QNAME minimisation. Using QNAME minimisation in a stub or 290 forwarding resolvers that does not have a mechanism to find and cache 291 zone cuts will drastically increase the number of outgoing queries. 293 3. Algorithm to Perform QNAME Minimisation 295 This algorithm performs name resolution with QNAME minimisation in 296 the presence of zone cuts that are not yet known. 298 Although a validating resolver already has the logic to find the 299 zone cuts, implementers of resolvers may want to use this algorithm 300 to locate the zone cuts. 302 (0) If the query can be answered from the cache, do so; otherwise, 303 iterate as follows: 305 (1) Get the closest delegation point that can be used for the 306 original QNAME from the cache. 308 (1a) For queries with a QTYPE for which the authority only lies 309 at the parent side (like QTYPE=DS) this is the NS RRset with 310 the owner matching the most labels with QNAME stripped by 311 one label. QNAME will be a subdomain of (but not equal to) 312 this NS RRset. Call this ANCESTOR. 314 (1b) For queries with other original QTYPEs this is the NS RRset 315 with the owner matching the most labels with QNAME. QNAME 316 will be equal to or a subdomain of this NS RRset. Call this 317 ANCESTOR. 319 (2) Initialise CHILD to the same as ANCESTOR. 321 (3) If CHILD is the same as QNAME, or if CHILD is one label shorter 322 than QNAME and the original QTYPE can only be at the parent side 323 (like QTYPE=DS), resolve the original query as normal starting 324 from ANCESTOR's name servers. Start over from step 0 if new 325 names need to be resolved as result of this answer, for example 326 when the answer contains a CNAME or DNAME record. 328 (4) Otherwise, add the next relevant label or labels from QNAME to 329 the start of CHILD. The number of labels to add is discussed in 330 Section 2.3. 332 (5) Look for a cache entry for the RRset at CHILD with the original 333 QTYPE. If the cached response code is NXDOMAIN and the resolver 334 has support for [RFC8020], the NXDOMAIN can be used in response 335 to the original query, and stop. If the cached response code is 336 NOERROR (including NODATA), go back to step 3. If the cached 337 response code is NXDOMAIN and the resolver does not support RFC 338 8020, go back to step 3. 340 (6) Query for CHILD with the selected QTYPE using one of ANCESTOR's 341 name servers. The response can be: 343 (6a) A referral. Cache the NS RRset from the authority section, 344 and go back to step 1. 346 (6b) A DNAME response. Proceed as if a DNAME is received for the 347 original query. Start over from step 0 to resolve the new 348 name based on the DNAME target. 350 (6c) All other NOERROR answers (including NODATA). Cache this 351 answer. Regardless of the answered RRset type, including 352 CNAMEs, continue with the algorithm from step 3 by building 353 the original QNAME. 355 (6d) An NXDOMAIN response. If the resolver supports RFC8020, 356 return an NXDOMAIN response to the original query and stop. 357 If the resolver does not support RFC8020, go to step 3. 359 (6e) A timeout or response with another RCODE. The 360 implementation may choose to retry step (6) with a different 361 ANCESTOR name server. 363 4. QNAME Minimisation Examples 365 Assume that a resolver receives a request to resolve 366 foo.bar.baz.example. Assume that the resolver already knows that 367 ns1.nic.example is authoritative for .example, and that the resolver 368 does not know a more specific authoritative name server. It will 369 send the query with QNAME=baz.example and the QTYPE selected to hide 370 the original QTYPE to ns1.nic.example. 372 Here are more detailed examples of other queries with QNAME 373 minimisation, using other names and authoritative servers: 375 Cold cache, traditional resolution algorithm without QNAME 376 minimisation, request for MX record of a.b.example.org: 378 QTYPE QNAME TARGET NOTE 379 MX a.b.example.org root nameserver 380 MX a.b.example.org org nameserver 381 MX a.b.example.org example.org nameserver 383 Cold cache, with QNAME minimisation, request for MX record of 384 a.b.example.org, using the A QTYPE to hide the original QTYPE: 386 QTYPE QNAME TARGET NOTE 387 A org root nameserver 388 A example.org org nameserver 389 A b.example.org example.org nameserver 390 A a.b.example.org example.org nameserver "a" may be delegated 391 MX a.b.example.org example.org nameserver 393 Note that in above example one query would have been saved if the 394 incoming QTYPE would have been the same as the QTYPE selected by the 395 resolver to hide the original QTYPE. Only one query for 396 a.b.example.org would have been needed if the original QTYPE would 397 have been A. Using the most used QTYPE to hide the original QTYPE 398 therefore slightly reduces the number of outgoing queries. 400 Warm cache with only org delegation known, (example.org's NS RRset is 401 not known), request for MX record of a.b.example.org, using A QTYPE 402 to hide the original QTYPE: 404 QTYPE QNAME TARGET NOTE 405 A example.org org nameserver 406 A b.example.org example.org nameserver 407 A a.b.example.org example.org nameserver "a" may be delegated 408 MX a.b.example.org example.org nameserver 410 5. Performance Considerations 412 The main goal of QNAME minimisation is to improve privacy by sending 413 less data. However, it may have other advantages. For instance, if 414 a resolver sends a root name server queries for A.example followed by 415 B.example followed by C.example, the result will be three NXDOMAINs, 416 since .example does not exist in the root zone. When using QNAME 417 minimisation, the resolver would send only one question (for .example 418 itself) to which they could answer NXDOMAIN. The resolver can cache 419 this answer and use it as to prove that nothing below .example exists 420 ([RFC8020]). A resolver now knows a priori that neither B.example 421 nor C.example exist. Thus, in this common case, the total number of 422 upstream queries under QNAME minimisation could counterintuitively be 423 less than the number of queries under the traditional iteration (as 424 described in the DNS standard). 426 QNAME minimisation can increase the number of queries based on the 427 incoming QNAME. This is described in Section 2.3. As described in 428 [devries-qnamemin], QNAME minimisation in strict mode both increases 429 the number of DNS lookups by up to 26% and leads to up to 5% more 430 failed lookups. The full cache in a production resolver will soften 431 that overhead. 433 6. Security Considerations 435 QNAME minimisation's benefits are clear in the case where you want to 436 decrease exposure to the authoritative name server. But minimising 437 the amount of data sent also, in part, addresses the case of a wire 438 sniffer as well as the case of privacy invasion by the servers. 439 (Encryption is of course a better defense against wire sniffers, but, 440 unlike QNAME minimisation, it changes the protocol and cannot be 441 deployed unilaterally. Also, the effect of QNAME minimisation on 442 wire sniffers depends on whether the sniffer is on the DNS path.) 444 QNAME minimisation offers no protection against the recursive 445 resolver, which still sees the full request coming from the stub 446 resolver. 448 A resolver using QNAME minimisation can possibly be used to cause a 449 query storm to be sent to servers when resolving queries containing a 450 QNAME with a large number of labels, as described in Section 2.3. 451 That section proposes methods to significantly dampen the effects of 452 such attacks. 454 7. References 456 7.1. Normative References 458 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 459 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 460 . 462 [RFC1035] Mockapetris, P., "Domain names - implementation and 463 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 464 November 1987, . 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 472 Morris, J., Hansen, M., and R. Smith, "Privacy 473 Considerations for Internet Protocols", RFC 6973, 474 DOI 10.17487/RFC6973, July 2013, 475 . 477 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 478 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 479 . 481 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 482 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 483 May 2017, . 485 7.2. Informative References 487 [apnic-qnamemin] 488 Huston, G. and J. Damas, "Measuring Query Name 489 Minimization", September 2020, . 494 [devries-qnamemin] 495 "A First Look at QNAME Minimization in the Domain Name 496 System", March 2019, 497 . 500 [dnsthought-qnamemin] 501 "DNSThought QNAME minimisation results. Using Atlas 502 probes", March 2020, 503 . 505 [Huque-QNAME-Min] 506 Huque, S., "Query name minimization and authoritative 507 server behavior", May 2015, 508 . 510 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 511 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 512 . 514 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 515 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 516 April 2013, . 518 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 519 DOI 10.17487/RFC7626, August 2015, 520 . 522 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 523 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 524 November 2016, . 526 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 527 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 528 July 2017, . 530 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 531 Better Connectivity Using Concurrency", RFC 8305, 532 DOI 10.17487/RFC8305, December 2017, 533 . 535 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 536 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 537 January 2019, . 539 [verisign-qnamemin] 540 Thomas, M., "Maximizing Qname Minimization: A New Chapter 541 in DNS Protocol Evolution", September 2020, 542 . 545 Acknowledgments 547 The acknowledgements from RFC 7816 apply here. In addition, many 548 participants from the DNSOP Working Group helped with proposals for 549 simplification, clarification, and general editorial help. 551 Changes from RFC 7816 553 Changed in -07 555 o Stopped using the term "aggressive" for the method described 557 o Clarified some terminology 559 o More reorganization 561 Changed in -06 563 o Removed lots of text from when this was experimental 565 o Lots of reorganization 566 Changed in -04 568 o Start structure for implementation section 570 o Add clarification why the used QTYPE does not matter 572 o Make algorithm DS QTYPE compatible 574 Changed in -03 576 o Drop recommendation to use the NS QTYPE to hide the incoming QTYPE 578 o Describe DoS attach vector for QNAME with large number of labels, 579 and propose a mitigation. 581 o Simplify examples and change qname to a.b.example.com to show the 582 change in number of queries. 584 Changed in -00, -01, and -02 586 o Made changes to deal with errata #4644 588 o Changed status to be on standards track 590 o Major reorganization 592 Authors' Addresses 594 Stephane Bortzmeyer 595 AFNIC 596 1, rue Stephenson 597 Montigny-le-Bretonneux 78180 598 France 600 Phone: +33 1 39 30 83 46 601 Email: bortzmeyer+ietf@nic.fr 602 URI: https://www.afnic.fr/ 604 Ralph Dolmans 605 NLnet Labs 607 Email: ralph@nlnetlabs.nl 608 Paul Hoffman 609 ICANN 611 Email: paul.hoffman@icann.org