1 Internet Engineering Task Force (IETF) S. Dickinson
2 Request for Comments: 8932 Sinodun IT
3 BCP: 232 B. Overeinder
4 Category: Best Current Practice R. van Rijswijk-Deij
5 ISSN: 2070-1721 NLnet Labs
6 A. Mankin
7 Salesforce
8 October 2020
9
10
11 Recommendations for DNS Privacy Service Operators
12
13 Abstract
14
15 This document presents operational, policy, and security
16 considerations for DNS recursive resolver operators who choose to
17 offer DNS privacy services. With these recommendations, the operator
18 can make deliberate decisions regarding which services to provide, as
19 well as understanding how those decisions and the alternatives impact
20 the privacy of users.
21
22 This document also presents a non-normative framework to assist
23 writers of a Recursive operator Privacy Statement, analogous to DNS
24 Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
25 described in RFC 6841.
26
27 Status of This Memo
28
29 This memo documents an Internet Best Current Practice.
30
31 This document is a product of the Internet Engineering Task Force
32 (IETF). It represents the consensus of the IETF community. It has
33 received public review and has been approved for publication by the
34 Internet Engineering Steering Group (IESG). Further information on
35 BCPs is available in Section 2 of RFC 7841.
36
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 https://www.rfc-editor.org/info/rfc8932.
40
41 Copyright Notice
42
43 Copyright (c) 2020 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
45
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (https://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
55
56 Table of Contents
57
58 1. Introduction
59 2. Scope
60 3. Privacy-Related Documents
61 4. Terminology
62 5. Recommendations for DNS Privacy Services
63 5.1. On the Wire between Client and Server
64 5.1.1. Transport Recommendations
65 5.1.2. Authentication of DNS Privacy Services
66 5.1.3. Protocol Recommendations
67 5.1.4. DNSSEC
68 5.1.5. Availability
69 5.1.6. Service Options
70 5.1.7. Impact of Encryption on Monitoring by DNS Privacy
71 Service Operators
72 5.1.8. Limitations of Fronting a DNS Privacy Service with a
73 Pure TLS Proxy
74 5.2. Data at Rest on the Server
75 5.2.1. Data Handling
76 5.2.2. Data Minimization of Network Traffic
77 5.2.3. IP Address Pseudonymization and Anonymization Methods
78 5.2.4. Pseudonymization, Anonymization, or Discarding of Other
79 Correlation Data
80 5.2.5. Cache Snooping
81 5.3. Data Sent Onwards from the Server
82 5.3.1. Protocol Recommendations
83 5.3.2. Client Query Obfuscation
84 5.3.3. Data Sharing
85 6. Recursive Operator Privacy Statement (RPS)
86 6.1. Outline of an RPS
87 6.1.1. Policy
88 6.1.2. Practice
89 6.2. Enforcement/Accountability
90 7. IANA Considerations
91 8. Security Considerations
92 9. References
93 9.1. Normative References
94 9.2. Informative References
95 Appendix A. Documents
96 A.1. Potential Increases in DNS Privacy
97 A.2. Potential Decreases in DNS Privacy
98 A.3. Related Operational Documents
99 Appendix B. IP Address Techniques
100 B.1. Categorization of Techniques
101 B.2. Specific Techniques
102 B.2.1. Google Analytics Non-Prefix Filtering
103 B.2.2. dnswasher
104 B.2.3. Prefix-Preserving Map
105 B.2.4. Cryptographic Prefix-Preserving Pseudonymization
106 B.2.5. Top-Hash Subtree-Replicated Anonymization
107 B.2.6. ipcipher
108 B.2.7. Bloom Filters
109 Appendix C. Current Policy and Privacy Statements
110 Appendix D. Example RPS
111 D.1. Policy
112 D.2. Practice
113 Acknowledgements
114 Contributors
115 Authors' Addresses
116
117 1. Introduction
118
119 The Domain Name System (DNS) is at the core of the Internet; almost
120 every activity on the Internet starts with a DNS query (and often
121 several). However, the DNS was not originally designed with strong
122 security or privacy mechanisms. A number of developments have taken
123 place in recent years that aim to increase the privacy of the DNS,
124 and these are now seeing some deployment. This latest evolution of
125 the DNS presents new challenges to operators, and this document
126 attempts to provide an overview of considerations for privacy-focused
127 DNS services.
128
129 In recent years, there has also been an increase in the availability
130 of "public resolvers" [RFC8499], which users may prefer to use
131 instead of the default network resolver, either because they offer a
132 specific feature (e.g., good reachability or encrypted transport) or
133 because the network resolver lacks a specific feature (e.g., strong
134 privacy policy or unfiltered responses). These public resolvers have
135 tended to be at the forefront of adoption of privacy-related
136 enhancements, but it is anticipated that operators of other resolver
137 services will follow.
138
139 Whilst protocols that encrypt DNS messages on the wire provide
140 protection against certain attacks, the resolver operator still has
141 (in principle) full visibility of the query data and transport
142 identifiers for each user. Therefore, a trust relationship (whether
143 explicit or implicit) is assumed to exist between each user and the
144 operator of the resolver(s) used by that user. The ability of the
145 operator to provide a transparent, well-documented, and secure
146 privacy service will likely serve as a major differentiating factor
147 for privacy-conscious users if they make an active selection of which
148 resolver to use.
149
150 It should also be noted that there are both advantages and
151 disadvantages to a user choosing to configure a single resolver (or a
152 fixed set of resolvers) and an encrypted transport to use in all
153 network environments. For example, the user has a clear expectation
154 of which resolvers have visibility of their query data. However,
155 this resolver/transport selection may provide an added mechanism for
156 tracking them as they move across network environments. Commitments
157 from resolver operators to minimize such tracking as users move
158 between networks are also likely to play a role in user selection of
159 resolvers.
160
161 More recently, the global legislative landscape with regard to
162 personal data collection, retention, and pseudonymization has seen
163 significant activity. Providing detailed practice advice about these
164 areas to the operator is out of scope, but Section 5.3.3 describes
165 some mitigations of data-sharing risk.
166
167 This document has two main goals:
168
169 * To provide operational and policy guidance related to DNS over
170 encrypted transports and to outline recommendations for data
171 handling for operators of DNS privacy services.
172
173 * To introduce the Recursive operator Privacy Statement (RPS) and
174 present a framework to assist writers of an RPS. An RPS is a
175 document that an operator should publish that outlines their
176 operational practices and commitments with regard to privacy,
177 thereby providing a means for clients to evaluate both the
178 measurable and claimed privacy properties of a given DNS privacy
179 service. The framework identifies a set of elements and specifies
180 an outline order for them. This document does not, however,
181 define a particular privacy statement, nor does it seek to provide
182 legal advice as to the contents of an RPS.
183
184 A desired operational impact is that all operators (both those
185 providing resolvers within networks and those operating large public
186 services) can demonstrate their commitment to user privacy, thereby
187 driving all DNS resolution services to a more equitable footing.
188 Choices for users would (in this ideal world) be driven by other
189 factors -- e.g., differing security policies or minor differences in
190 operator policy -- rather than gross disparities in privacy concerns.
191
192 Community insight (or judgment?) about operational practices can
193 change quickly, and experience shows that a Best Current Practice
194 (BCP) document about privacy and security is a point-in-time
195 statement. Readers are advised to seek out any updates that apply to
196 this document.
197
198 2. Scope
199
200 "DNS Privacy Considerations" [RFC7626] describes the general privacy
201 issues and threats associated with the use of the DNS by Internet
202 users; much of the threat analysis here is lifted from that document
203 and [RFC6973]. However, this document is limited in scope to best-
204 practice considerations for the provision of DNS privacy services by
205 servers (recursive resolvers) to clients (stub resolvers or
206 forwarders). Choices that are made exclusively by the end user, or
207 those for operators of authoritative nameservers, are out of scope.
208
209 This document includes (but is not limited to) considerations in the
210 following areas:
211
212 1. Data "on the wire" between a client and a server.
213
214 2. Data "at rest" on a server (e.g., in logs).
215
216 3. Data "sent onwards" from the server (either on the wire or shared
217 with a third party).
218
219 Whilst the issues raised here are targeted at those operators who
220 choose to offer a DNS privacy service, considerations for areas 2 and
221 3 could equally apply to operators who only offer DNS over
222 unencrypted transports but who would otherwise like to align with
223 privacy best practice.
224
225 3. Privacy-Related Documents
226
227 There are various documents that describe protocol changes that have
228 the potential to either increase or decrease the privacy properties
229 of the DNS in various ways. Note that this does not imply that some
230 documents are good or bad, better or worse, just that (for example)
231 some features may bring functional benefits at the price of a
232 reduction in privacy, and conversely some features increase privacy
233 with an accompanying increase in complexity. A selection of the most
234 relevant documents is listed in Appendix A for reference.
235
236 4. Terminology
237
238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
240 "OPTIONAL" in this document are to be interpreted as described in BCP
241 14 [RFC2119] [RFC8174] when, and only when, they appear in all
242 capitals, as shown here.
243
244 DNS terminology is as described in [RFC8499], except with regard to
245 the definition of privacy-enabling DNS server in Section 6 of
246 [RFC8499]. In this document we use the full definition of a DNS over
247 (D)TLS privacy-enabling DNS server as given in [RFC8310], i.e., that
248 such a server should also offer at least one of the credentials
249 described in Section 8 of [RFC8310] and implement the (D)TLS profile
250 described in Section 9 of [RFC8310].
251
252 Other Terms:
253
254 RPS: Recursive operator Privacy Statement; see Section 6.
255
256 DNS privacy service: The service that is offered via a privacy-
257 enabling DNS server and is documented either in an informal
258 statement of policy and practice with regard to users privacy or a
259 formal RPS.
260
261 5. Recommendations for DNS Privacy Services
262
263 In the following sections, we first outline the threats relevant to
264 the specific topic and then discuss the potential actions that can be
265 taken to mitigate them.
266
267 We describe two classes of threats:
268
269 * Threats described in [RFC6973], "Privacy Considerations for
270 Internet Protocols"
271
272 - Privacy terminology, threats to privacy, and mitigations as
273 described in Sections 3, 5, and 6 of [RFC6973].
274
275 * DNS Privacy Threats
276
277 - These are threats to the users and operators of DNS privacy
278 services that are not directly covered by [RFC6973]. These may
279 be more operational in nature, such as certificate-management
280 or service-availability issues.
281
282 We describe three classes of actions that operators of DNS privacy
283 services can take:
284
285 * Threat mitigation for well-understood and documented privacy
286 threats to the users of the service and, in some cases, the
287 operators of the service.
288
289 * Optimization of privacy services from an operational or management
290 perspective.
291
292 * Additional options that could further enhance the privacy and
293 usability of the service.
294
295 This document does not specify policy, only best practice. However,
296 for DNS privacy services to be considered compliant with these best-
297 practice guidelines, they SHOULD implement (where appropriate) all:
298
299 * Threat mitigations to be minimally compliant.
300
301 * Optimizations to be moderately compliant.
302
303 * Additional options to be maximally compliant.
304
305 The rest of this document does not use normative language but instead
306 refers only to the three differing classes of action that correspond
307 to the three named levels of compliance stated above. However,
308 compliance (to the indicated level) remains a normative requirement.
309
310 5.1. On the Wire between Client and Server
311
312 In this section, we consider both data on the wire and the service
313 provided to the client.
314
315 5.1.1. Transport Recommendations
316
317 Threats described in [RFC6973]:
318 Surveillance:
319 Passive surveillance of traffic on the wire.
320
321 DNS Privacy Threats:
322 Active injection of spurious data or traffic.
323
324 Mitigations:
325 A DNS privacy service can mitigate these threats by providing
326 service over one or more of the following transports:
327
328 * DNS over TLS (DoT) [RFC7858] [RFC8310].
329
330 * DNS over HTTPS (DoH) [RFC8484].
331
332 It is noted that a DNS privacy service can also be provided over DNS
333 over DTLS [RFC8094]; however, this is an Experimental specification,
334 and there are no known implementations at the time of writing.
335
336 It is also noted that DNS privacy service might be provided over
337 DNSCrypt [DNSCrypt], IPsec, or VPNs. However, there are no specific
338 RFCs that cover the use of these transports for DNS, and any
339 discussion of best practice for providing such a service is out of
340 scope for this document.
341
342 Whilst encryption of DNS traffic can protect against active injection
343 on the paths traversed by the encrypted connection, this does not
344 diminish the need for DNSSEC; see Section 5.1.4.
345
346 5.1.2. Authentication of DNS Privacy Services
347
348 Threats described in [RFC6973]:
349 Surveillance:
350 Active attacks on client resolver configuration.
351
352 Mitigations:
353 DNS privacy services should ensure clients can authenticate the
354 server. Note that this, in effect, commits the DNS privacy
355 service to a public identity users will trust.
356
357 When using DoT, clients that select a "Strict Privacy" usage
358 profile [RFC8310] (to mitigate the threat of active attack on the
359 client) require the ability to authenticate the DNS server. To
360 enable this, DNS privacy services that offer DoT need to provide
361 credentials that will be accepted by the client's trust model, in
362 the form of either X.509 certificates [RFC5280] or Subject Public
363 Key Info (SPKI) pin sets [RFC8310].
364
365 When offering DoH [RFC8484], HTTPS requires authentication of the
366 server as part of the protocol.
367
368 5.1.2.1. Certificate Management
369
370 Anecdotal evidence to date highlights the management of certificates
371 as one of the more challenging aspects for operators of traditional
372 DNS resolvers that choose to additionally provide a DNS privacy
373 service, as management of such credentials is new to those DNS
374 operators.
375
376 It is noted that SPKI pin set management is described in [RFC7858]
377 but that key-pinning mechanisms in general have fallen out of favor
378 operationally for various reasons, such as the logistical overhead of
379 rolling keys.
380
381 DNS Privacy Threats:
382 * Invalid certificates, resulting in an unavailable service,
383 which might force a user to fall back to cleartext.
384
385 * Misidentification of a server by a client -- e.g., typos in DoH
386 URL templates [RFC8484] or authentication domain names
387 [RFC8310] that accidentally direct clients to attacker-
388 controlled servers.
389
390 Mitigations:
391 It is recommended that operators:
392
393 * Follow the guidance in Section 6.5 of [RFC7525] with regard to
394 certificate revocation.
395
396 * Automate the generation, publication, and renewal of
397 certificates. For example, Automatic Certificate Management
398 Environment (ACME) [RFC8555] provides a mechanism to actively
399 manage certificates through automation and has been implemented
400 by a number of certificate authorities.
401
402 * Monitor certificates to prevent accidental expiration of
403 certificates.
404
405 * Choose a short, memorable authentication domain name for the
406 service.
407
408 5.1.3. Protocol Recommendations
409
410 5.1.3.1. DoT
411
412 DNS Privacy Threats:
413 * Known attacks on TLS, such as those described in [RFC7457].
414
415 * Traffic analysis, for example: [Pitfalls-of-DNS-Encryption]
416 (focused on DoT).
417
418 * Potential for client tracking via transport identifiers.
419
420 * Blocking of well-known ports (e.g., 853 for DoT).
421
422 Mitigations:
423 In the case of DoT, TLS profiles from Section 9 of [RFC8310] and
424 the "Countermeasures to DNS Traffic Analysis" from Section 11.1 of
425 [RFC8310] provide strong mitigations. This includes but is not
426 limited to:
427
428 * Adhering to [RFC7525].
429
430 * Implementing only (D)TLS 1.2 or later, as specified in
431 [RFC8310].
432
433 * Implementing Extension Mechanisms for DNS (EDNS(0)) Padding
434 [RFC7830] using the guidelines in [RFC8467] or a successor
435 specification.
436
437 * Servers should not degrade in any way the query service level
438 provided to clients that do not use any form of session
439 resumption mechanism, such as TLS session resumption [RFC5077]
440 with TLS 1.2 (Section 2.2 of [RFC8446]) or Domain Name System
441 (DNS) Cookies [RFC7873].
442
443 * A DoT privacy service on both port 853 and 443. If the
444 operator deploys DoH on the same IP address, this requires the
445 use of the "dot" Application-Layer Protocol Negotiation (ALPN)
446 value [dot-ALPN].
447
448 Optimizations:
449 * Concurrent processing of pipelined queries, returning responses
450 as soon as available, potentially out of order, as specified in
451 [RFC7766]. This is often called "OOOR" -- out-of-order
452 responses (providing processing performance similar to HTTP
453 multiplexing).
454
455 * Management of TLS connections to optimize performance for
456 clients using [RFC7766] and EDNS(0) Keepalive [RFC7828]
457
458 Additional Options:
459 Management of TLS connections to optimize performance for clients
460 using DNS Stateful Operations [RFC8490].
461
462 5.1.3.2. DoH
463
464 DNS Privacy Threats:
465 * Known attacks on TLS, such as those described in [RFC7457].
466
467 * Traffic analysis, for example: [DNS-Privacy-not-so-private]
468 (focused on DoH).
469
470 * Potential for client tracking via transport identifiers.
471
472 Mitigations:
473 * Clients must be able to forgo the use of HTTP cookies [RFC6265]
474 and still use the service.
475
476 * Use of HTTP/2 padding and/or EDNS(0) padding, as described in
477 Section 9 of [RFC8484].
478
479 * Clients should not be required to include any headers beyond
480 the absolute minimum to obtain service from a DoH server. (See
481 Section 6.1 of [BUILD-W-HTTP].)
482
483 5.1.4. DNSSEC
484
485 DNS Privacy Threats:
486 Users may be directed to bogus IP addresses that, depending on the
487 application, protocol, and authentication method, might lead users
488 to reveal personal information to attackers. One example is a
489 website that doesn't use TLS or whose TLS authentication can
490 somehow be subverted.
491
492 Mitigations:
493 All DNS privacy services must offer a DNS privacy service that
494 performs Domain Name System Security Extensions (DNSSEC)
495 validation. In addition, they must be able to provide the DNSSEC
496 Resource Records (RRs) to the client so that it can perform its
497 own validation.
498
499 The addition of encryption to DNS does not remove the need for DNSSEC
500 [RFC4033]; they are independent and fully compatible protocols, each
501 solving different problems. The use of one does not diminish the
502 need nor the usefulness of the other.
503
504 While the use of an authenticated and encrypted transport protects
505 origin authentication and data integrity between a client and a DNS
506 privacy service, it provides no proof (for a nonvalidating client)
507 that the data provided by the DNS privacy service was actually DNSSEC
508 authenticated. As with cleartext DNS, the user is still solely
509 trusting the Authentic Data (AD) bit (if present) set by the
510 resolver.
511
512 It should also be noted that the use of an encrypted transport for
513 DNS actually solves many of the practical issues encountered by DNS
514 validating clients -- e.g., interference by middleboxes with
515 cleartext DNS payloads is completely avoided. In this sense, a
516 validating client that uses a DNS privacy service that supports
517 DNSSEC has a far simpler task in terms of DNSSEC roadblock avoidance
518 [RFC8027].
519
520 5.1.5. Availability
521
522 DNS Privacy Threats:
523 A failing DNS privacy service could force the user to switch
524 providers, fall back to cleartext, or accept no DNS service for
525 the duration of the outage.
526
527 Mitigations:
528 A DNS privacy service should strive to engineer encrypted services
529 to the same availability level as any unencrypted services they
530 provide. Particular care should to be taken to protect DNS
531 privacy services against denial-of-service (DoS) attacks, as
532 experience has shown that unavailability of DNS resolving because
533 of attacks is a significant motivation for users to switch
534 services. See, for example, Section IV-C of
535 [Passive-Observations-of-a-Large-DNS].
536
537 Techniques such as those described in Section 10 of [RFC7766] can
538 be of use to operators to defend against such attacks.
539
540 5.1.6. Service Options
541
542 DNS Privacy Threats:
543 Unfairly disadvantaging users of the privacy service with respect
544 to the services available. This could force the user to switch
545 providers, fall back to cleartext, or accept no DNS service for
546 the duration of the outage.
547
548 Mitigations:
549 A DNS privacy service should deliver the same level of service as
550 offered on unencrypted channels in terms of options such as
551 filtering (or lack thereof), DNSSEC validation, etc.
552
553 5.1.7. Impact of Encryption on Monitoring by DNS Privacy Service
554 Operators
555
556 DNS Privacy Threats:
557 Increased use of encryption can impact a DNS privacy service
558 operator's ability to monitor traffic and therefore manage their
559 DNS servers [RFC8404].
560
561 Many monitoring solutions for DNS traffic rely on the plaintext
562 nature of this traffic and work by intercepting traffic on the wire,
563 either using a separate view on the connection between clients and
564 the resolver, or as a separate process on the resolver system that
565 inspects network traffic. Such solutions will no longer function
566 when traffic between clients and resolvers is encrypted. Many DNS
567 privacy service operators still need to inspect DNS traffic -- e.g.,
568 to monitor for network security threats. Operators may therefore
569 need to invest in an alternative means of monitoring that relies on
570 either the resolver software directly, or exporting DNS traffic from
571 the resolver using, for example, [dnstap].
572
573 Optimization:
574 When implementing alternative means for traffic monitoring,
575 operators of a DNS privacy service should consider using privacy-
576 conscious means to do so. See Section 5.2 for more details on
577 data handling and the discussion on the use of Bloom Filters in
578 Appendix B.
579
580 5.1.8. Limitations of Fronting a DNS Privacy Service with a Pure TLS
581 Proxy
582
583 DNS Privacy Threats:
584 * Limited ability to manage or monitor incoming connections using
585 DNS-specific techniques.
586
587 * Misconfiguration (e.g., of the target-server address in the
588 proxy configuration) could lead to data leakage if the proxy-
589 to-target-server path is not encrypted.
590
591 Optimization:
592 Some operators may choose to implement DoT using a TLS proxy
593 (e.g., [nginx], [haproxy], or [stunnel]) in front of a DNS
594 nameserver because of proven robustness and capacity when handling
595 large numbers of client connections, load-balancing capabilities,
596 and good tooling. Currently, however, because such proxies
597 typically have no specific handling of DNS as a protocol over TLS
598 or DTLS, using them can restrict traffic management at the proxy
599 layer and the DNS server. For example, all traffic received by a
600 nameserver behind such a proxy will appear to originate from the
601 proxy, and DNS techniques such as Access Control Lists (ACLs),
602 Response Rate Limiting (RRL), or DNS64 [RFC6147] will be hard or
603 impossible to implement in the nameserver.
604
605 Operators may choose to use a DNS-aware proxy, such as [dnsdist],
606 that offers custom options (similar to those proposed in
607 [DNS-XPF]) to add source information to packets to address this
608 shortcoming. It should be noted that such options potentially
609 significantly increase the leaked information in the event of a
610 misconfiguration.
611
612 5.2. Data at Rest on the Server
613
614 5.2.1. Data Handling
615
616 Threats described in [RFC6973]:
617 * Surveillance.
618
619 * Stored-data compromise.
620
621 * Correlation.
622
623 * Identification.
624
625 * Secondary use.
626
627 * Disclosure.
628
629 Other Threats
630 * Contravention of legal requirements not to process user data.
631
632 Mitigations:
633 The following are recommendations relating to common activities
634 for DNS service operators; in all cases, data retention should be
635 minimized or completely avoided if possible for DNS privacy
636 services. If data is retained, it should be encrypted and either
637 aggregated, pseudonymized, or anonymized whenever possible. In
638 general, the principle of data minimization described in [RFC6973]
639 should be applied.
640
641 * Transient data (e.g., data used for real-time monitoring and
642 threat analysis, which might be held only in memory) should be
643 retained for the shortest possible period deemed operationally
644 feasible.
645
646 * The retention period of DNS traffic logs should be only as long
647 as is required to sustain operation of the service and meet
648 regulatory requirements, to the extent that they exist.
649
650 * DNS privacy services should not track users except for the
651 particular purpose of detecting and remedying technically
652 malicious (e.g., DoS) or anomalous use of the service.
653
654 * Data access should be minimized to only those personnel who
655 require access to perform operational duties. It should also
656 be limited to anonymized or pseudonymized data where
657 operationally feasible, with access to full logs (if any are
658 held) only permitted when necessary.
659
660 Optimizations:
661 * Consider use of full-disk encryption for logs and data-capture
662 storage.
663
664 5.2.2. Data Minimization of Network Traffic
665
666 Data minimization refers to collecting, using, disclosing, and
667 storing the minimal data necessary to perform a task, and this can be
668 achieved by removing or obfuscating privacy-sensitive information in
669 network traffic logs. This is typically personal data or data that
670 can be used to link a record to an individual, but it may also
671 include other confidential information -- for example, on the
672 structure of an internal corporate network.
673
674 The problem of effectively ensuring that DNS traffic logs contain no
675 or minimal privacy-sensitive information is not one that currently
676 has a generally agreed solution or any standards to inform this
677 discussion. This section presents an overview of current techniques
678 to simply provide reference on the current status of this work.
679
680 Research into data minimization techniques (and particularly IP
681 address pseudonymization/anonymization) was sparked in the late 1990s
682 / early 2000s, partly driven by the desire to share significant
683 corpuses of traffic captures for research purposes. Several
684 techniques reflecting different requirements in this area and
685 different performance/resource trade-offs emerged over the course of
686 the decade. Developments over the last decade have been both a
687 blessing and a curse; the large increase in size between an IPv4 and
688 an IPv6 address, for example, renders some techniques impractical,
689 but also makes available a much larger amount of input entropy, the
690 better to resist brute-force re-identification attacks that have
691 grown in practicality over the period.
692
693 Techniques employed may be broadly categorized as either
694 anonymization or pseudonymization. The following discussion uses the
695 definitions from [RFC6973], Section 3, with additional observations
696 from [van-Dijkhuizen-et-al].
697
698 * Anonymization. To enable anonymity of an individual, there must
699 exist a set of individuals that appear to have the same
700 attribute(s) as the individual. To the attacker or the observer,
701 these individuals must appear indistinguishable from each other.
702
703 * Pseudonymization. The true identity is deterministically replaced
704 with an alternate identity (a pseudonym). When the
705 pseudonymization schema is known, the process can be reversed, so
706 the original identity becomes known again.
707
708 In practice, there is a fine line between the two; for example, it is
709 difficult to categorize a deterministic algorithm for data
710 minimization of IP addresses that produces a group of pseudonyms for
711 a single given address.
712
713 5.2.3. IP Address Pseudonymization and Anonymization Methods
714
715 A major privacy risk in DNS is connecting DNS queries to an
716 individual, and the major vector for this in DNS traffic is the
717 client IP address.
718
719 There is active discussion in the space of effective pseudonymization
720 of IP addresses in DNS traffic logs; however, there seems to be no
721 single solution that is widely recognized as suitable for all or most
722 use cases. There are also as yet no standards for this that are
723 unencumbered by patents.
724
725 Appendix B provides a more detailed survey of various techniques
726 employed or under development in 2020.
727
728 5.2.4. Pseudonymization, Anonymization, or Discarding of Other
729 Correlation Data
730
731 DNS Privacy Threats:
732 * Fingerprinting of the client OS via various means, including:
733 IP TTL/Hoplimit, TCP parameters (e.g., window size, Explicit
734 Congestion Notification (ECN) support, selective acknowledgment
735 (SACK)), OS-specific DNS query patterns (e.g., for network
736 connectivity, captive portal detection, or OS-specific
737 updates).
738
739 * Fingerprinting of the client application or TLS library by, for
740 example, HTTP headers (e.g., User-Agent, Accept, Accept-
741 Encoding), TLS version/Cipher-suite combinations, or other
742 connection parameters.
743
744 * Correlation of queries on multiple TCP sessions originating
745 from the same IP address.
746
747 * Correlating of queries on multiple TLS sessions originating
748 from the same client, including via session-resumption
749 mechanisms.
750
751 * Resolvers _might_ receive client identifiers -- e.g., Media
752 Access Control (MAC) addresses in EDNS(0) options. Some
753 customer premises equipment (CPE) devices are known to add them
754 [MAC-address-EDNS].
755
756 Mitigations:
757 * Data minimization or discarding of such correlation data.
758
759 5.2.5. Cache Snooping
760
761 Threats described in [RFC6973]:
762 Surveillance:
763 Profiling of client queries by malicious third parties.
764
765 Mitigations:
766 See [ISC-Knowledge-database-on-cache-snooping] for an example
767 discussion on defending against cache snooping. Options proposed
768 include limiting access to a server and limiting nonrecursive
769 queries.
770
771 5.3. Data Sent Onwards from the Server
772
773 In this section, we consider both data sent on the wire in upstream
774 queries and data shared with third parties.
775
776 5.3.1. Protocol Recommendations
777
778 Threats described in [RFC6973]:
779 Surveillance:
780 Transmission of identifying data upstream.
781
782 Mitigations:
783 The server should:
784
785 * implement QNAME minimization [RFC7816].
786
787 * honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the
788 EDNS(0) Client Subnet (ECS) option ([RFC7871], Section 7.1.2).
789 This is as specified in [RFC8310] for DoT but applicable to any
790 DNS privacy service.
791
792 Optimizations:
793 As per Section 2 of [RFC7871], the server should either:
794
795 * not use the ECS option in upstream queries at all, or
796
797 * offer alternative services, one that sends ECS and one that
798 does not.
799
800 If operators do offer a service that sends the ECS options upstream,
801 they should use the shortest prefix that is operationally feasible
802 and ideally use a policy of allowlisting upstream servers to which to
803 send ECS in order to reduce data leakage. Operators should make
804 clear in any policy statement what prefix length they actually send
805 and the specific policy used.
806
807 Allowlisting has the benefit that not only does the operator know
808 which upstream servers can use ECS, but also the operator can decide
809 which upstream servers apply privacy policies that the operator is
810 happy with. However, some operators consider allowlisting to incur
811 significant operational overhead compared to dynamic detection of ECS
812 support on authoritative servers.
813
814 Additional options:
815
816 * "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] and
817 "NXDOMAIN: There Really Is Nothing Underneath" [RFC8020] to reduce
818 the number of queries to authoritative servers to increase
819 privacy.
820
821 * Run a local copy of the root zone [RFC8806] to avoid making
822 queries to the root servers that might leak information.
823
824 5.3.2. Client Query Obfuscation
825
826 Additional options:
827
828 Since queries from recursive resolvers to authoritative servers are
829 performed using cleartext (at the time of writing), resolver services
830 need to consider the extent to which they may be directly leaking
831 information about their client community via these upstream queries
832 and what they can do to mitigate this further. Note that, even when
833 all the relevant techniques described above are employed, there may
834 still be attacks possible -- e.g., [Pitfalls-of-DNS-Encryption]. For
835 example, a resolver with a very small community of users risks
836 exposing data in this way and ought to obfuscate this traffic by
837 mixing it with "generated" traffic to make client characterization
838 harder. The resolver could also employ aggressive prefetch
839 techniques as a further measure to counter traffic analysis.
840
841 At the time of writing, there are no standardized or widely
842 recognized techniques to perform such obfuscation or bulk prefetches.
843
844 Another technique that particularly small operators may consider is
845 forwarding local traffic to a larger resolver (with a privacy policy
846 that aligns with their own practices) over an encrypted protocol, so
847 that the upstream queries are obfuscated among those of the large
848 resolver.
849
850 5.3.3. Data Sharing
851
852 Threats described in [RFC6973]:
853 * Surveillance.
854
855 * Stored-data compromise.
856
857 * Correlation.
858
859 * Identification.
860
861 * Secondary use.
862
863 * Disclosure.
864
865 DNS Privacy Threats:
866 Contravention of legal requirements not to process user data.
867
868 Mitigations:
869 Operators should not share identifiable data with third parties.
870
871 If operators choose to share identifiable data with third parties
872 in specific circumstances, they should publish the terms under
873 which data is shared.
874
875 Operators should consider including specific guidelines for the
876 collection of aggregated and/or anonymized data for research
877 purposes, within or outside of their own organization. This can
878 benefit not only the operator (through inclusion in novel
879 research) but also the wider Internet community. See the policy
880 published by SURFnet [SURFnet-policy] on data sharing for research
881 as an example.
882
883 6. Recursive Operator Privacy Statement (RPS)
884
885 To be compliant with this Best Current Practice document, a DNS
886 recursive operator SHOULD publish a Recursive operator Privacy
887 Statement (RPS). Adopting the outline, and including the headings in
888 the order provided, is a benefit to persons comparing RPSs from
889 multiple operators.
890
891 Appendix C provides a comparison of some existing policy and privacy
892 statements.
893
894 6.1. Outline of an RPS
895
896 The contents of Sections 6.1.1 and 6.1.2 are non-normative, other
897 than the order of the headings. Material under each topic is present
898 to assist the operator developing their own RPS. This material:
899
900 * Relates _only_ to matters around the technical operation of DNS
901 privacy services, and no other matters.
902
903 * Does not attempt to offer an exhaustive list for the contents of
904 an RPS.
905
906 * Is not intended to form the basis of any legal/compliance
907 documentation.
908
909 Appendix D provides an example (also non-normative) of an RPS
910 statement for a specific operator scenario.
911
912 6.1.1. Policy
913
914 1. Treatment of IP addresses. Make an explicit statement that IP
915 addresses are treated as personal data.
916
917 2. Data collection and sharing. Specify clearly what data
918 (including IP addresses) is:
919
920 * Collected and retained by the operator, and for what period it
921 is retained.
922
923 * Shared with partners.
924
925 * Shared, sold, or rented to third parties.
926
927 In each case, specify whether data is aggregated, pseudonymized,
928 or anonymized and the conditions of data transfer. Where
929 possible provide details of the techniques used for the above
930 data minimizations.
931
932 3. Exceptions. Specify any exceptions to the above -- for example,
933 technically malicious or anomalous behavior.
934
935 4. Associated entities. Declare and explicitly enumerate any
936 partners, third-party affiliations, or sources of funding.
937
938 5. Correlation. Whether user DNS data is correlated or combined
939 with any other personal information held by the operator.
940
941 6. Result filtering. This section should explain whether the
942 operator filters, edits, or alters in any way the replies that it
943 receives from the authoritative servers for each DNS zone before
944 forwarding them to the clients. For each category listed below,
945 the operator should also specify how the filtering lists are
946 created and managed, whether it employs any third-party sources
947 for such lists, and which ones.
948
949 * Specify if any replies are being filtered out or altered for
950 network- and computer-security reasons (e.g., preventing
951 connections to malware-spreading websites or botnet control
952 servers).
953
954 * Specify if any replies are being filtered out or altered for
955 mandatory legal reasons, due to applicable legislation or
956 binding orders by courts and other public authorities.
957
958 * Specify if any replies are being filtered out or altered for
959 voluntary legal reasons, due to an internal policy by the
960 operator aiming at reducing potential legal risks.
961
962 * Specify if any replies are being filtered out or altered for
963 any other reason, including commercial ones.
964
965 6.1.2. Practice
966
967 Communicate the current operational practices of the service.
968
969 1. Deviations. Specify any temporary or permanent deviations from
970 the policy for operational reasons.
971
972 2. Client-facing capabilities. With reference to each subsection of
973 Section 5.1, provide specific details of which capabilities
974 (transport, DNSSEC, padding, etc.) are provided on which client-
975 facing addresses/port combination or DoH URI template. For
976 Section 5.1.2, clearly specify which specific authentication
977 mechanisms are supported for each endpoint that offers DoT:
978
979 a. The authentication domain name to be used (if any).
980
981 b. The SPKI pin sets to be used (if any) and policy for rolling
982 keys.
983
984 3. Upstream capabilities. With reference to Section 5.3, provide
985 specific details of which capabilities are provided upstream for
986 data sent to authoritative servers.
987
988 4. Support. Provide contact/support information for the service.
989
990 5. Data Processing. This section can optionally communicate links
991 to, and the high-level contents of, any separate statements the
992 operator has published that cover applicable data-processing
993 legislation or agreements with regard to the location(s) of
994 service provision.
995
996 6.2. Enforcement/Accountability
997
998 Transparency reports may help with building user trust that operators
999 adhere to their policies and practices.
1000
1001 Where possible, independent monitoring or analysis could be performed
1002 of:
1003
1004 * ECS, QNAME minimization, EDNS(0) padding, etc.
1005
1006 * Filtering.
1007
1008 * Uptime.
1009
1010 This is by analogy with several TLS or website-analysis tools that
1011 are currently available -- e.g., [SSL-Labs] or [Internet.nl].
1012
1013 Additionally, operators could choose to engage the services of a
1014 third-party auditor to verify their compliance with their published
1015 RPS.
1016
1017 7. IANA Considerations
1018
1019 This document has no IANA actions.
1020
1021 8. Security Considerations
1022
1023 Security considerations for DNS over TCP are given in [RFC7766], many
1024 of which are generally applicable to session-based DNS. Guidance on
1025 operational requirements for DNS over TCP are also available in
1026 [DNS-OVER-TCP]. Security considerations for DoT are given in
1027 [RFC7858] and [RFC8310], and those for DoH in [RFC8484].
1028
1029 Security considerations for DNSSEC are given in [RFC4033], [RFC4034],
1030 and [RFC4035].
1031
1032 9. References
1033
1034 9.1. Normative References
1035
1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1037 Requirement Levels", BCP 14, RFC 2119,
1038 DOI 10.17487/RFC2119, March 1997,
1039 <https://www.rfc-editor.org/info/rfc2119>.
1040
1041 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1042 Rose, "DNS Security Introduction and Requirements",
1043 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1044 <https://www.rfc-editor.org/info/rfc4033>.
1045
1046 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1047 Housley, R., and W. Polk, "Internet X.509 Public Key
1048 Infrastructure Certificate and Certificate Revocation List
1049 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1050 <https://www.rfc-editor.org/info/rfc5280>.
1051
1052 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
1053 Morris, J., Hansen, M., and R. Smith, "Privacy
1054 Considerations for Internet Protocols", RFC 6973,
1055 DOI 10.17487/RFC6973, July 2013,
1056 <https://www.rfc-editor.org/info/rfc6973>.
1057
1058 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
1059 Known Attacks on Transport Layer Security (TLS) and
1060 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
1061 February 2015, <https://www.rfc-editor.org/info/rfc7457>.
1062
1063 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
1064 "Recommendations for Secure Use of Transport Layer
1065 Security (TLS) and Datagram Transport Layer Security
1066 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
1067 2015, <https://www.rfc-editor.org/info/rfc7525>.
1068
1069 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
1070 D. Wessels, "DNS Transport over TCP - Implementation
1071 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
1072 <https://www.rfc-editor.org/info/rfc7766>.
1073
1074 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
1075 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
1076 <https://www.rfc-editor.org/info/rfc7816>.
1077
1078 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
1079 edns-tcp-keepalive EDNS0 Option", RFC 7828,
1080 DOI 10.17487/RFC7828, April 2016,
1081 <https://www.rfc-editor.org/info/rfc7828>.
1082
1083 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
1084 DOI 10.17487/RFC7830, May 2016,
1085 <https://www.rfc-editor.org/info/rfc7830>.
1086
1087 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
1088 and P. Hoffman, "Specification for DNS over Transport
1089 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
1090 2016, <https://www.rfc-editor.org/info/rfc7858>.
1091
1092 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
1093 Kumari, "Client Subnet in DNS Queries", RFC 7871,
1094 DOI 10.17487/RFC7871, May 2016,
1095 <https://www.rfc-editor.org/info/rfc7871>.
1096
1097 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
1098 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
1099 November 2016, <https://www.rfc-editor.org/info/rfc8020>.
1100
1101 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1102 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1103 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1104
1105 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
1106 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
1107 July 2017, <https://www.rfc-editor.org/info/rfc8198>.
1108
1109 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
1110 for DNS over TLS and DNS over DTLS", RFC 8310,
1111 DOI 10.17487/RFC8310, March 2018,
1112 <https://www.rfc-editor.org/info/rfc8310>.
1113
1114 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
1115 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
1116 October 2018, <https://www.rfc-editor.org/info/rfc8467>.
1117
1118 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
1119 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
1120 <https://www.rfc-editor.org/info/rfc8484>.
1121
1122 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
1123 Lemon, T., and T. Pusateri, "DNS Stateful Operations",
1124 RFC 8490, DOI 10.17487/RFC8490, March 2019,
1125 <https://www.rfc-editor.org/info/rfc8490>.
1126
1127 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
1128 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
1129 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
1130
1131 [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
1132 a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
1133 <https://www.rfc-editor.org/info/rfc8806>.
1134
1135 9.2. Informative References
1136
1137 [Bloom-filter]
1138 van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L.
1139 Allodi, "Privacy-Conscious Threat Intelligence Using
1140 DNSBLOOM", IFIP/IEEE International Symposium on Integrated
1141 Network Management (IM2019), 2019,
1142 <http://dl.ifip.org/db/conf/im/im2019/189282.pdf>.
1143
1144 [Brekne-and-Arnes]
1145 Brekne, T. and A. Årnes, "Circumventing IP-address
1146 pseudonymization", Communications and Computer Networks,
1147 2005, <https://pdfs.semanticscholar.org/7b34/12c951cebe71c
1148 d2cddac5fda164fb2138a44.pdf>.
1149
1150 [BUILD-W-HTTP]
1151 Nottingham, M., "Building Protocols with HTTP", Work in
1152 Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09,
1153 1 November 2019, <https://tools.ietf.org/html/draft-ietf-
1154 httpbis-bcp56bis-09>.
1155
1156 [Crypto-PAn]
1157 CESNET, "Crypto-PAn", commit 636b237, March 2015,
1158 <https://github.com/CESNET/ipfixcol/tree/master/base/src/
1159 intermediate/anonymization/Crypto-PAn>.
1160
1161 [DNS-OVER-TCP]
1162 Kristoff, J. and D. Wessels, "DNS Transport over TCP -
1163 Operational Requirements", Work in Progress, Internet-
1164 Draft, draft-ietf-dnsop-dns-tcp-requirements-06, 6 May
1165 2020, <https://tools.ietf.org/html/draft-ietf-dnsop-dns-
1166 tcp-requirements-06>.
1167
1168 [DNS-Privacy-not-so-private]
1169 Silby, S., Juarez, M., Vallina-Rodriguez, N., and C.
1170 Troncoso, "DNS Privacy not so private: the traffic
1171 analysis perspective.", Privacy Enhancing
1172 Technologies Symposium, 2018,
1173 <https://petsymposium.org/2018/files/hotpets/4-siby.pdf>.
1174
1175 [DNS-XPF] Bellis, R., Dijk, P. V., and R. Gacogne, "DNS X-Proxied-
1176 For", Work in Progress, Internet-Draft, draft-bellis-
1177 dnsop-xpf-04, 5 March 2018,
1178 <https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04>.
1179
1180 [DNSCrypt] "DNSCrypt - Official Project Home Page",
1181 <https://www.dnscrypt.org>.
1182
1183 [dnsdist] PowerDNS, "dnsdist Overview", <https://dnsdist.org>.
1184
1185 [dnstap] "dnstap", <https://dnstap.info>.
1186
1187 [DoH-resolver-policy]
1188 Mozilla, "Security/DOH-resolver-policy", 2019,
1189 <https://wiki.mozilla.org/Security/DOH-resolver-policy>.
1190
1191 [dot-ALPN] IANA, "Transport Layer Security (TLS) Extensions: TLS
1192 Application-Layer Protocol Negotiation (ALPN) Protocol
1193 IDs", <https://www.iana.org/assignments/tls-extensiontype-
1194 values>.
1195
1196 [Geolocation-Impact-Assessment]
1197 Conversion Works, "Anonymize IP Geolocation Accuracy
1198 Impact Assessment", 19 May 2017,
1199 <https://www.conversionworks.co.uk/blog/2017/05/19/
1200 anonymize-ip-geo-impact-test/>.
1201
1202 [haproxy] "HAProxy - The Reliable, High Performance TCP/HTTP Load
1203 Balancer", <https://www.haproxy.org/>.
1204
1205 [Harvan] Harvan, M., "Prefix- and Lexicographical-order-preserving
1206 IP Address Anonymization", IEEE/IFIP Network Operations
1207 and Management Symposium, DOI 10.1109/NOMS.2006.1687580,
1208 2006, <http://mharvan.net/talks/noms-ip_anon.pdf>.
1209
1210 [Internet.nl]
1211 Internet.nl, "Internet.nl Is Your Internet Up To Date?",
1212 2019, <https://internet.nl>.
1213
1214 [IP-Anonymization-in-Analytics]
1215 Google, "IP Anonymization in Analytics", 2019,
1216 <https://support.google.com/analytics/
1217 answer/2763052?hl=en>.
1218
1219 [ipcipher1]
1220 Hubert, B., "On IP address encryption: security analysis
1221 with respect for privacy", Medium, 7 May 2017,
1222 <https://medium.com/@bert.hubert/on-ip-address-encryption-
1223 security-analysis-with-respect-for-privacy-dabe1201b476>.
1224
1225 [ipcipher2]
1226 PowerDNS, "ipcipher", commit fd47abe, 13 February 2018,
1227 <https://github.com/PowerDNS/ipcipher>.
1228
1229 [ipcrypt] veorq, "ipcrypt: IP-format-preserving encryption",
1230 commit 8cc12f9, 6 July 2015,
1231 <https://github.com/veorq/ipcrypt>.
1232
1233 [ipcrypt-analysis]
1234 Aumasson, J-P., "Subject: Re: [Cfrg] Analysis of
1235 ipcrypt?", message to the Cfrg mailing list, 22 February
1236 2018, <https://mailarchive.ietf.org/arch/msg/cfrg/
1237 cFx5WJo48ZEN-a5cj_LlyrdN8-0/>.
1238
1239 [ISC-Knowledge-database-on-cache-snooping]
1240 Goldlust, S. and C. Almond, "DNS Cache snooping - should I
1241 be concerned?", ISC Knowledge Database, 15 October 2018,
1242 <https://kb.isc.org/docs/aa-00482>.
1243
1244 [MAC-address-EDNS]
1245 Hubert, B., "Embedding MAC address in DNS requests for
1246 selective filtering", DNS-OARC mailing list, 25 January
1247 2016, <https://lists.dns-oarc.net/pipermail/dns-
1248 operations/2016-January/014143.html>.
1249
1250 [nginx] nginx.org, "nginx news", 2019, <https://nginx.org/>.
1251
1252 [Passive-Observations-of-a-Large-DNS]
1253 de Vries, W. B., van Rijswijk-Deij, R., de Boer, P-T., and
1254 A. Pras, "Passive Observations of a Large DNS Service: 2.5
1255 Years in the Life of Google",
1256 DOI 10.23919/TMA.2018.8506536, 2018,
1257 <http://tma.ifip.org/2018/wp-
1258 content/uploads/sites/3/2018/06/tma2018_paper30.pdf>.
1259
1260 [pcap] The Tcpdump Group, "Tcpdump & Libpcap", 2020,
1261 <https://www.tcpdump.org/>.
1262
1263 [Pitfalls-of-DNS-Encryption]
1264 Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
1265 Encryption", Proceedings of the 13th Workshop on Privacy
1266 in the Electronic Society, pp. 191-200,
1267 DOI 10.1145/2665943.2665959, November 2014,
1268 <https://dl.acm.org/citation.cfm?id=2665959>.
1269
1270 [policy-comparison]
1271 Dickinson, S., "Comparison of policy and privacy
1272 statements 2019", DNS Privacy Project, 18 December 2019,
1273 <https://dnsprivacy.org/wiki/display/DP/
1274 Comparison+of+policy+and+privacy+statements+2019>.
1275
1276 [PowerDNS-dnswasher]
1277 PowerDNS, "dnswasher", commit 050e687, 24 April 2020,
1278 <https://github.com/PowerDNS/pdns/blob/master/pdns/
1279 dnswasher.cc>.
1280
1281 [Ramaswamy-and-Wolf]
1282 Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving
1283 IP Address Anonymization for Passive Measurement Systems",
1284 DOI 10.1109/TNET.2006.890128, 2007,
1285 <http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.
1286
1287 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1288 Rose, "Resource Records for the DNS Security Extensions",
1289 RFC 4034, DOI 10.17487/RFC4034, March 2005,
1290 <https://www.rfc-editor.org/info/rfc4034>.
1291
1292 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1293 Rose, "Protocol Modifications for the DNS Security
1294 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1295 <https://www.rfc-editor.org/info/rfc4035>.
1296
1297 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
1298 "Transport Layer Security (TLS) Session Resumption without
1299 Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
1300 January 2008, <https://www.rfc-editor.org/info/rfc5077>.
1301
1302 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
1303 Beijnum, "DNS64: DNS Extensions for Network Address
1304 Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
1305 DOI 10.17487/RFC6147, April 2011,
1306 <https://www.rfc-editor.org/info/rfc6147>.
1307
1308 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
1309 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
1310 <https://www.rfc-editor.org/info/rfc6235>.
1311
1312 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
1313 DOI 10.17487/RFC6265, April 2011,
1314 <https://www.rfc-editor.org/info/rfc6265>.
1315
1316 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
1317 DOI 10.17487/RFC7626, August 2015,
1318 <https://www.rfc-editor.org/info/rfc7626>.
1319
1320 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
1321 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
1322 <https://www.rfc-editor.org/info/rfc7873>.
1323
1324 [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,
1325 "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
1326 DOI 10.17487/RFC8027, November 2016,
1327 <https://www.rfc-editor.org/info/rfc8027>.
1328
1329 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
1330 Transport Layer Security (DTLS)", RFC 8094,
1331 DOI 10.17487/RFC8094, February 2017,
1332 <https://www.rfc-editor.org/info/rfc8094>.
1333
1334 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
1335 Pervasive Encryption on Operators", RFC 8404,
1336 DOI 10.17487/RFC8404, July 2018,
1337 <https://www.rfc-editor.org/info/rfc8404>.
1338
1339 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1340 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1341 <https://www.rfc-editor.org/info/rfc8446>.
1342
1343 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
1344 Kasten, "Automatic Certificate Management Environment
1345 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
1346 <https://www.rfc-editor.org/info/rfc8555>.
1347
1348 [RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
1349 and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS
1350 Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September
1351 2019, <https://www.rfc-editor.org/info/rfc8618>.
1352
1353 [SSL-Labs] SSL Labs, "SSL Server Test", 2019,
1354 <https://www.ssllabs.com/ssltest/>.
1355
1356 [stunnel] Goldlust, S., Almond, C., and F. Dupont, "DNS over TLS",
1357 ISC Knowledge Database", 1 November 2018,
1358 <https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html>.
1359
1360 [SURFnet-policy]
1361 Baartmans, C., van Wynsberghe, A., van Rijswijk-Deij, R.,
1362 and F. Jorna, "SURFnet Data Sharing Policy", June 2016,
1363 <https://surf.nl/datasharing>.
1364
1365 [tcpdpriv] Ipsilon Networks, Inc., "TCPDRIV - Program for Eliminating
1366 Confidential Information from Traces", 2004,
1367 <http://fly.isti.cnr.it/software/tcpdpriv/>.
1368
1369 [van-Dijkhuizen-et-al]
1370 Van Dijkhuizen, N. and J. Van Der Ham, "A Survey of
1371 Network Traffic Anonymisation Techniques and
1372 Implementations", ACM Computing Surveys,
1373 DOI 10.1145/3182660, May 2018,
1374 <https://doi.org/10.1145/3182660>.
1375
1376 [Xu-et-al] Fan, J., Xu, J., Ammar, M.H., and S.B. Moon, "Prefix-
1377 preserving IP address anonymization: measurement-based
1378 security evaluation and a new cryptography-based scheme",
1379 DOI 10.1016/j.comnet.2004.03.033, 2004,
1380 <http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-
1381 anon.pdf>.
1382
1383 Appendix A. Documents
1384
1385 This section provides an overview of some DNS privacy-related
1386 documents. However, this is neither an exhaustive list nor a
1387 definitive statement on the characteristics of any document with
1388 regard to potential increases or decreases in DNS privacy.
1389
1390 A.1. Potential Increases in DNS Privacy
1391
1392 These documents are limited in scope to communications between stub
1393 clients and recursive resolvers:
1394
1395 * "Specification for DNS over Transport Layer Security (TLS)"
1396 [RFC7858].
1397
1398 * "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094].
1399 Note that this document has the category of Experimental.
1400
1401 * "DNS Queries over HTTPS (DoH)" [RFC8484].
1402
1403 * "Usage Profiles for DNS over TLS and DNS over DTLS" [RFC8310].
1404
1405 * "The EDNS(0) Padding Option" [RFC7830] and "Padding Policies for
1406 Extension Mechanisms for DNS (EDNS(0))" [RFC8467].
1407
1408 These documents apply to recursive and authoritative DNS but are
1409 relevant when considering the operation of a recursive server:
1410
1411 * "DNS Query Name Minimisation to Improve Privacy" [RFC7816].
1412
1413 A.2. Potential Decreases in DNS Privacy
1414
1415 These documents relate to functionality that could provide increased
1416 tracking of user activity as a side effect:
1417
1418 * "Client Subnet in DNS Queries" [RFC7871].
1419
1420 * "Domain Name System (DNS) Cookies" [RFC7873]).
1421
1422 * "Transport Layer Security (TLS) Session Resumption without Server-
1423 Side State" [RFC5077], referred to here as simply TLS session
1424 resumption.
1425
1426 * [RFC8446], Appendix C.4 describes client tracking prevention in
1427 TLS 1.3
1428
1429 * "Compacted-DNS (C-DNS): A Format for DNS Packet Capture"
1430 [RFC8618].
1431
1432 * Passive DNS [RFC8499].
1433
1434 * Section 8 of [RFC8484] outlines the privacy considerations of DoH.
1435 Note that (while that document advises exposing the minimal set of
1436 data needed to achieve the desired feature set), depending on the
1437 specifics of a DoH implementation, there may be increased
1438 identification and tracking compared to other DNS transports.
1439
1440 A.3. Related Operational Documents
1441
1442 * "DNS Transport over TCP - Implementation Requirements" [RFC7766].
1443
1444 * "DNS Transport over TCP - Operational Requirements"
1445 [DNS-OVER-TCP].
1446
1447 * "The edns-tcp-keepalive EDNS0 Option" [RFC7828].
1448
1449 * "DNS Stateful Operations" [RFC8490].
1450
1451 Appendix B. IP Address Techniques
1452
1453 The following table presents a high-level comparison of various
1454 techniques employed or under development in 2019 and classifies them
1455 according to categorization of technique and other properties. Both
1456 the specific techniques and the categorizations are described in more
1457 detail in the following sections. The list of techniques includes
1458 the main techniques in current use but does not claim to be
1459 comprehensive.
1460
1461 +===========================+====+===+====+===+====+===+===+
1462 | Categorization/Property | GA | d | TC | C | TS | i | B |
1463 +===========================+====+===+====+===+====+===+===+
1464 | Anonymization | X | X | X | | | | X |
1465 +---------------------------+----+---+----+---+----+---+---+
1466 | Pseudonymization | | | | X | X | X | |
1467 +---------------------------+----+---+----+---+----+---+---+
1468 | Format preserving | X | X | X | X | X | X | |
1469 +---------------------------+----+---+----+---+----+---+---+
1470 | Prefix preserving | | | X | X | X | | |
1471 +---------------------------+----+---+----+---+----+---+---+
1472 | Replacement | | | X | | | | |
1473 +---------------------------+----+---+----+---+----+---+---+
1474 | Filtering | X | | | | | | |
1475 +---------------------------+----+---+----+---+----+---+---+
1476 | Generalization | | | | | | | X |
1477 +---------------------------+----+---+----+---+----+---+---+
1478 | Enumeration | | X | | | | | |
1479 +---------------------------+----+---+----+---+----+---+---+
1480 | Reordering/Shuffling | | | X | | | | |
1481 +---------------------------+----+---+----+---+----+---+---+
1482 | Random substitution | | | X | | | | |
1483 +---------------------------+----+---+----+---+----+---+---+
1484 | Cryptographic permutation | | | | X | X | X | |
1485 +---------------------------+----+---+----+---+----+---+---+
1486 | IPv6 issues | | | | | X | | |
1487 +---------------------------+----+---+----+---+----+---+---+
1488 | CPU intensive | | | | X | | | |
1489 +---------------------------+----+---+----+---+----+---+---+
1490 | Memory intensive | | | X | | | | |
1491 +---------------------------+----+---+----+---+----+---+---+
1492 | Security concerns | | | | | | X | |
1493 +---------------------------+----+---+----+---+----+---+---+
1494
1495 Table 1: Classification of Techniques
1496
1497 Legend of techniques:
1498
1499 GA = Google Analytics
1500 d = dnswasher
1501 TC = TCPdpriv
1502 C = CryptoPAn
1503 TS = TSA
1504 i = ipcipher
1505 B = Bloom filter
1506
1507 The choice of which method to use for a particular application will
1508 depend on the requirements of that application and consideration of
1509 the threat analysis of the particular situation.
1510
1511 For example, a common goal is that distributed packet captures must
1512 be in an existing data format, such as PCAP [pcap] or Compacted-DNS
1513 (C-DNS) [RFC8618], that can be used as input to existing analysis
1514 tools. In that case, use of a format-preserving technique is
1515 essential. This, though, is not cost free; several authors (e.g.,
1516 [Brekne-and-Arnes]) have observed that, as the entropy in an IPv4
1517 address is limited, if an attacker can
1518
1519 * ensure packets are captured by the target and
1520
1521 * send forged traffic with arbitrary source and destination
1522 addresses to that target and
1523
1524 * obtain a de-identified log of said traffic from that target,
1525
1526 any format-preserving pseudonymization is vulnerable to an attack
1527 along the lines of a cryptographic chosen-plaintext attack.
1528
1529 B.1. Categorization of Techniques
1530
1531 Data minimization methods may be categorized by the processing used
1532 and the properties of their outputs. The following builds on the
1533 categorization employed in [RFC6235]:
1534
1535 Format-preserving. Normally, when encrypting, the original data
1536 length and patterns in the data should be hidden from an attacker.
1537 Some applications of de-identification, such as network capture
1538 de-identification, require that the de-identified data is of the
1539 same form as the original data, to allow the data to be parsed in
1540 the same way as the original.
1541
1542 Prefix preservation. Values such as IP addresses and MAC addresses
1543 contain prefix information that can be valuable in analysis --
1544 e.g., manufacturer ID in MAC addresses, or subnet in IP addresses.
1545 Prefix preservation ensures that prefixes are de-identified
1546 consistently; for example, if two IP addresses are from the same
1547 subnet, a prefix preserving de-identification will ensure that
1548 their de-identified counterparts will also share a subnet. Prefix
1549 preservation may be fixed (i.e., based on a user-selected prefix
1550 length identified in advance to be preserved ) or general.
1551
1552 Replacement. A one-to-one replacement of a field to a new value of
1553 the same type -- for example, using a regular expression.
1554
1555 Filtering. Removing or replacing data in a field. Field data can be
1556 overwritten, often with zeros, either partially (truncation or
1557 reverse truncation) or completely (black-marker anonymization).
1558
1559 Generalization. Data is replaced by more general data with reduced
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
1560 specificity. One example would be to replace all TCP/UDP port
1561 numbers with one of two fixed values indicating whether the
1562 original port was ephemeral (>=1024) or nonephemeral (>1024).
1563 Another example, precision degradation, reduces the accuracy of,
1564 for example, a numeric value or a timestamp.
1565
1566 Enumeration. With data from a well-ordered set, replace the first
1567 data item's data using a random initial value and then allocate
1568 ordered values for subsequent data items. When used with
1569 timestamp data, this preserves ordering but loses precision and
1570 distance.
1571
1572 Reordering/shuffling. Preserving the original data, but rearranging
1573 its order, often in a random manner.
1574
1575 Random substitution. As replacement, but using randomly generated
1576 replacement values.
1577
1578 Cryptographic permutation. Using a permutation function, such as a
1579 hash function or cryptographic block cipher, to generate a
1580 replacement de-identified value.
1581
1582 B.2. Specific Techniques
1583
1584 B.2.1. Google Analytics Non-Prefix Filtering
1585
1586 Since May 2010, Google Analytics has provided a facility
1587 [IP-Anonymization-in-Analytics] that allows website owners to request
1588 that all their users' IP addresses are anonymized within Google
1589 Analytics processing. This very basic anonymization simply sets to
1590 zero the least significant 8 bits of IPv4 addresses, and the least
1591 significant 80 bits of IPv6 addresses. The level of anonymization
1592 this produces is perhaps questionable. There are some analysis
1593 results [Geolocation-Impact-Assessment] that suggest that the impact
1594 of this on reducing the accuracy of determining the user's location
1595 from their IP address is less than might be hoped; the average
1596 discrepancy in identification of the user city for UK users is no
1597 more than 17%.
1598
1599 Anonymization: Format-preserving, Filtering (truncation).
1600
1601 B.2.2. dnswasher
1602
1603 Since 2006, PowerDNS has included a de-identification tool, dnswasher
1604 [PowerDNS-dnswasher], with their PowerDNS product. This is a PCAP
1605 filter that performs a one-to-one mapping of end-user IP addresses
1606 with an anonymized address. A table of user IP addresses and their
1607 de-identified counterparts is kept; the first IPv4 user addresses is
1608 translated to 0.0.0.1, the second to 0.0.0.2, and so on. The de-
1609 identified address therefore depends on the order that addresses
1610 arrive in the input, and when running over a large amount of data,
1611 the address translation tables can grow to a significant size.
1612
1613 Anonymization: Format-preserving, Enumeration.
1614
1615 B.2.3. Prefix-Preserving Map
1616
1617 Used in [tcpdpriv], this algorithm stores a set of original and
1618 anonymized IP address pairs. When a new IP address arrives, it is
1619 compared with previous addresses to determine the longest prefix
1620 match. The new address is anonymized by using the same prefix, with
1621 the remainder of the address anonymized with a random value. The use
1622 of a random value means that TCPdpriv is not deterministic; different
1623 anonymized values will be generated on each run. The need to store
1624 previous addresses means that TCPdpriv has significant and unbounded
1625 memory requirements. The need to allocate anonymized addresses
1626 sequentially means that TCPdpriv cannot be used in parallel
1627 processing.
1628
1629 Anonymization: Format-preserving, prefix preservation (general).
1630
1631 B.2.4. Cryptographic Prefix-Preserving Pseudonymization
1632
1633 Cryptographic prefix-preserving pseudonymization was originally
1634 proposed as an improvement to the prefix-preserving map implemented
1635 in TCPdpriv, described in [Xu-et-al] and implemented in the
1636 [Crypto-PAn] tool. Crypto-PAn is now frequently used as an acronym
1637 for the algorithm. Initially, it was described for IPv4 addresses
1638 only; extension for IPv6 addresses was proposed in [Harvan]. This
1639 uses a cryptographic algorithm rather than a random value, and thus
1640 pseudonymity is determined uniquely by the encryption key, and is
1641 deterministic. It requires a separate AES encryption for each output
1642 bit and so has a nontrivial calculation overhead. This can be
1643 mitigated to some extent (for IPv4, at least) by precalculating
1644 results for some number of prefix bits.
1645
1646 Pseudonymization: Format-preserving, prefix preservation (general).
1647
1648 B.2.5. Top-Hash Subtree-Replicated Anonymization
1649
1650 Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated
1651 Anonymization (TSA) originated in response to the requirement for
1652 faster processing than Crypto-PAn. It used hashing for the most
1653 significant byte of an IPv4 address and a precalculated binary-tree
1654 structure for the remainder of the address. To save memory space,
1655 replication is used within the tree structure, reducing the size of
1656 the precalculated structures to a few megabytes for IPv4 addresses.
1657 Address pseudonymization is done via hash and table lookup and so
1658 requires minimal computation. However, due to the much-increased
1659 address space for IPv6, TSA is not memory efficient for IPv6.
1660
1661 Pseudonymization: Format-preserving, prefix preservation (general).
1662
1663 B.2.6. ipcipher
1664
1665 A recently released proposal from PowerDNS, ipcipher [ipcipher1]
1666 [ipcipher2], is a simple pseudonymization technique for IPv4 and IPv6
1667 addresses. IPv6 addresses are encrypted directly with AES-128 using
1668 a key (which may be derived from a passphrase). IPv4 addresses are
1669 similarly encrypted, but using a recently proposed encryption
1670 [ipcrypt] suitable for 32-bit block lengths. However, the author of
1671 ipcrypt has since indicated [ipcrypt-analysis] that it has low
1672 security, and further analysis has revealed it is vulnerable to
1673 attack.
1674
1675 Pseudonymization: Format-preserving, cryptographic permutation.
1676
1677 B.2.7. Bloom Filters
1678
1679 van Rijswijk-Deij et al. have recently described work using Bloom
1680 Filters [Bloom-filter] to categorize query traffic and record the
1681 traffic as the state of multiple filters. The goal of this work is
1682 to allow operators to identify so-called Indicators of Compromise
1683 (IOCs) originating from specific subnets without storing information
1684 about, or being able to monitor, the DNS queries of an individual
1685 user. By using a Bloom Filter, it is possible to determine with a
1686 high probability if, for example, a particular query was made, but
1687 the set of queries made cannot be recovered from the filter.
1688 Similarly, by mixing queries from a sufficient number of users in a
1689 single filter, it becomes practically impossible to determine if a
1690 particular user performed a particular query. Large numbers of
1691 queries can be tracked in a memory-efficient way. As filter status
1692 is stored, this approach cannot be used to regenerate traffic and so
1693 cannot be used with tools used to process live traffic.
1694
1695 Anonymized: Generalization.
1696
1697 Appendix C. Current Policy and Privacy Statements
1698
1699 A tabular comparison of policy and privacy statements from various
1700 DNS privacy service operators based loosely on the proposed RPS
1701 structure can be found at [policy-comparison]. The analysis is based
1702 on the data available in December 2019.
1703
1704 We note that the existing policies vary widely in style, content, and
1705 detail, and it is not uncommon for the full text for a given operator
1706 to equate to more than 10 pages (A4 size) of text in a moderate-sized
1707 font. It is a nontrivial task today for a user to extract a
1708 meaningful overview of the different services on offer.
1709
1710 It is also noted that Mozilla has published a DoH resolver policy
1711 [DoH-resolver-policy] that describes the minimum set of policy
1712 requirements that a party must satisfy to be considered as a
1713 potential partner for Mozilla's Trusted Recursive Resolver (TRR)
1714 program.
1715
1716 Appendix D. Example RPS
1717
1718 The following example RPS is very loosely based on some elements of
1719 published privacy statements for some public resolvers, with
1720 additional fields populated to illustrate what the full contents of
1721 an RPS might look like. This should not be interpreted as
1722
1723 * having been reviewed or approved by any operator in any way
1724
1725 * having any legal standing or validity at all
1726
1727 * being complete or exhaustive
1728
1729 This is a purely hypothetical example of an RPS to outline example
1730 contents -- in this case, for a public resolver operator providing a
1731 basic DNS Privacy service via one IP address and one DoH URI with
1732 security-based filtering. It does aim to meet minimal compliance as
1733 specified in Section 5.
1734
1735 D.1. Policy
1736
1737 1. Treatment of IP addresses. Many nations classify IP addresses as
1738 personal data, and we take a conservative approach in treating IP
1739 addresses as personal data in all jurisdictions in which our
1740 systems reside.
1741
1742 2. Data collection and sharing.
1743
1744 a. IP addresses. Our normal course of data management does not
1745 have any IP address information or other personal data logged
1746 to disk or transmitted out of the location in which the query
1747 was received. We may aggregate certain counters to larger
1748 network block levels for statistical collection purposes, but
1749 those counters do not maintain specific IP address data, nor
1750 is the format or model of data stored capable of being
1751 reverse-engineered to ascertain what specific IP addresses
1752 made what queries.
1753
1754 b. Data collected in logs. We do keep some generalized location
1755 information (at the city / metropolitan-area level) so that
1756 we can conduct debugging and analyze abuse phenomena. We
1757 also use the collected information for the creation and
1758 sharing of telemetry (timestamp, geolocation, number of hits,
1759 first seen, last seen) for contributors, public publishing of
1760 general statistics of system use (protections, threat types,
1761 counts, etc.). When you use our DNS services, here is the
1762 full list of items that are included in our logs:
1763
1764 * Requested domain name -- e.g., example.net
1765
1766 * Record type of requested domain -- e.g., A, AAAA, NS, MX,
1767 TXT, etc.
1768
1769 * Transport protocol on which the request arrived -- i.e.,
1770 UDP, TCP, DoT, DoH
1771
1772 * Origin IP general geolocation information -- i.e.,
1773 geocode, region ID, city ID, and metro code
1774
1775 * IP protocol version -- IPv4 or IPv6
1776
1777 * Response code sent -- e.g., SUCCESS, SERVFAIL, NXDOMAIN,
1778 etc.
1779
1780 * Absolute arrival time using a precision in ms
1781
1782 * Name of the specific instance that processed this request
1783
1784 * IP address of the specific instance to which this request
1785 was addressed (no relation to the requestor's IP address)
1786
1787 We may keep the following data as summary information,
1788 including all the above EXCEPT for data about the DNS record
1789 requested:
1790
1791 * Currently advertised BGP-summarized IP prefix/netmask of
1792 apparent client origin
1793
1794 * Autonomous system number (BGP ASN) of apparent client
1795 origin
1796
1797 All the above data may be kept in full or partial form in
1798 permanent archives.
1799
1800 c. Sharing of data. Except as described in this document, we do
1801 not intentionally share, sell, or rent individual personal
1802 information associated with the requestor (i.e., source IP
1803 address or any other information that can positively identify
1804 the client using our infrastructure) with anyone without your
1805 consent. We generate and share high-level anonymized
1806 aggregate statistics, including threat metrics on threat
1807 type, geolocation, and if available, sector, as well as other
1808 vertical metrics, including performance metrics on our DNS
1809 Services (i.e., number of threats blocked, infrastructure
1810 uptime) when available with our Threat Intelligence (TI)
1811 partners, academic researchers, or the public. Our DNS
1812 services share anonymized data on specific domains queried
1813 (records such as domain, timestamp, geolocation, number of
1814 hits, first seen, last seen) with our Threat Intelligence
1815 partners. Our DNS service also builds, stores, and may share
1816 certain DNS data streams which store high level information
1817 about domain resolved, query types, result codes, and
1818 timestamp. These streams do not contain the IP address
1819 information of the requestor and cannot be correlated to IP
1820 address or other personal data. We do not and never will
1821 share any of the requestor's data with marketers, nor will we
1822 use this data for demographic analysis.
1823
1824 3. Exceptions. There are exceptions to this storage model: In the
1825 event of actions or observed behaviors that we deem malicious or
1826 anomalous, we may utilize more detailed logging to collect more
1827 specific IP address data in the process of normal network defense
1828 and mitigation. This collection and transmission off-site will
1829 be limited to IP addresses that we determine are involved in the
1830 event.
1831
1832 4. Associated entities. Details of our Threat Intelligence partners
1833 can be found at our website page (insert link).
1834
1835 5. Correlation of Data. We do not correlate or combine information
1836 from our logs with any personal information that you have
1837 provided us for other services, or with your specific IP address.
1838
1839 6. Result filtering.
1840
1841 a. Filtering. We utilize cyber-threat intelligence about
1842 malicious domains from a variety of public and private
1843 sources and block access to those malicious domains when your
1844 system attempts to contact them. An NXDOMAIN is returned for
1845 blocked sites.
1846
1847 i. Censorship. We will not provide a censoring component
1848 and will limit our actions solely to the blocking of
1849 malicious domains around phishing, malware, and exploit-
1850 kit domains.
1851
1852 ii. Accidental blocking. We implement allowlisting
1853 algorithms to make sure legitimate domains are not
1854 blocked by accident. However, in the rare case of
1855 blocking a legitimate domain, we work with the users to
1856 quickly allowlist that domain. Please use our support
1857 form (insert link) if you believe we are blocking a
1858 domain in error.
1859
1860 D.2. Practice
1861
1862 1. Deviations from Policy. None in place since (insert date).
1863
1864 2. Client-facing capabilities.
1865
1866 a. We offer UDP and TCP DNS on port 53 on (insert IP address)
1867
1868 b. We offer DNS over TLS as specified in RFC 7858 on (insert IP
1869 address). It is available on port 853 and port 443. We also
1870 implement RFC 7766.
1871
1872 i. The DoT authentication domain name used is (insert
1873 domain name).
1874
1875 ii. We do not publish SPKI pin sets.
1876
1877 c. We offer DNS over HTTPS as specified in RFC 8484 on (insert
1878 URI template).
1879
1880 d. Both services offer TLS 1.2 and TLS 1.3.
1881
1882 e. Both services pad DNS responses according to RFC 8467.
1883
1884 f. Both services provide DNSSEC validation.
1885
1886 3. Upstream capabilities.
1887
1888 a. Our servers implement QNAME minimization.
1889
1890 b. Our servers do not send ECS upstream.
1891
1892 4. Support. Support information for this service is available at
1893 (insert link).
1894
1895 5. Data Processing. We operate as the legal entity (insert entity)
1896 registered in (insert country); as such, we operate under (insert
1897 country/region) law. Our separate statement regarding the
1898 specifics of our data processing policy, practice, and agreements
1899 can be found here (insert link).
1900
1901 Acknowledgements
1902
1903 Many thanks to Amelia Andersdotter for a very thorough review of the
1904 first draft of this document and Stephen Farrell for a thorough
1905 review at Working Group Last Call and for suggesting the inclusion of
1906 an example RPS. Thanks to John Todd for discussions on this topic,
1907 and to Stéphane Bortzmeyer, Puneet Sood, and Vittorio Bertola for
1908 review. Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman,
1909 Dan York, Jon Reed, and Lorenzo Colitti for comments at the mic.
1910 Thanks to Loganaden Velvindron for useful updates to the text.
1911
1912 Sara Dickinson thanks the Open Technology Fund for a grant to support
1913 the work on this document.
1914
1915 Contributors
1916
1917 The below individuals contributed significantly to the document:
1918
1919 John Dickinson
1920 Sinodun IT
1921 Magdalen Centre
1922 Oxford Science Park
1923 Oxford
1924 OX4 4GA
1925 United Kingdom
1926
1927
1928 Jim Hague
1929 Sinodun IT
1930 Magdalen Centre
1931 Oxford Science Park
1932 Oxford
1933 OX4 4GA
1934 United Kingdom
1935
1936
1937 Authors' Addresses
1938
1939 Sara Dickinson
1940 Sinodun IT
1941 Magdalen Centre
1942 Oxford Science Park
1943 Oxford
1944 OX4 4GA
1945 United Kingdom
1946
1947 Email: sara@sinodun.com
1948
1949
1950 Benno J. Overeinder
1951 NLnet Labs
1952 Science Park 400
1953 1098 XH Amsterdam
1954 Netherlands
1955
1956 Email: benno@nlnetLabs.nl
1957
1958
1959 Roland M. van Rijswijk-Deij
1960 NLnet Labs
1961 Science Park 400
1962 1098 XH Amsterdam
1963 Netherlands
1964
1965 Email: roland@nlnetLabs.nl
1966
1967
1968 Allison Mankin
1969 Salesforce.com, Inc.
1970 Salesforce Tower
1971 415 Mission Street, 3rd Floor
1972 San Francisco, CA 94105
1973 United States of America
1974
1975 Email: allison.mankin@gmail.com
1976
One example would be to replace all TCP/UDP port numbers with one of two fixed values indicating whether the original port was ephemeral (>=1024) or nonephemeral (>1024).
One example would be to replace all TCP/UDP port numbers with one of two fixed values indicating whether the original port was ephemeral (>=1024) or nonephemeral (><1024).