idnits 2.17.1 draft-lmo-dprive-phase2-requirements-01.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 9. TLS 1.3 (or later versions) MUST be supported and downgrades from TLS 1.3 to prior versions MUST not occur. -- The document date (November 04, 2019) is 1607 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 619 -- Looks like a reference, but probably isn't: '2' on line 621 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DPRIVE J. Livingood 3 Internet-Draft Comcast 4 Intended status: Informational A. Mayrhofer 5 Expires: May 7, 2020 nic.at GmbH 6 B. Overeinder 7 NLnet Labs 8 November 04, 2019 10 DNS Privacy Requirements for Exchanges between Recursive Resolvers and 11 Authoritative Servers 12 draft-lmo-dprive-phase2-requirements-01 14 Abstract 16 This document provides requirements for adding confidentiality to DNS 17 exchanges between recursive resolvers and authoritative servers. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 7, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction & Scope . . . . . . . . . . . . . . . . . . . . 2 54 2. Document Development . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Threat Model and Problem Statement . . . . . . . . . . . . . 3 57 5. Perspectives and Use Cases . . . . . . . . . . . . . . . . . 4 58 5.1. The User Perspective and Use Cases . . . . . . . . . . . 4 59 5.2. The Operator Perspective and Use Cases . . . . . . . . . 5 60 5.3. The Implementor / Software Vendor Perspective and Use 61 Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Preliminary Requirements . . . . . . . . . . . . . . . . . . 7 63 6.1. Mandatory Requirements (Proposed) . . . . . . . . . . . . 7 64 6.2. Optional Requirements (Proposed) . . . . . . . . . . . . 8 65 6.3. Working Group Discussion Needed . . . . . . . . . . . . . 8 66 6.4. Prioritization of Requirements . . . . . . . . . . . . . 9 67 6.5. Opportunistic Upgrade to Encryption . . . . . . . . . . . 9 68 6.6. Detection of Availability . . . . . . . . . . . . . . . . 10 69 6.7. Resistance to Downgrade Attack . . . . . . . . . . . . . 10 70 6.8. End-User Policy Propagation . . . . . . . . . . . . . . . 11 71 6.9. Performance and Efficiency . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 9.1. lmo-dprive-phase2-requirements-00 . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 13 79 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction & Scope 85 The 2018 approved charter of the IETF DPRIVE Working Group [1] 86 contains milestones related to confidentiality aspects of DNS 87 transactions between the iterative resolver and authoritative name 88 servers. 90 This is also reflected in the DPRIVE milestones [2], which (as of 91 October 2019) contains two relevant milestones: 93 Develop requirements for adding confidentiality to DNS exchanges 94 between recursive resolvers and authoritative servers (unpublished 95 document). 97 Investigate potential solutions for adding confidentiality to DNS 98 exchanges involving authoritative servers (Experimental). 100 This document intends to cover the first milestone for defining 101 requirements for adding confidentiality to DNS exchanges between 102 recursive resolvers and authoritative servers. This may in turn lead 103 to progress in investigating, developing and standardizing potential 104 experimental methods of meeting those requirements. 106 The motivation for this work is to extend the confidentiality methods 107 used between a user's stub resolver and a recursive resolver to the 108 recursive queries sent by recursive resolvers in response to a DNS 109 lookup (when a cache miss occurs and the server must perform 110 recursion to obtain a response to the query). A recursive resolver 111 will send queries to root servers, to Top Level Domain (TLD) servers, 112 to authoritative second level domain servers and potentially to other 113 authoritative DNS servers and each of these query/response 114 transactions presents an opportunity to extend the confidentiality of 115 user DNS queries. 117 2. Document Development 119 TEMPORARY SECTION - WILL BE REMOVED BEFORE PUBLISHING The authors are 120 working on this document via GitHub at https://github.com/alex-nicat/ 121 ietf-dprive-phase2-requirements/. Feedback via pull requests and 122 issues are invited there. The authors plan to continue developing 123 the document in the lead up to IETF-106, after the draft cut-off 124 date. 126 3. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 This document also makes use of DNS Terminology defined in [RFC8499] 136 4. Threat Model and Problem Statement 138 Currently, potentially privacy-protective protocols such as DoT 139 provide encryption between the user's stub resolver and a recursive 140 resolver. This provides (1) protection from observation of end user 141 DNS queries and responses as well as (2) protection from on-the-wire 142 modification DNS queries or responses (including potentially forcing 143 a downgrade to an unencrypted communication). Of course, observation 144 and modification are still possible when performed by the recursive 145 resolver, which decrypts queries, serves a response from cache or 146 performs recursion to obtain a response (or synthesizes a response), 147 and then encrypts the response and sends it back to the user's stub 148 resolver. 150 But observation and modification threats still exist when a recursive 151 resolver must perform DNS recursion, from the root to TLD to 152 authoritative servers. This document specifies requirements for 153 filling those gaps. 155 5. Perspectives and Use Cases 157 The DNS resolving process involves several entities. These entities 158 have different interests/requirements, and hence it does make sense 159 to examine the interests of those entities separately - though in 160 many cases their interests are aligned. Four different entities can 161 be identified, and their interests are described in the following 162 sections: 164 o Users 166 o Operators 168 o Implementors / Software Developers 170 o Researchers 172 5.1. The User Perspective and Use Cases 174 The privacy and confidentiality of Users (that is, users as in 175 clients of recursive resolvers, which in turn forward/resolve the 176 user's DNS requests by contacting authoritative servers) can be 177 improved in several ways. We call this "minimisation of exposure", 178 and there are currently three ways to reduce that exposure: 180 o Qname minimisation [RFC7816], reducing the amount of information 181 which is absolutely necessary to resolve a query 183 o Aggressive NSEC/local auth cache [RFC8198], reducing the amount of 184 outgoing queries in the first place 186 o Encryption, removing exposure of information while in transit 188 As recursors typically forwards queries received from the user to 189 authoritative servers. This creates a transitive trust between the 190 user and the recursor, as well as the authoritative server, since 191 information created by the user is exposed to the authoritative 192 server. However, the user has never a chance to identify which data 193 was exposed to which authoritative party (via which path). 195 Also, Users would want to be informed about the status of the 196 connections which were made on their behalf, which adds a fourth 197 point 199 Encryption/privacy status signaling 201 *TODO*: Actual requirements - what do users "want"? Start below: 203 5.2. The Operator Perspective and Use Cases 205 Operators of authoritative services have to provide stable and fast 206 DNS services, and interact with a wide range of clients, not all of 207 them authoritative servers. The operator side actually consists of 208 two sides: 210 o The "upstream" facing side of recursive resolvers 212 o The "downstream" side of authoritative servers 214 Those two sides are typically operated by different entities, but 215 many entities operate "both sides". Even though that is discouraged 216 (*TODO* source), the two sides might even be operated on the same 217 nameserver. 219 o Maybe different technical perspectives for operators 221 * Intelligence (sharing information) 223 * SLD popularity for marketing 225 o Focus initially on Second Level Domains (SLDs) initially 227 * Is there a difference for TLDs vs. SLDs from a "protocol" 228 perspective? 230 o Monitoring and aggregated data analysis 232 o Signaling provisioning information 234 * New record type for finding authoritative server key and 235 authentication? Use SRV? (Being able to use different servers 236 for serving up DNS-over-{TCP,UDP} vs DNS-over-TLS responses may 237 be valuable. 239 * Signal secure transport details (DNS-over-TLS, DNS-over-QUIC, 240 EncryptedSNI, connectionless, etc.), perhaps in an extensible 241 manner? Minimize RTTs and reduce need for trials. 243 * Large provider use cases where the NS names are out of 244 bailiwick for the zone (e.g. small number of distinct NS 245 records serving 100k+ zones) 247 o EDNS client subnet (JL: Not sure ECS crosses the cost/benefit 248 threshold to be included as a requirement and many CDNs that run 249 auth servers will likely say ECS is quite operationally important) 251 o Decide between TLS and connectionless (such as COSE-based 252 messages) 254 o Costs of TLS connection vs. connectionless 256 * Technical solution, e.g. encryption of the DNS query, shouldn't 257 enable an attack vector for DDoS or resource exhaustion. For 258 example, only if the client uses DNS-over-TLS, the upstream 259 query to the authoritative will be over DNS-over-TLS also. If 260 the client uses UDP, the resolver won't invest resources in 261 DNS-over-TLS to prevent a potential resource exhaustion attack. 263 * Reuse connection state (if any) and examine resumption 264 considerations 266 * Minimize server-side state (eg, with session tickets) 268 * Need empirical studies on capacity, traffic, attack vectors 270 * Evaluate impact on architecture and footprint expansion 272 * Analyze optimal persistent connection time/time-out 274 * Analyze optimal number of persistent connections recursive 275 resolvers should maintain 277 * Consider operational concerns with respect to capabilities 278 signaling 280 * Develop a profile that has operational advantages for operators 282 *TODO*: Actual requirements - what do operators "want"? 284 5.3. The Implementor / Software Vendor Perspective and Use Cases 286 Implementer requirements follows requirements from user and operator 287 perspectives: 289 o Non-functional requirements, e.g. diversity of implementations 291 o Horizontal vs. vertical scaling, for example similar to http 292 servers 294 o Use of DANE [RFC6698] for authentication: strict vs. opportunistic 296 o Incremental deployment 298 o Cache reuse vs. downgrade? Does the cache need to be partitioned? 299 When can an in-cache answer retrieved via cleartext be served 300 encrypted to a recursive query? 302 o (Use of TCP fast open) - but this might be a requirement for the 303 actual encryption protocol 305 *TODO*: Actual requirements of implementors - essentially, they 306 follow what Operators need? 308 6. Preliminary Requirements 310 The requirements of different interested stakeholders are outlined 311 below. The parenthetical risks and priority levels are intended only 312 to spur discussion. But at a high level the requirements may be 313 summarized as follows: 315 6.1. Mandatory Requirements (Proposed) 317 1. Each implementing party should be able to independently take 318 incremental steps to meet requirements without the need for close 319 coordination (e.g. loosely coupled) (low risk, high priority) 321 2. Implement DoT between a recursive resolver and single level 322 domain authoritative servers (high risk, high priority) 324 3. Implement DNS privacy protections between a recursive resolver 325 and TLD servers (low risk, low priority) 327 4. Implement DNS privacy protections between a recursive resolver 328 and the root servers (low risk, low priority) 330 5. Implement DoT or other DNS privacy protections in a manner that 331 enables operators to perform appropriate performance and security 332 monitoring, conduct relevant research, etc. (high risk, high 333 priority) 335 6. Implement QNAME minimisation in all steps of recursion (medium 336 risk, medium priority) 338 7. The legacy unencrypted DNS protocol (e.g. UDP/TCP port 53) MUST 339 be supported in parallel to DoT (high risk, high priority) 341 8. Recursive resolvers SHOULD opportunistically upgrade recursive 342 query transmissions to DoT when an authoritative server is 343 detected to support DoT (high risk, high priority) 345 9. TLS 1.3 (or later versions) MUST be supported and downgrades from 346 TLS 1.3 to prior versions MUST not occur. 348 6.2. Optional Requirements (Proposed) 350 1. Implement DoT between a recursive resolver and TLD servers (low 351 risk, low priority) 353 2. Implement DoT between a recursive resolver and the root servers 354 (low risk, low priority) 356 3. DNSSEC validation SHOULD be performed 358 4. Users SHOULD have a method for signaling their preferences for 359 (1) exclusively using DNS privacy & encryption, (2) preferring 360 DNS privacy & encryption but falling back to un-encrypted DNS as 361 needed, (3) exclusively using un-encrypted DNS, or other 362 preferences. (Possible reference to DNSSEC DO bit?) 364 5. Authoritative domain administrators SHOULD have a method for 365 signaling their preferences for (1) exclusively using DNS privacy 366 & encryption, (2) preferring DNS privacy & encryption but falling 367 back to un-encrypted DNS as needed, (3) exclusively using un- 368 encrypted DNS, or other preferences. (Possible reference to 369 DNSSEC DO bit?) 371 6.3. Working Group Discussion Needed 373 o Provisioning impacts - operators and vendors say implementation 374 must be zero-provisioning. What does that mean and how should 375 that be articulated as a requirement? 377 o Signaling: Provide some method to signal not just binary support 378 DoT / do not support to allow for certain QTYPES or whatever to 379 use DoT while others may not (e.g. an auth server may want to say 380 in high load that some low risk or low priority queries fallback 381 to unencrypted comms). Is this signaling or negotiation? Perhaps 382 the requirement is ultimately about "Load Shedding" or "Load 383 Management". 385 o Trust anchor/authority: Should this depend only on the DNS, such 386 as DANE, or Certification Authorities? See discussion at 387 https://github.com/alex-nicat/ietf-dprive-phase2-requirements/ 388 issues/13 390 o Rather than say DNS privacy methods should we specifically say no 391 ECS (or not fine-grained ECS), and to do QNAME minimization? 393 o There is a new signaling draft at https://tools.ietf.org/html/ 394 draft-levine-dprive-signal-00 and a prior one at 395 https://tools.ietf.org/html/draft-bortzmeyer-dprive-step-2-05 - 396 are these informative for our requirements? 398 o Is signaling good and/or necessary. 400 6.4. Prioritization of Requirements 402 The preliminary requirements above each have varying levels of risk 403 and so can be prioritized based on that risk. As a result, the 404 highest risk area is the one that involves the greatest potential for 405 surveillance and modification based on the details of the specific 406 step of recursion. This suggests the highest risk and thus highest 407 priority is between a recursive server and first level authoritative 408 server. Lower risks are to TLDs and root servers, with 409 correspondingly lower priority. Support for monitoring and 410 compliance are also high risk since this is operationally critical, 411 and thus should also be considered high priority. 413 6.5. Opportunistic Upgrade to Encryption 415 Opportunistically upgrading to use encryption may be the most viable 416 path to deploy new DNS encryption protocols. This may enable 417 deployment to occur incrementally and without tightly coupled 418 coordination across a diverse global group of very different 419 potential implementors. 421 EDITORIAL NOTE: This paragraph may be unnecessary and could be cut. 422 The exact method by which a recursive resolver determines whether an 423 authoritative server supports DoT has not been specified in this 424 document. But it seems reasonable to imagine that a recursive server 425 might be able to probe authoritative servers on TCP/853 using the DoT 426 protocol and then build a cached list of servers that support DoT so 427 that subsequent queries will upgrade to use DoT (and can fallback if 428 DoT connections subsequently fail). It seems also possible to 429 imagine a method might exist for an authoritative domain to use a TBD 430 resource record or other method to specify whether DoT is supported. 432 6.6. Detection of Availability 434 EDITORIAL NOTE: This section was just moved up. May need some better 435 integration later on. 437 Recursive resolvers typically communicate with many authoritative 438 nameservers. Not every authoritative nameserver will support DoT and 439 not every recursive resolver will support every requirement. How 440 should a recursive resolver determine whether DoT is supported for 441 example? (There may be multiple ways, or none) 443 What scope/granularity should such an availability marker have? 445 o by zone ("all authoritative nameservers in the "example.net" zone 446 support private queries from resolvers") 448 o by identified nameserver ("the nameserver "a.ns.example.net" 449 supports private queries from resolvers") 451 o by IP address ("any nameservers that resolve to 192.0.2.13 support 452 private queries from resolvers") 454 Note that if there is no signal for availability, recursors could 455 still opportunistically try the DNS privacy mechanism, as this is 456 employed by some stub resolvers when they contact their designated 457 recursors. 459 Should a signal of availability also indicate a preference for 460 privacy over availability? i.e., are there distinct ways to signal 461 "DNS-privacy is available" separately from "Only contact this server 462 via DNS-privacy if you understand this signal (though we may continue 463 to support non-private DNS queries for clients that don't understand 464 it)". 466 6.7. Resistance to Downgrade Attack 468 When a connection is opportunistically upgraded to DoT, if a fallback 469 to unencrypted DNS can be possible via a downgrade attack by blocking 470 or modifying TCP/853 communications. In such cases, it may be best 471 to establish a mechanism whereby the authoritative domain can specify 472 their preferred behaviour. This may range from only use DoT and do 473 not fallback to unencrypted DNS, to opportunistically use DoT but 474 fallback in failure, to do not use DoT. The email application layer 475 protocols have similar methods for asserting how email from a 476 particular domain should be treated, so following some of the lessons 477 learned there is likely a good idea. Compare HSTS [RFC6797]? 479 6.8. End-User Policy Propagation 481 EDITORIAL NOTE: This section was just moved up. May need some better 482 integration later on. 484 Like any multi-party protocol (e.g. SMTP), the end user's 485 preferences or policies might or might not be respected by later hops 486 in the chain. But if we have a way to express those preferences, we 487 offer cooperating resolvers at least an opportunity to respect them. 489 WG DISCUSS: Is it better to let auth domains assert whether fallback 490 should be permitted or is that an end user preference or both? The 491 email world might suggest the former while the DNSSEC world the 492 latter. Or specify the standardization of the preferences and their 493 communication and leave it to implementors to decide whether or how 494 to treat those signals? 496 What sorts of preferences or policy might an end-user want to 497 express? for example: 499 o do not identify my general location (e.g. don't send my subnet 500 information (ECS) [RFC7871] data about me when talking to 501 authoritative servers), accepting that reduced localization may 502 result in less localized responses from authoritative Content 503 Delivery Network (CDN) servers and thus slower access to content 505 o prefer DNS privacy over reduced latency (i.e., do not try to do 506 speedups - try opportunistic privacy first and fall back to 507 cleartext only if that fails) 509 o never do non-private authoritative queries on my behalf (for any 510 external queries you need to do to resolve this request, require 511 strict, well-authenticated DNS privacy) 513 How specifically are these preferences be expressed by the client? 514 (e.g. new EDNS0 [RFC6891] options?) Should the recursor have a way 515 to indicate whether: 517 o they are capable of honoring them? 519 o they intend to honor them? 521 o they _did_ honor them over the course of a specific lookup? 522 If a resolver merely forwards a request to another recursor, should 523 it also propagate those preferences/policy? if so, how? 525 This seems similar to [I-D.ietf-uta-smtp-require-tls]. 527 To implement end-user policies, support for signaling of DNS server 528 capabilities is helpful, see for example 529 [I-D.edmonds-dnsop-capabilities]. 531 6.9. Performance and Efficiency 533 o Can authoritative server operators limit resource-exhaustion 534 attacks against private DNS mechanisms from having an impact on 535 traditional (non-private) authoritative DNS availability? (JL: 536 seems easy to implement per host connection limits and implement 537 other standard DDoS protections - again for a later BCP doc) 539 o What are best practices for authoritative server operators that 540 can minimize latency and unavailability? 542 o What are best practices for recursors? 544 7. Security Considerations 546 At this point of the document, the authors have not yet discussed 547 security considerations in detail, as the whole document tends to 548 deal with user privacy, which can be considered part of security. :) 550 8. IANA Considerations 552 This document has no actions for IANA. 554 9. Changelog 556 Note to RFC editor: Remove this entire section before publication. 558 9.1. lmo-dprive-phase2-requirements-00 560 Initial version 562 10. References 564 10.1. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, 568 DOI 10.17487/RFC2119, March 1997, 569 . 571 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 572 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 573 May 2017, . 575 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 576 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 577 January 2019, . 579 10.2. Informative References 581 [I-D.edmonds-dnsop-capabilities] 582 Edmonds, R., "Signaling DNS Capabilities", draft-edmonds- 583 dnsop-capabilities-00 (work in progress), July 2017. 585 [I-D.ietf-uta-smtp-require-tls] 586 Fenton, J., "SMTP Require TLS Option", draft-ietf-uta- 587 smtp-require-tls-09 (work in progress), August 2019. 589 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 590 of Named Entities (DANE) Transport Layer Security (TLS) 591 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 592 2012, . 594 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 595 Transport Security (HSTS)", RFC 6797, 596 DOI 10.17487/RFC6797, November 2012, 597 . 599 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 600 for DNS (EDNS(0))", STD 75, RFC 6891, 601 DOI 10.17487/RFC6891, April 2013, 602 . 604 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 605 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 606 . 608 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 609 Kumari, "Client Subnet in DNS Queries", RFC 7871, 610 DOI 10.17487/RFC7871, May 2016, 611 . 613 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 614 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 615 July 2017, . 617 10.3. URIs 619 [1] https://datatracker.ietf.org/doc/charter-ietf-dprive/ 621 [2] https://datatracker.ietf.org/wg/dprive/about/ 623 Acknowledgments 625 TODO 627 Authors' Addresses 629 Jason Livingood 630 Comcast 632 Email: Jason_Livingood@comcast.com 634 Alexander Mayrhofer 635 nic.at GmbH 637 Email: alex.mayrhofer.ietf@gmail.com 639 Benno Overeinder 640 NLnet Labs 642 Email: benno@NLnetLabs.nl