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