idnits 2.17.1 draft-ietf-dnsop-rfc7816bis-07.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 364 has weird spacing: '...ple.org exam...' == Line 380 has weird spacing: '...ple.org exam...' -- The document date (27 October 2020) is 1269 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: 30 April 2021 P. Hoffman 7 ICANN 8 27 October 2020 10 DNS Query Name Minimisation to Improve Privacy 11 draft-ietf-dnsop-rfc7816bis-07 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 30 April 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 . . . . . . . . . . . . . . 6 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 publicaiton. 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 changes 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 hide the original QTYPE 168 * the QNAME that is the original QNAME, stripped to just one label 169 more than the longest matching domain name for which the 170 nameserver is known to be authoritative 172 2.1. QTYPE Selection 174 Note that this document relaxes the recommendation in RFC 7816 to use 175 the NS QTYPE to hide the original QTYPE. Using the NS QTYPE is still 176 allowed. The authority of NS records lies at the child side. The 177 parent side of the delegation will answer using a referral, like it 178 will do for queries with other QTYPEs. Using the NS QTYPE therefore 179 has no added value over other QTYPEs. 181 The QTYPE to use while minimising queries can be any possible data 182 type (as defined in [RFC6895] Section 3.1) for which the authority 183 always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG, 184 TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no 185 relation between the incoming QTYPE and the selection of the QTYPE to 186 use while minimising. A good candidate is to always use the "A" 187 QTYPE because this is the least likely to raise issues in DNS 188 software and middleboxes that do not properly support all QTYPEs. 189 The QTYPE=A queries will also blend into traffic from non-minimising 190 resolvers, making it in some cases harder to observe that the 191 resolver is using QNAME minimisation. Using the QTYPE that occurs 192 most in incoming queries will slightly reduce the number of queries, 193 as there is no extra check needed for delegations on non-apex 194 records. Another potential benefit of using QTYPE=A is that 195 [RFC8305] clients that need answers for both the A and AAAA types 196 will send the AAAA query first. When minimising using QTYPE=A the 197 minimised query might be useful, and now already in the cache, for 198 the happy eyeballs query for the A QTYPE. 200 2.2. QNAME Selection 202 The minimising resolver works perfectly when it knows the zone cut 203 (zone cuts are described in Section 6 of [RFC2181]). But zone cuts 204 do not necessarily exist at every label boundary. In the name 205 www.foo.bar.example, it is possible that there is a zone cut between 206 "foo" and "bar" but not between "bar" and "example". So, assuming 207 that the resolver already knows the name servers of example, when it 208 receives the query "What is the AAAA record of www.foo.bar.example?", 209 it does not always know where the zone cut will be. To find the 210 zone cut, it will query the example name servers for a record for 211 bar.example. It will get a non-referral answer, it has to query the 212 example name servers again with one more label, and so on. 213 (Section 3 describes this algorithm in deeper detail.) 215 2.3. Limit Number of Queries 217 When using QNAME minimisation, the number of labels in the received 218 QNAME can influence the number of queries sent from the resolver. 219 This opens an attack vector and can decrease performance. Resolvers 220 supporting QNAME minimisation MUST implement a mechanism to limit the 221 number of outgoing queries per user request. 223 Take for example an incoming QNAME with many labels, like 224 www.host.group.department.example.com, where 225 host.group.department.example.com is hosted on example.com's 226 name servers. (Such deep domains are especially common under 227 ip6.arpa.) Assume a resolver that knows only the name servers of 228 example.com. Without QNAME minimisation, it would send these 229 example.com name servers a query for 230 www.host.group.department.example.com and immediately get a specific 231 referral or an answer, without the need for more queries to probe for 232 the zone cut. For such a name, a cold resolver with QNAME 233 minimisation will send more queries, one per label. Once the cache 234 is warm, there will be less difference with a traditional resolver. 235 Testing of this is described in [Huque-QNAME-Min]. 237 The behaviour of sending multiple queries can be exploited by sending 238 queries with a large number of labels in the QNAME that will be 239 answered using a wildcard record. Take for example a record for 240 *.example.com, hosted on example.com's name servers. An incoming 241 query containing a QNAME with more than 100 labels, ending in 242 example.com, will result in a query per label. By using random 243 labels, the attacker can bypass the cache and always require the 244 resolver to send many queries upstream. Note that [RFC8198] can 245 limit this attack in some cases. 247 One mechanism to reduce this attack vector is by appending more than 248 one label per iteration for QNAMEs with a large number of labels. To 249 do this, a maximum number of QNAME minimisation iterations has to be 250 selected (MAX_MINIMISE_COUNT); a good value is 10. Optionally, a 251 value for the number of queries that should only have one label 252 appended can be selected (MINIMISE_ONE_LAB), a good value is 4. The 253 assumption here is that the number of labels on delegations higher in 254 the hierarchy are rather small, therefore not exposing too may labels 255 early on has the most privacy benefit. 257 When a resolver needs to send out a query, it will look for the 258 closest known delegation point in its cache. The number of QNAME 259 minimisation iterations is the difference between this closest 260 nameserver and the incoming QNAME. The first MINIMISE_ONE_LAB 261 iterations will be handles as described in Section 2. The number of 262 labels that are not exposed yet now need to be divided over the 263 iterations that are left (MAX_MINIMISE_COUNT - MINIMISE_ONE_LAB). 264 The remainder of the division should be added to the last iterations. 265 For example, when resolving a QNAME with 18 labels, the number of 266 labels added per iteration are: 1,1,1,1,2,2,2,2,3,3. 268 2.4. Stub and Forwarding Resolvers 270 Stub and forwarding resolvers MAY implement QNAME minimisation. 271 Minimising queries that will be sent to an upstream resolver does not 272 help in hiding data from the upstream resolver because all 273 information will end up there anyway. It might, however, limit the 274 data exposure between the upstream resolver and the authoritative 275 nameserver in the situation where the upstream resolver does not 276 support QNAME minimisation. Using QNAME minimisation in a stub or 277 forwarding resolvers that does not have a mechanism to find and cache 278 zone cuts will drastically increase the number of outgoing queries. 280 3. Algorithm to Perform QNAME Minimisation 282 This algorithm performs name resolution with QNAME minimisation in 283 the presence of zone cuts that are not yet known. 285 Although a validating resolver already has the logic to find the 286 zone cuts, implementers of resolvers may want to use this algorithm 287 to locate the zone cuts. 289 (0) If the query can be answered from the cache, do so; otherwise, 290 iterate as follows: 292 (1) Get the closest delegation point that can be used for the 293 original QNAME/QTYPE combination from the cache. 295 (1a) For queries with QTYPE=DS this is the NS RRset with the 296 owner matching the most labels with the QNAME stripped by 297 one label. The QNAME will be a subdomain of (but not equal 298 to) this NS RRset. Call this ANCESTOR. 300 (1b) For queries with other original QTYPEs this is the NS RRset 301 with the owner matching the most labels with the QNAME. The 302 QNAME will be equal to or a subdomain of this NS RRset. 303 Call this ANCESTOR. 305 (2) Initialise CHILD to the same as ANCESTOR. 307 (3) If CHILD is the same as the QNAME, or if the CHILD is one label 308 shorter than the QNAME and the original QTYPE is DS, resolve the 309 original query using ANCESTOR's name servers, and finish. 311 (4) Otherwise, add a label from the QNAME to the start of CHILD. 313 (5) Look for a cache entry for the RRset at CHILD with the original 314 QTYPE. If this entry is for an NXDOMAIN and the resolver has 315 support for [RFC8020], the NXDOMAIN can be used in response to 316 the original query, and stop. If the entry is for a NOERROR 317 answer (either positive or negative), go back to step 3. If the 318 entry is for an NXDOMAIN answer and the resolver does not support 319 RFC 8020, go back to step 3. 321 (6) Query for CHILD with the selected QTYPE using ANCESTOR's 322 name servers. The response can be: 324 (6a) A referral. Cache the NS RRset from the authority section, 325 and go back to step 1. 327 (6b) A NOERROR answer (either positive or negative). Cache this 328 answer, and go back to step 3. 330 (6c) If the resolver is doing RFC 8020 with strict NXDOMAIN, an 331 NXDOMAIN answer. Return an NXDOMAIN answer in response to 332 the original query, and stop. If the resolver does not 333 support RFC 8020, go back to step 3. 335 (6d) An answer with another RCODE, or no answer. Try another 336 name server at the same delegation point. Stop if none of 337 them are able to return a valid answer. 339 4. QNAME Minimisation Examples 341 Assume that a resolver receives a request to resolve 342 foo.bar.baz.example. Assume that the resolver already knows that 343 ns1.nic.example is authoritative for .example, and that the resolver 344 does not know a more specific authoritative name server. It will 345 send the query with QNAME=baz.example and the QTYPE selected to hide 346 the original QTYPE to ns1.nic.example. 348 Here are more detailed examples of queries with QNAME minimisation: 350 Cold cache, traditional resolution algorithm without QNAME 351 minimisation, request for MX record of a.b.example.org: 353 QTYPE QNAME TARGET NOTE 354 MX a.b.example.org root nameserver 355 MX a.b.example.org org nameserver 356 MX a.b.example.org example.org nameserver 358 Cold cache, with QNAME minimisation, request for MX record of 359 a.b.example.org, using the A QTYPE to hide the original QTYPE: 361 QTYPE QNAME TARGET NOTE 362 A org root nameserver 363 A example.org org nameserver 364 A b.example.org example.org nameserver 365 A a.b.example.org example.org nameserver "a" may be delegated 366 MX a.b.example.org example.org nameserver 367 Note that in above example one query would have been saved if the 368 incoming QTYPE would have been the same as the QTYPE selected by the 369 resolver to hide the original QTYPE. Only one query for 370 a.b.example.org would have been needed if the original QTYPE would 371 have been A. Using the most used QTYPE to hide the original QTYPE 372 therefore slightly reduces the number of outgoing queries. 374 Warm cache with only org delegation known, (example.org's NS RRset is 375 not known), request for MX record of a.b.example.org, using A QTYPE 376 to hide the original QTYPE: 378 QTYPE QNAME TARGET NOTE 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 5. Performance Considerations 386 The main goal of QNAME minimisation is to improve privacy by sending 387 less data. However, it may have other advantages. For instance, if 388 a resolver sends a root name server queries for A.example followed by 389 B.example followed by C.example, the result will be three NXDOMAINs, 390 since .example does not exist in the root zone. When using QNAME 391 minimisation, the resolver would send only one question (for .example 392 itself) to which they could answer NXDOMAIN. The resolver can cache 393 this answer and use it as to prove that nothing below .example exists 394 ([RFC8020]). A resolver now knows a priori that neither B.example 395 nor C.example exist. Thus, in this common case, the total number of 396 upstream queries under QNAME minimisation could counterintuitively be 397 less than the number of queries under the traditional iteration (as 398 described in the DNS standard). 400 QNAME minimisation may also improve lookup performance for TLD 401 operators. For a TLD that is delegation-only, a two-label QNAME 402 query may be optimal for finding the delegation owner name, depending 403 on the way domain matching is implemented. 405 QNAME minimisation can increase the number of queries based on the 406 incoming QNAME. This is described in Section 2.3. 408 6. Security Considerations 410 QNAME minimisation's benefits are clear in the case where you want to 411 decrease exposure to the authoritative name server. But minimising 412 the amount of data sent also, in part, addresses the case of a wire 413 sniffer as well as the case of privacy invasion by the servers. 414 (Encryption is of course a better defense against wire sniffers, but, 415 unlike QNAME minimisation, it changes the protocol and cannot be 416 deployed unilaterally. Also, the effect of QNAME minimisation on 417 wire sniffers depends on whether the sniffer is on the DNS path.) 419 QNAME minimisation offers no protection against the recursive 420 resolver, which still sees the full request coming from the stub 421 resolver. 423 A resolver using QNAME minimisation can possibly be used to cause a 424 query storm to be sent to servers when resolving queries containing a 425 QNAME with a large number of labels, as described in Section 2.3. 426 That section proposes methods to significantly dampen the effects of 427 such attacks. 429 7. References 431 7.1. Normative References 433 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 434 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 435 . 437 [RFC1035] Mockapetris, P., "Domain names - implementation and 438 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 439 November 1987, . 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, 443 DOI 10.17487/RFC2119, March 1997, 444 . 446 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 447 Morris, J., Hansen, M., and R. Smith, "Privacy 448 Considerations for Internet Protocols", RFC 6973, 449 DOI 10.17487/RFC6973, July 2013, 450 . 452 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 453 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 454 . 456 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 457 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 458 May 2017, . 460 7.2. Informative References 462 [apnic-qnamemin] 463 Huston, G. and J. Damas, "Measuring Query Name 464 Minimization", September 2020, . 469 [devries-qnamemin] 470 "A First Look at QNAME Minimization in the Domain Name 471 System", March 2019, 472 . 475 [dnsthought-qnamemin] 476 "DNSThought QNAME minimisation results. Using Atlas 477 probes", March 2020, 478 . 480 [Huque-QNAME-Min] 481 Huque, S., "Query name minimization and authoritative 482 server behavior", May 2015, 483 . 485 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 486 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 487 . 489 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 490 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 491 April 2013, . 493 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 494 DOI 10.17487/RFC7626, August 2015, 495 . 497 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 498 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 499 November 2016, . 501 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 502 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 503 July 2017, . 505 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 506 Better Connectivity Using Concurrency", RFC 8305, 507 DOI 10.17487/RFC8305, December 2017, 508 . 510 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 511 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 512 January 2019, . 514 [verisign-qnamemin] 515 Thomas, M., "Maximizing Qname Minimization: A New Chapter 516 in DNS Protocol Evolution", September 2020, 517 . 520 Acknowledgments 522 The acknowledgements from RFC 7816 apply here. In addition, many 523 participants from the DNSOP Working Group helped with proposals for 524 simplification, clarification, and general editorial help. 526 Changes from RFC 7816 528 Changed in -07 530 * Stopped using the term "aggressive" for the method described 532 * Clarified some terminology 534 * More reorganization 536 Changed in -06 538 * Removed lots of text from when this was experimental 540 * Lots of reorganization 542 Changed in -04 544 * Start structure for implementation section 546 * Add clarification why the used QTYPE does not matter 548 * Make algorithm DS QTYPE compatible 550 Changed in -03 552 * Drop recommendation to use the NS QTYPE to hide the incoming QTYPE 553 * Describe DoS attach vector for QNAME with large number of labels, 554 and propose a mitigation. 556 * Simplify examples and change qname to a.b.example.com to show the 557 change in number of queries. 559 Changed in -00, -01, and -02 561 * Made changes to deal with errata #4644 563 * Changed status to be on standards track 565 * Major reorganization 567 Authors' Addresses 569 Stephane Bortzmeyer 570 AFNIC 571 1, rue Stephenson 572 78180 Montigny-le-Bretonneux 573 France 575 Phone: +33 1 39 30 83 46 576 Email: bortzmeyer+ietf@nic.fr 577 URI: https://www.afnic.fr/ 579 Ralph Dolmans 580 NLnet Labs 582 Email: ralph@nlnetlabs.nl 584 Paul Hoffman 585 ICANN 587 Email: paul.hoffman@icann.org