idnits 2.17.1 draft-ietf-dnsop-rfc7816bis-08.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 378 has weird spacing: '...ple.org exam...' == Line 395 has weird spacing: '...ple.org exam...' -- The document date (15 April 2021) is 1078 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: 17 October 2021 P. Hoffman 7 ICANN 8 15 April 2021 10 DNS Query Name Minimisation to Improve Privacy 11 draft-ietf-dnsop-rfc7816bis-08 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 17 October 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. 125 1.2. Terminology 127 The terminology used in this document is defined in [RFC8499]. 129 In this document, a "cold" cache is one that is empty, having 130 literally no entries in it. A "warm" cache is one that has some 131 entries in it. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 2. Description of QNAME Minimisation 141 The idea behind QNAME minimisation is to minimise the amount of 142 privacy sensitive data sent from the DNS resolver to the 143 authoritative name server. This section describes how to do QNAME 144 minimisation. The algorithm is summarised in Section 3. 146 When a resolver is not able to answer a query from cache it has to 147 send a query to an authoritative nameserver. Traditionally these 148 queries would contain the full QNAME and the original QTYPE as 149 received in the client query. 151 The full QNAME and original QTYPE are only needed at the nameserver 152 that is authoritative for the record requested by the client. All 153 other nameservers queried while resolving the query only need to 154 receive enough of the QNAME to be able to answer with a delegation. 155 The QTYPE in these queries is not relevant, as the nameserver is not 156 able to authoritatively answer the records the client is looking for. 157 Sending the full QNAME and original QTYPE to these nameservers 158 therefore exposes more privacy sensitive data than necessary to 159 resolve the client's request. 161 A resolver that implements QNAME minimisation obscures the QNAME and 162 QTYPE in queries directed to an authoritative nameserver that is not 163 known to be responsible for the original QNAME. These queries 164 contain: 166 * a QTYPE selected by the resolver to possibly obscure the original 167 QTYPE 169 * the QNAME that is the original QNAME, stripped to just one label 170 more than the longest matching domain name for which the 171 nameserver is known to be authoritative 173 2.1. QTYPE Selection 175 Note that this document relaxes the recommendation in RFC 7816 to use 176 the NS QTYPE to hide the original QTYPE. Using the NS QTYPE is still 177 allowed. The authority of NS records lies at the child side. The 178 parent side of the delegation will answer using a referral, like it 179 will do for queries with other QTYPEs. Using the NS QTYPE therefore 180 has no added value over other QTYPEs. 182 The QTYPE to use while minimising queries can be any possible data 183 type (as defined in [RFC6895] Section 3.1) for which the authority 184 always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG, 185 TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no 186 relation between the incoming QTYPE and the selection of the QTYPE to 187 use while minimising. A good candidate is to always use the "A" 188 QTYPE because this is the least likely to raise issues in DNS 189 software and middleboxes that do not properly support all QTYPEs. 190 The QTYPE=A queries will also blend into traffic from non-minimising 191 resolvers, making it in some cases harder to observe that the 192 resolver is using QNAME minimisation. Using the QTYPE that occurs 193 most in incoming queries will slightly reduce the number of queries, 194 as there is no extra check needed for delegations on non-apex 195 records. Another potential benefit of using QTYPE=A is that 196 [RFC8305] clients that need answers for both the A and AAAA types 197 will send the AAAA query first. When minimising using QTYPE=A the 198 minimised query might be useful, and now already in the cache, for 199 the happy eyeballs query for the A QTYPE. 201 2.2. QNAME Selection 203 The minimising resolver works perfectly when it knows the zone cut 204 (zone cuts are described in Section 6 of [RFC2181]). But zone cuts 205 do not necessarily exist at every label boundary. In the name 206 www.foo.bar.example, it is possible that there is a zone cut between 207 "foo" and "bar" but not between "bar" and "example". So, assuming 208 that the resolver already knows the name servers of example, when it 209 receives the query "What is the AAAA record of www.foo.bar.example?", 210 it does not always know where the zone cut will be. To find the 211 zone cut, it will query the example name servers for a record for 212 bar.example. It will get a non-referral answer, it has to query the 213 example name servers again with one more label, and so on. 214 (Section 3 describes this algorithm in deeper detail.) 216 2.3. Limit Number of Queries 218 When using QNAME minimisation, the number of labels in the received 219 QNAME can influence the number of queries sent from the resolver. 220 This opens an attack vector and can decrease performance. Resolvers 221 supporting QNAME minimisation MUST implement a mechanism to limit the 222 number of outgoing queries per user request. 224 Take for example an incoming QNAME with many labels, like 225 www.host.group.department.example.com, where 226 host.group.department.example.com is hosted on example.com's 227 name servers. (Such deep domains are especially common under 228 ip6.arpa.) Assume a resolver that knows only the name servers of 229 example.com. Without QNAME minimisation, it would send these 230 example.com name servers a query for 231 www.host.group.department.example.com and immediately get a specific 232 referral or an answer, without the need for more queries to probe for 233 the zone cut. For such a name, a cold resolver with QNAME 234 minimisation will send more queries, one per label. Once the cache 235 is warm, there will be less difference with a traditional resolver. 236 Testing of this is described in [Huque-QNAME-Min]. 238 The behaviour of sending multiple queries can be exploited by sending 239 queries with a large number of labels in the QNAME that will be 240 answered using a wildcard record. Take for example a record for 241 *.example.com, hosted on example.com's name servers. An incoming 242 query containing a QNAME with more than 100 labels, ending in 243 example.com, will result in a query per label. By using random 244 labels, the attacker can bypass the cache and always require the 245 resolver to send many queries upstream. Note that [RFC8198] can 246 limit this attack in some cases. 248 One mechanism that MAY be used to reduce this attack vector is by 249 appending more than one label per iteration for QNAMEs with a large 250 number of labels. To do this, a maximum number of QNAME minimisation 251 iterations has to be selected (MAX_MINIMISE_COUNT); a good value is 252 10. Optionally, a value for the number of queries that should only 253 have one label appended can be selected (MINIMISE_ONE_LAB), a good 254 value is 4. The assumption here is that the number of labels on 255 delegations higher in the hierarchy are rather small, therefore not 256 exposing too many labels early on has the most privacy benefit. 258 When a resolver needs to send out a query, it will look for the 259 closest known delegation point in its cache. The number of not yet 260 exposed labels is the difference between this closest nameserver and 261 the incoming QNAME. The first MINIMISE_ONE_LAB labels will be 262 handled as described in Section 2. The number of labels that are 263 still not exposed now need to be divided proportionally over the 264 remaining iterations (MAX_MINIMISE_COUNT - MINIMISE_ONE_LAB). If the 265 not yet exposed labels can not be equally divided over the remaining 266 iterations, the remainder of the division should be added to the last 267 iterations. For example, when resolving a QNAME with 18 labels with 268 MAX_MINIMISE_COUNT set to 10 and MINIMISE_ONE_LAB set to 4, the 269 number of labels added per iteration are: 1,1,1,1,2,2,2,2,3,3. 271 2.4. Stub and Forwarding Resolvers 273 Stub and forwarding resolvers MAY implement QNAME minimisation. 274 Minimising queries that will be sent to an upstream resolver does not 275 help in hiding data from the upstream resolver because all 276 information will end up there anyway. It might, however, limit the 277 data exposure between the upstream resolver and the authoritative 278 nameserver in the situation where the upstream resolver does not 279 support QNAME minimisation. Using QNAME minimisation in a stub or 280 forwarding resolvers that does not have a mechanism to find and cache 281 zone cuts will drastically increase the number of outgoing queries. 283 3. Algorithm to Perform QNAME Minimisation 285 This algorithm performs name resolution with QNAME minimisation in 286 the presence of zone cuts that are not yet known. 288 Although a validating resolver already has the logic to find the 289 zone cuts, implementers of resolvers may want to use this algorithm 290 to locate the zone cuts. 292 (0) If the query can be answered from the cache, do so; otherwise, 293 iterate as follows: 295 (1) Get the closest delegation point that can be used for the 296 original QNAME from the cache. 298 (1a) For queries with a QTYPE for which the authority only lies 299 at the parent side (like QTYPE=DS) this is the NS RRset with 300 the owner matching the most labels with QNAME stripped by 301 one label. QNAME will be a subdomain of (but not equal to) 302 this NS RRset. Call this ANCESTOR. 304 (1b) For queries with other original QTYPEs this is the NS RRset 305 with the owner matching the most labels with QNAME. QNAME 306 will be equal to or a subdomain of this NS RRset. Call this 307 ANCESTOR. 309 (2) Initialise CHILD to the same as ANCESTOR. 311 (3) If CHILD is the same as QNAME, or if CHILD is one label shorter 312 than QNAME and the original QTYPE can only be at the parent side 313 (like QTYPE=DS), resolve the original query as normal starting 314 from ANCESTOR's name servers. Start over from step 0 if new 315 names need to be resolved as result of this answer, for example 316 when the answer contains a CNAME or DNAME record. 318 (4) Otherwise, add the next relevant label or labels from QNAME to 319 the start of CHILD. The number of labels to add is discussed in 320 Section 2.3. 322 (5) Look for a cache entry for the RRset at CHILD with the original 323 QTYPE. If the cached response code is NXDOMAIN and the resolver 324 has support for [RFC8020], the NXDOMAIN can be used in response 325 to the original query, and stop. If the cached response code is 326 NOERROR (including NODATA), go back to step 3. If the cached 327 response code is NXDOMAIN and the resolver does not support RFC 328 8020, go back to step 3. 330 (6) Query for CHILD with the selected QTYPE using one of ANCESTOR's 331 name servers. The response can be: 333 (6a) A referral. Cache the NS RRset from the authority section, 334 and go back to step 1. 336 (6b) A DNAME response. Proceed as if a DNAME is received for 337 the original query. Start over from step 0 to resolve the 338 new name based on the DNAME target. 340 (6c) All other NOERROR answers (including NODATA). Cache this 341 answer. Regardless of the answered RRset type, including 342 CNAMEs, continue with the algorithm from step 3 by building 343 the original QNAME. 345 (6d) An NXDOMAIN response. If the resolver supports RFC8020, 346 return an NXDOMAIN response to the original query and stop. 347 If the resolver does not support RFC8020, go to step 3. 349 (6e) A timeout or response with another RCODE. The 350 implementation may choose to retry step (6) with a different 351 ANCESTOR name server. 353 4. QNAME Minimisation Examples 355 Assume that a resolver receives a request to resolve 356 foo.bar.baz.example. Assume that the resolver already knows that 357 ns1.nic.example is authoritative for .example, and that the resolver 358 does not know a more specific authoritative name server. It will 359 send the query with QNAME=baz.example and the QTYPE selected to hide 360 the original QTYPE to ns1.nic.example. 362 Here are more detailed examples of queries with QNAME minimisation: 364 Cold cache, traditional resolution algorithm without QNAME 365 minimisation, request for MX record of a.b.example.org: 367 QTYPE QNAME TARGET NOTE 368 MX a.b.example.org root nameserver 369 MX a.b.example.org org nameserver 370 MX a.b.example.org example.org nameserver 372 Cold cache, with QNAME minimisation, request for MX record of 373 a.b.example.org, using the A QTYPE to hide the original QTYPE: 375 QTYPE QNAME TARGET NOTE 376 A org root nameserver 377 A example.org org nameserver 378 A b.example.org example.org nameserver 379 A a.b.example.org example.org nameserver "a" may be delegated 380 MX a.b.example.org example.org nameserver 382 Note that in above example one query would have been saved if the 383 incoming QTYPE would have been the same as the QTYPE selected by the 384 resolver to hide the original QTYPE. Only one query for 385 a.b.example.org would have been needed if the original QTYPE would 386 have been A. Using the most used QTYPE to hide the original QTYPE 387 therefore slightly reduces the number of outgoing queries. 389 Warm cache with only org delegation known, (example.org's NS RRset is 390 not known), request for MX record of a.b.example.org, using A QTYPE 391 to hide the original QTYPE: 393 QTYPE QNAME TARGET NOTE 394 A example.org org nameserver 395 A b.example.org example.org nameserver 396 A a.b.example.org example.org nameserver "a" may be delegated 397 MX a.b.example.org example.org nameserver 399 5. Performance Considerations 401 The main goal of QNAME minimisation is to improve privacy by sending 402 less data. However, it may have other advantages. For instance, if 403 a resolver sends a root name server queries for A.example followed by 404 B.example followed by C.example, the result will be three NXDOMAINs, 405 since .example does not exist in the root zone. When using QNAME 406 minimisation, the resolver would send only one question (for .example 407 itself) to which they could answer NXDOMAIN. The resolver can cache 408 this answer and use it as to prove that nothing below .example exists 409 ([RFC8020]). A resolver now knows a priori that neither B.example 410 nor C.example exist. Thus, in this common case, the total number of 411 upstream queries under QNAME minimisation could counterintuitively be 412 less than the number of queries under the traditional iteration (as 413 described in the DNS standard). 415 QNAME minimisation may also improve lookup performance for TLD 416 operators. For a TLD that is delegation-only, a two-label QNAME 417 query may be optimal for finding the delegation owner name, depending 418 on the way domain matching is implemented. 420 QNAME minimisation can increase the number of queries based on the 421 incoming QNAME. This is described in Section 2.3. 423 6. Security Considerations 425 QNAME minimisation's benefits are clear in the case where you want to 426 decrease exposure to the authoritative name server. But minimising 427 the amount of data sent also, in part, addresses the case of a wire 428 sniffer as well as the case of privacy invasion by the servers. 429 (Encryption is of course a better defense against wire sniffers, but, 430 unlike QNAME minimisation, it changes the protocol and cannot be 431 deployed unilaterally. Also, the effect of QNAME minimisation on 432 wire sniffers depends on whether the sniffer is on the DNS path.) 434 QNAME minimisation offers no protection against the recursive 435 resolver, which still sees the full request coming from the stub 436 resolver. 438 A resolver using QNAME minimisation can possibly be used to cause a 439 query storm to be sent to servers when resolving queries containing a 440 QNAME with a large number of labels, as described in Section 2.3. 441 That section proposes methods to significantly dampen the effects of 442 such attacks. 444 7. References 446 7.1. Normative References 448 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 449 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 450 . 452 [RFC1035] Mockapetris, P., "Domain names - implementation and 453 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 454 November 1987, . 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, 458 DOI 10.17487/RFC2119, March 1997, 459 . 461 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 462 Morris, J., Hansen, M., and R. Smith, "Privacy 463 Considerations for Internet Protocols", RFC 6973, 464 DOI 10.17487/RFC6973, July 2013, 465 . 467 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 468 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 469 . 471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 473 May 2017, . 475 7.2. Informative References 477 [apnic-qnamemin] 478 Huston, G. and J. Damas, "Measuring Query Name 479 Minimization", September 2020, . 484 [devries-qnamemin] 485 "A First Look at QNAME Minimization in the Domain Name 486 System", March 2019, 487 . 490 [dnsthought-qnamemin] 491 "DNSThought QNAME minimisation results. Using Atlas 492 probes", March 2020, 493 . 495 [Huque-QNAME-Min] 496 Huque, S., "Query name minimization and authoritative 497 server behavior", May 2015, 498 . 500 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 501 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 502 . 504 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 505 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 506 April 2013, . 508 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 509 DOI 10.17487/RFC7626, August 2015, 510 . 512 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 513 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 514 November 2016, . 516 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 517 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 518 July 2017, . 520 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 521 Better Connectivity Using Concurrency", RFC 8305, 522 DOI 10.17487/RFC8305, December 2017, 523 . 525 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 526 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 527 January 2019, . 529 [verisign-qnamemin] 530 Thomas, M., "Maximizing Qname Minimization: A New Chapter 531 in DNS Protocol Evolution", September 2020, 532 . 535 Acknowledgments 537 The acknowledgements from RFC 7816 apply here. In addition, many 538 participants from the DNSOP Working Group helped with proposals for 539 simplification, clarification, and general editorial help. 541 Changes from RFC 7816 543 Changed in -07 545 * Stopped using the term "aggressive" for the method described 547 * Clarified some terminology 549 * More reorganization 551 Changed in -06 553 * Removed lots of text from when this was experimental 555 * Lots of reorganization 556 Changed in -04 558 * Start structure for implementation section 560 * Add clarification why the used QTYPE does not matter 562 * Make algorithm DS QTYPE compatible 564 Changed in -03 566 * Drop recommendation to use the NS QTYPE to hide the incoming QTYPE 568 * Describe DoS attach vector for QNAME with large number of labels, 569 and propose a mitigation. 571 * Simplify examples and change qname to a.b.example.com to show the 572 change in number of queries. 574 Changed in -00, -01, and -02 576 * Made changes to deal with errata #4644 578 * Changed status to be on standards track 580 * Major reorganization 582 Authors' Addresses 584 Stephane Bortzmeyer 585 AFNIC 586 1, rue Stephenson 587 78180 Montigny-le-Bretonneux 588 France 590 Phone: +33 1 39 30 83 46 591 Email: bortzmeyer+ietf@nic.fr 592 URI: https://www.afnic.fr/ 594 Ralph Dolmans 595 NLnet Labs 597 Email: ralph@nlnetlabs.nl 599 Paul Hoffman 600 ICANN 601 Email: paul.hoffman@icann.org