idnits 2.17.1 draft-ietf-dnsop-rfc7816bis-09.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 379 has weird spacing: '...ple.org exam...' == Line 396 has weird spacing: '...ple.org exam...' -- The document date (30 April 2021) is 1085 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: 1 November 2021 P. Hoffman 7 ICANN 8 30 April 2021 10 DNS Query Name Minimisation to Improve Privacy 11 draft-ietf-dnsop-rfc7816bis-09 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 1 November 2021. 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Background . . . . . . . . . . . . . . . . . 2 58 1.1. Experience From RFC 7816 . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Description of QNAME Minimisation . . . . . . . . . . . . . . 4 61 2.1. QTYPE Selection . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. QNAME Selection . . . . . . . . . . . . . . . . . . . . . 5 63 2.3. Limit Number of Queries . . . . . . . . . . . . . . . . . 5 64 2.4. Stub and Forwarding Resolvers . . . . . . . . . . . . . . 7 65 3. Algorithm to Perform QNAME Minimisation . . . . . . . . . . . 7 66 4. QNAME Minimisation Examples . . . . . . . . . . . . . . . . . 8 67 5. Performance Considerations . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 7.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 Changes from RFC 7816 . . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction and Background 78 The problem statement for this document is described in [RFC7626]. 79 This specific solution is not intended to fully solve the DNS privacy 80 problem; instead, it should be viewed as one tool amongst many. 82 QNAME minimisation follows the principle explained in Section 6.1 of 83 [RFC6973]: the less data you send out, the fewer privacy problems 84 you have. 86 Before QNAME minimisation, when a resolver received the query "What 87 is the AAAA record for www.example.com?", it sent to the root 88 (assuming a resolver whose cache is empty) the very same question. 89 Sending the full QNAME to the authoritative name server was a 90 tradition, not a protocol requirement. In a conversation with one of 91 the authors in January 2015, Paul Mockapetris explained that this 92 tradition comes from a desire to optimise the number of requests, 93 when the same name server is authoritative for many zones in a given 94 name (something that was more common in the old days, where the same 95 name servers served .com and the root) or when the same name server 96 is both recursive and authoritative (something that is strongly 97 discouraged now). Whatever the merits of this choice at this time, 98 the DNS is quite different now. 100 QNAME minimisation is compatible with the current DNS system and 101 therefore can easily be deployed. Because it is only a change to the 102 way that the resolver operates, it does not change the DNS protocol 103 itself. The behaviour suggested here (minimising the amount of data 104 sent in QNAMEs from the resolver) is allowed by Section 5.3.3 of 105 [RFC1034] and Section 7.2 of [RFC1035]. 107 1.1. Experience From RFC 7816 109 This document obsoletes [RFC7816]. RFC 7816 was labelled 110 "experimental", but ideas from it were widely deployed since its 111 publication. Many resolver implementations now support QNAME 112 minimisation. The lessons learned from implementing QNAME 113 minimisation were used to create this new revision. 115 Data from DNSThought [dnsthought-qnamemin], Verisign 116 [verisign-qnamemin] and APNIC [apnic-qnamemin] shows that a large 117 percentage of the resolvers deployed on the Internet already support 118 QNAME minimisation in some way. 120 Academic research has been performed on QNAME minimisation 121 [devries-qnamemin]. This work shows that QNAME minimisation in 122 relaxed mode causes almost no problems. The paper recommends using 123 the A QTYPE, and limiting the number of queries in some way. Some of 124 the issues that the paper found are covered in Section 5. 126 1.2. Terminology 128 The terminology used in this document is defined in [RFC8499]. 130 In this document, a "cold" cache is one that is empty, having 131 literally no entries in it. A "warm" cache is one that has some 132 entries in it. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 2. Description of QNAME Minimisation 142 The idea behind QNAME minimisation is to minimise the amount of 143 privacy sensitive data sent from the DNS resolver to the 144 authoritative name server. This section describes how to do QNAME 145 minimisation. The algorithm is summarised in Section 3. 147 When a resolver is not able to answer a query from cache it has to 148 send a query to an authoritative nameserver. Traditionally these 149 queries would contain the full QNAME and the original QTYPE as 150 received in the client query. 152 The full QNAME and original QTYPE are only needed at the nameserver 153 that is authoritative for the record requested by the client. All 154 other nameservers queried while resolving the query only need to 155 receive enough of the QNAME to be able to answer with a delegation. 156 The QTYPE in these queries is not relevant, as the nameserver is not 157 able to authoritatively answer the records the client is looking for. 158 Sending the full QNAME and original QTYPE to these nameservers 159 therefore exposes more privacy sensitive data than necessary to 160 resolve the client's request. 162 A resolver that implements QNAME minimisation obscures the QNAME and 163 QTYPE in queries directed to an authoritative nameserver that is not 164 known to be responsible for the original QNAME. These queries 165 contain: 167 * a QTYPE selected by the resolver to possibly obscure the original 168 QTYPE 170 * the QNAME that is the original QNAME, stripped to just one label 171 more than the longest matching domain name for which the 172 nameserver is known to be authoritative 174 2.1. QTYPE Selection 176 Note that this document relaxes the recommendation in RFC 7816 to use 177 the NS QTYPE to hide the original QTYPE. Using the NS QTYPE is still 178 allowed. The authority of NS records lies at the child side. The 179 parent side of the delegation will answer using a referral, like it 180 will do for queries with other QTYPEs. Using the NS QTYPE therefore 181 has no added value over other QTYPEs. 183 The QTYPE to use while minimising queries can be any possible data 184 type (as defined in [RFC6895] Section 3.1) for which the authority 185 always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG, 186 TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no 187 relation between the incoming QTYPE and the selection of the QTYPE to 188 use while minimising. A good candidate is to always use the "A" 189 QTYPE because this is the least likely to raise issues in DNS 190 software and middleboxes that do not properly support all QTYPEs. 191 The QTYPE=A queries will also blend into traffic from non-minimising 192 resolvers, making it in some cases harder to observe that the 193 resolver is using QNAME minimisation. Using the QTYPE that occurs 194 most in incoming queries will slightly reduce the number of queries, 195 as there is no extra check needed for delegations on non-apex 196 records. Another potential benefit of using QTYPE=A is that 197 [RFC8305] clients that need answers for both the A and AAAA types 198 will send the AAAA query first. When minimising using QTYPE=A the 199 minimised query might be useful, and now already in the cache, for 200 the happy eyeballs query for the A QTYPE. 202 2.2. QNAME Selection 204 The minimising resolver works perfectly when it knows the zone cut 205 (zone cuts are described in Section 6 of [RFC2181]). But zone cuts 206 do not necessarily exist at every label boundary. In the name 207 www.foo.bar.example, it is possible that there is a zone cut between 208 "foo" and "bar" but not between "bar" and "example". So, assuming 209 that the resolver already knows the name servers of example, when it 210 receives the query "What is the AAAA record of www.foo.bar.example?", 211 it does not always know where the zone cut will be. To find the 212 zone cut, it will query the example name servers for a record for 213 bar.example. It will get a non-referral answer, it has to query the 214 example name servers again with one more label, and so on. 215 (Section 3 describes this algorithm in deeper detail.) 217 2.3. Limit Number of Queries 219 When using QNAME minimisation, the number of labels in the received 220 QNAME can influence the number of queries sent from the resolver. 221 This opens an attack vector and can decrease performance. Resolvers 222 supporting QNAME minimisation MUST implement a mechanism to limit the 223 number of outgoing queries per user request. 225 Take for example an incoming QNAME with many labels, like 226 www.host.group.department.example.com, where 227 host.group.department.example.com is hosted on example.com's 228 name servers. (Such deep domains are especially common under 229 ip6.arpa.) Assume a resolver that knows only the name servers of 230 example.com. Without QNAME minimisation, it would send these 231 example.com name servers a query for 232 www.host.group.department.example.com and immediately get a specific 233 referral or an answer, without the need for more queries to probe for 234 the zone cut. For such a name, a cold resolver with QNAME 235 minimisation will send more queries, one per label. Once the cache 236 is warm, there will be less difference with a traditional resolver. 237 Testing of this is described in [Huque-QNAME-Min]. 239 The behaviour of sending multiple queries can be exploited by sending 240 queries with a large number of labels in the QNAME that will be 241 answered using a wildcard record. Take for example a record for 242 *.example.com, hosted on example.com's name servers. An incoming 243 query containing a QNAME with more than 100 labels, ending in 244 example.com, will result in a query per label. By using random 245 labels, the attacker can bypass the cache and always require the 246 resolver to send many queries upstream. Note that [RFC8198] can 247 limit this attack in some cases. 249 One mechanism that MAY be used to reduce this attack vector is by 250 appending more than one label per iteration for QNAMEs with a large 251 number of labels. To do this, a maximum number of QNAME minimisation 252 iterations has to be selected (MAX_MINIMISE_COUNT); a good value is 253 10. Optionally, a value for the number of queries that should only 254 have one label appended can be selected (MINIMISE_ONE_LAB), a good 255 value is 4. The assumption here is that the number of labels on 256 delegations higher in the hierarchy are rather small, therefore not 257 exposing too many labels early on has the most privacy benefit. 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 record. 319 (4) Otherwise, add the next relevant label or labels from QNAME to 320 the start of CHILD. The number of labels to add is discussed in 321 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 Assume that a resolver receives a request to resolve 357 foo.bar.baz.example. Assume that the resolver already knows that 358 ns1.nic.example is authoritative for .example, and that the resolver 359 does not know a more specific authoritative name server. It will 360 send the query with QNAME=baz.example and the QTYPE selected to hide 361 the original QTYPE to ns1.nic.example. 363 Here are more detailed examples of queries with QNAME minimisation: 365 Cold cache, traditional resolution algorithm without QNAME 366 minimisation, request for MX record of a.b.example.org: 368 QTYPE QNAME TARGET NOTE 369 MX a.b.example.org root nameserver 370 MX a.b.example.org org nameserver 371 MX a.b.example.org example.org nameserver 373 Cold cache, with QNAME minimisation, request for MX record of 374 a.b.example.org, using the A QTYPE to hide the original QTYPE: 376 QTYPE QNAME TARGET NOTE 377 A org root nameserver 378 A example.org org nameserver 379 A b.example.org example.org nameserver 380 A a.b.example.org example.org nameserver "a" may be delegated 381 MX a.b.example.org example.org nameserver 383 Note that in above example one query would have been saved if the 384 incoming QTYPE would have been the same as the QTYPE selected by the 385 resolver to hide the original QTYPE. Only one query for 386 a.b.example.org would have been needed if the original QTYPE would 387 have been A. Using the most used QTYPE to hide the original QTYPE 388 therefore slightly reduces the number of outgoing queries. 390 Warm cache with only org delegation known, (example.org's NS RRset is 391 not known), request for MX record of a.b.example.org, using A QTYPE 392 to hide the original QTYPE: 394 QTYPE QNAME TARGET NOTE 395 A example.org org nameserver 396 A b.example.org example.org nameserver 397 A a.b.example.org example.org nameserver "a" may be delegated 398 MX a.b.example.org example.org nameserver 400 5. Performance Considerations 402 The main goal of QNAME minimisation is to improve privacy by sending 403 less data. However, it may have other advantages. For instance, if 404 a resolver sends a root name server queries for A.example followed by 405 B.example followed by C.example, the result will be three NXDOMAINs, 406 since .example does not exist in the root zone. When using QNAME 407 minimisation, the resolver would send only one question (for .example 408 itself) to which they could answer NXDOMAIN. The resolver can cache 409 this answer and use it as to prove that nothing below .example exists 410 ([RFC8020]). A resolver now knows a priori that neither B.example 411 nor C.example exist. Thus, in this common case, the total number of 412 upstream queries under QNAME minimisation could counterintuitively be 413 less than the number of queries under the traditional iteration (as 414 described in the DNS standard). 416 QNAME minimisation may also improve lookup performance for TLD 417 operators. For a TLD that is delegation-only, a two-label QNAME 418 query may be optimal for finding the delegation owner name, depending 419 on the way domain matching is implemented. 421 QNAME minimisation can increase the number of queries based on the 422 incoming QNAME. This is described in Section 2.3. As described in 423 [devries-qnamemin], QNAME minimisation in strict mode both increases 424 the number of DNS lookups by up to 26% and leads to up to 5% more 425 failed lookups. The full cache in a production resolver will soften 426 that overhead. 428 6. Security Considerations 430 QNAME minimisation's benefits are clear in the case where you want to 431 decrease exposure to the authoritative name server. But minimising 432 the amount of data sent also, in part, addresses the case of a wire 433 sniffer as well as the case of privacy invasion by the servers. 434 (Encryption is of course a better defense against wire sniffers, but, 435 unlike QNAME minimisation, it changes the protocol and cannot be 436 deployed unilaterally. Also, the effect of QNAME minimisation on 437 wire sniffers depends on whether the sniffer is on the DNS path.) 439 QNAME minimisation offers no protection against the recursive 440 resolver, which still sees the full request coming from the stub 441 resolver. 443 A resolver using QNAME minimisation can possibly be used to cause a 444 query storm to be sent to servers when resolving queries containing a 445 QNAME with a large number of labels, as described in Section 2.3. 446 That section proposes methods to significantly dampen the effects of 447 such attacks. 449 7. References 451 7.1. Normative References 453 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 454 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 455 . 457 [RFC1035] Mockapetris, P., "Domain names - implementation and 458 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 459 November 1987, . 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 467 Morris, J., Hansen, M., and R. Smith, "Privacy 468 Considerations for Internet Protocols", RFC 6973, 469 DOI 10.17487/RFC6973, July 2013, 470 . 472 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 473 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 474 . 476 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 477 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 478 May 2017, . 480 7.2. Informative References 482 [apnic-qnamemin] 483 Huston, G. and J. Damas, "Measuring Query Name 484 Minimization", September 2020, . 489 [devries-qnamemin] 490 "A First Look at QNAME Minimization in the Domain Name 491 System", March 2019, 492 . 495 [dnsthought-qnamemin] 496 "DNSThought QNAME minimisation results. Using Atlas 497 probes", March 2020, 498 . 500 [Huque-QNAME-Min] 501 Huque, S., "Query name minimization and authoritative 502 server behavior", May 2015, 503 . 505 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 506 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 507 . 509 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 510 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 511 April 2013, . 513 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 514 DOI 10.17487/RFC7626, August 2015, 515 . 517 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 518 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 519 November 2016, . 521 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 522 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 523 July 2017, . 525 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 526 Better Connectivity Using Concurrency", RFC 8305, 527 DOI 10.17487/RFC8305, December 2017, 528 . 530 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 531 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 532 January 2019, . 534 [verisign-qnamemin] 535 Thomas, M., "Maximizing Qname Minimization: A New Chapter 536 in DNS Protocol Evolution", September 2020, 537 . 540 Acknowledgments 542 The acknowledgements from RFC 7816 apply here. In addition, many 543 participants from the DNSOP Working Group helped with proposals for 544 simplification, clarification, and general editorial help. 546 Changes from RFC 7816 548 Changed in -07 550 * Stopped using the term "aggressive" for the method described 552 * Clarified some terminology 554 * More reorganization 556 Changed in -06 557 * Removed lots of text from when this was experimental 559 * Lots of reorganization 561 Changed in -04 563 * Start structure for implementation section 565 * Add clarification why the used QTYPE does not matter 567 * Make algorithm DS QTYPE compatible 569 Changed in -03 571 * Drop recommendation to use the NS QTYPE to hide the incoming QTYPE 573 * Describe DoS attach vector for QNAME with large number of labels, 574 and propose a mitigation. 576 * Simplify examples and change qname to a.b.example.com to show the 577 change in number of queries. 579 Changed in -00, -01, and -02 581 * Made changes to deal with errata #4644 583 * Changed status to be on standards track 585 * Major reorganization 587 Authors' Addresses 589 Stephane Bortzmeyer 590 AFNIC 591 1, rue Stephenson 592 78180 Montigny-le-Bretonneux 593 France 595 Phone: +33 1 39 30 83 46 596 Email: bortzmeyer+ietf@nic.fr 597 URI: https://www.afnic.fr/ 599 Ralph Dolmans 600 NLnet Labs 602 Email: ralph@nlnetlabs.nl 603 Paul Hoffman 604 ICANN 606 Email: paul.hoffman@icann.org