draft-ietf-dprive-bcp-op-05.txt   draft-ietf-dprive-bcp-op-06.txt 
dprive S. Dickinson dprive S. Dickinson
Internet-Draft Sinodun IT Internet-Draft Sinodun IT
Intended status: Best Current Practice B. Overeinder Intended status: Best Current Practice B. Overeinder
Expires: May 3, 2020 R. van Rijswijk-Deij Expires: May 21, 2020 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
October 31, 2019 November 18, 2019
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-05 draft-ietf-dprive-bcp-op-06
Abstract Abstract
This document presents operational, policy and security This document presents operational, policy and security
considerations for DNS recursive resolver operators who choose to considerations for DNS recursive resolver operators who choose to
offer DNS Privacy services. With these recommendations, the operator offer DNS Privacy services. With these recommendations, the operator
can make deliberate decisions regarding which services to provide, can make deliberate decisions regarding which services to provide,
and how the decisions and alternatives impact the privacy of users. and how the decisions and alternatives impact the privacy of users.
This document also presents a framework to assist writers of a DNS This document also presents a framework to assist writers of a DNS
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2020. This Internet-Draft will expire on May 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
6.2. Current policy and privacy statements . . . . . . . . . . 22 6.2. Current policy and privacy statements . . . . . . . . . . 22
6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security considerations . . . . . . . . . . . . . . . . . . . 23 8. Security considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 28
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31
A.1. Potential increases in DNS privacy . . . . . . . . . . . 31 A.1. Potential increases in DNS privacy . . . . . . . . . . . 31
A.2. Potential decreases in DNS privacy . . . . . . . . . . . 31 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 32
A.3. Related operational documents . . . . . . . . . . . . . . 32 A.3. Related operational documents . . . . . . . . . . . . . . 32
Appendix B. IP address techniques . . . . . . . . . . . . . . . 32 Appendix B. IP address techniques . . . . . . . . . . . . . . . 32
B.1. Google Analytics non-prefix filtering . . . . . . . . . . 33 B.1. Google Analytics non-prefix filtering . . . . . . . . . . 33
B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 33 B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 34
B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 34 B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 34
B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 34 B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 34
B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 34 B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 35
B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 35 B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 35
B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 35 B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Example DROP statement . . . . . . . . . . . . . . . 35 Appendix C. Example DROP statement . . . . . . . . . . . . . . . 36
C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 36 C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 36
C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 38 C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
The Domain Name System (DNS) is at the core of the Internet; almost The Domain Name System (DNS) is at the core of the Internet; almost
every activity on the Internet starts with a DNS query (and often every activity on the Internet starts with a DNS query (and often
several). However the DNS was not originally designed with strong several). However the DNS was not originally designed with strong
security or privacy mechanisms. A number of developments have taken security or privacy mechanisms. A number of developments have taken
place in recent years which aim to increase the privacy of the DNS place in recent years which aim to increase the privacy of the DNS
system and these are now seeing some deployment. This latest system and these are now seeing some deployment. This latest
skipping to change at page 5, line 13 skipping to change at page 5, line 13
operator policy rather than gross disparities in privacy concerns. operator policy rather than gross disparities in privacy concerns.
Community insight [or judgment?] about operational practices can Community insight [or judgment?] about operational practices can
change quickly, and experience shows that a Best Current Practice change quickly, and experience shows that a Best Current Practice
(BCP) document about privacy and security is a point-in-time (BCP) document about privacy and security is a point-in-time
statement. Readers are advised to seek out any errata or updates statement. Readers are advised to seek out any errata or updates
that apply to this document. that apply to this document.
2. Scope 2. Scope
"DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis] "DNS Privacy Considerations" [I-D.ietf-dprive-rfc7626-bis] describes
describes the general privacy issues and threats associated with the the general privacy issues and threats associated with the use of the
use of the DNS by Internet users and much of the threat analysis here DNS by Internet users and much of the threat analysis here is lifted
is lifted from that document and from [RFC6973]. However this from that document and from [RFC6973]. However this document is
document is limited in scope to best practice considerations for the limited in scope to best practice considerations for the provision of
provision of DNS privacy services by servers (recursive resolvers) to DNS privacy services by servers (recursive resolvers) to clients
clients (stub resolvers or forwarders). Privacy considerations (stub resolvers or forwarders). Privacy considerations specifically
specifically from the perspective of an end user, or those for from the perspective of an end user, or those for operators of
operators of authoritative nameservers are out of scope. authoritative nameservers are out of scope.
This document includes (but is not limited to) considerations in the This document includes (but is not limited to) considerations in the
following areas (taken from [I-D.bortzmeyer-dprive-rfc7626-bis]): following areas (taken from [I-D.ietf-dprive-rfc7626-bis]):
1. Data "on the wire" between a client and a server 1. Data "on the wire" between a client and a server
2. Data "at rest" on a server (e.g. in logs) 2. Data "at rest" on a server (e.g. in logs)
3. Data "sent onwards" from the server (either on the wire or shared 3. Data "sent onwards" from the server (either on the wire or shared
with a third party) with a third party)
Whilst the issues raised here are targeted at those operators who Whilst the issues raised here are targeted at those operators who
choose to offer a DNS privacy service, considerations for areas 2 and choose to offer a DNS privacy service, considerations for areas 2 and
skipping to change at page 6, line 10 skipping to change at page 6, line 10
benefits at the price of a reduction in privacy and conversely some benefits at the price of a reduction in privacy and conversely some
features increase privacy with an accompanying increase in features increase privacy with an accompanying increase in
complexity. A selection of the most relevant documents are listed in complexity. A selection of the most relevant documents are listed in
Appendix A for reference. Appendix A for reference.
4. Terminology 4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] and [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
DNS terminology is as described in [RFC8499] with one modification: DNS terminology is as described in [RFC8499] with one modification:
we restate the clause in the original definition of Privacy-enabling we restate the clause in the original definition of Privacy-enabling
DNS server in [RFC8310] to include the requirement that a DNS over DNS server in [RFC8310] to include the requirement that a DNS over
(D)TLS server should also offer at least one of the credentials (D)TLS server should also offer at least one of the credentials
described in Section 8 and implement the (D)TLS profile described in described in Section 8 and implement the (D)TLS profile described in
Section 9 of [RFC8310]. Section 9 of [RFC8310].
Other Terms: Other Terms:
skipping to change at page 7, line 33 skipping to change at page 7, line 33
In this section we consider both data on the wire and the service In this section we consider both data on the wire and the service
provided to the client. provided to the client.
5.1.1. Transport recommendations 5.1.1. Transport recommendations
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
* Passive surveillance of traffic on the wire * Passive surveillance of traffic on the wire
[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.4.2. [I-D.ietf-dprive-rfc7626-bis] Section 2.4.2.
DNS Privacy Threats: DNS Privacy Threats:
o Active injection of spurious data or traffic o Active injection of spurious data or traffic
Mitigations: Mitigations:
A DNS privacy service can mitigate these threats by providing service A DNS privacy service can mitigate these threats by providing service
over one or more of the following transports over one or more of the following transports
skipping to change at page 8, line 20 skipping to change at page 8, line 20
Whilst encryption of DNS traffic can protect against active injection Whilst encryption of DNS traffic can protect against active injection
this does not diminish the need for DNSSEC, see Section 5.1.4. this does not diminish the need for DNSSEC, see Section 5.1.4.
5.1.2. Authentication of DNS privacy services 5.1.2. Authentication of DNS privacy services
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
* Active attacks that can redirect traffic to rogue servers * Active attacks that can redirect traffic to rogue servers
[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3. [I-D.ietf-dprive-rfc7626-bis] Section 2.5.3.
Mitigations: Mitigations:
DNS privacy services should ensure clients can authenticate the DNS privacy services should ensure clients can authenticate the
server. Note that this, in effect, commits the DNS privacy service server. Note that this, in effect, commits the DNS privacy service
to a public identity users will trust. to a public identity users will trust.
When using DNS-over-TLS clients that select a 'Strict Privacy' usage When using DNS-over-TLS clients that select a 'Strict Privacy' usage
profile [RFC8310] (to mitigate the threat of active attack on the profile [RFC8310] (to mitigate the threat of active attack on the
client) require the ability to authenticate the DNS server. To client) require the ability to authenticate the DNS server. To
skipping to change at page 11, line 48 skipping to change at page 11, line 48
5.1.5. Availability 5.1.5. Availability
DNS Privacy Threats: DNS Privacy Threats:
o A failed DNS privacy service could force the user to switch o A failed DNS privacy service could force the user to switch
providers, fallback to cleartext or accept no DNS service for the providers, fallback to cleartext or accept no DNS service for the
outage. outage.
Mitigations: Mitigations:
A DNS privacy service must be engineered for high availability. A DNS privacy service should strive to engineer encrypted services to
the same availability level as any unencrypted services they provide.
Particular care should to be taken to protect DNS privacy services Particular care should to be taken to protect DNS privacy services
against denial-of-service attacks, as experience has shown that against denial-of-service attacks, as experience has shown that
unavailability of DNS resolving because of attacks is a significant unavailability of DNS resolving because of attacks is a significant
motivation for users to switch services. See, for example motivation for users to switch services. See, for example
Section IV-C of Passive Observations of a Large DNS Service: 2.5 Section IV-C of Passive Observations of a Large DNS Service: 2.5
Years in the Life of Google [2]. Years in the Life of Google [2].
Techniques such as those described in Section 10 of [RFC7766] can be Techniques such as those described in Section 10 of [RFC7766] can be
of use to operators to defend against such attacks. of use to operators to defend against such attacks.
skipping to change at page 12, line 48 skipping to change at page 12, line 49
however, legitimate reasons for operators to inspect DNS traffic, however, legitimate reasons for operators to inspect DNS traffic,
e.g. to monitor for network security threats. Operators may e.g. to monitor for network security threats. Operators may
therefore need to invest in alternative means of monitoring that therefore need to invest in alternative means of monitoring that
relies on either the resolver software directly, or exporting DNS relies on either the resolver software directly, or exporting DNS
traffic from the resolver using e.g. dnstap [3]. traffic from the resolver using e.g. dnstap [3].
Optimization: Optimization:
When implementing alternative means for traffic monitoring, operators When implementing alternative means for traffic monitoring, operators
of a DNS privacy service should consider using privacy conscious of a DNS privacy service should consider using privacy conscious
means to do so (see, for example, the discussion on the use of Bloom means to do so (see section Section 5.2 for more details on data
Filters in the #documents appendix in this document). handling and also the discussion on the use of Bloom Filters in
Appendix A.
5.1.8. Limitations of using a pure TLS proxy 5.1.8. Limitations of using a pure TLS proxy
DNS Privacy Threats: DNS Privacy Threats:
o Limited ability to manage or monitor incoming connections using o Limited ability to manage or monitor incoming connections using
DNS specific techniques DNS specific techniques
o Misconfiguration of the target server could lead to data leakage o Misconfiguration of the target server could lead to data leakage
if the proxy to target server path is not encrypted. if the proxy to target server path is not encrypted.
skipping to change at page 14, line 18 skipping to change at page 14, line 18
Mitigations: Mitigations:
The following are common activities for DNS service operators and in The following are common activities for DNS service operators and in
all cases should be minimized or completely avoided if possible for all cases should be minimized or completely avoided if possible for
DNS privacy services. If data is retained it should be encrypted and DNS privacy services. If data is retained it should be encrypted and
either aggregated, pseudonymized or anonymized whenever possible. In either aggregated, pseudonymized or anonymized whenever possible. In
general the principle of data minimization described in [RFC6973] general the principle of data minimization described in [RFC6973]
should be applied. should be applied.
o Transient data (e.g. that is used for real time monitoring and o Transient data (e.g. that is used for real time monitoring and
threat analysis which might be held only memory) should be threat analysis which might be held only in memory) should be
retained for the shortest possible period deemed operationally retained for the shortest possible period deemed operationally
feasible. feasible.
o The retention period of DNS traffic logs should be only those o The retention period of DNS traffic logs should be only those
required to sustain operation of the service and, to the extent required to sustain operation of the service and, to the extent
that such exists, meet regulatory requirements. that such exists, meet regulatory requirements.
o DNS privacy services should not track users except for the o DNS privacy services should not track users except for the
particular purpose of detecting and remedying technically particular purpose of detecting and remedying technically
malicious (e.g. DoS) or anomalous use of the service. malicious (e.g. DoS) or anomalous use of the service.
skipping to change at page 15, line 46 skipping to change at page 15, line 46
pseudonymization schema is known, the process can be reversed, so pseudonymization schema is known, the process can be reversed, so
the original identity becomes known again. the original identity becomes known again.
In practice there is a fine line between the two; for example, how to In practice there is a fine line between the two; for example, how to
categorize a deterministic algorithm for data minimization of IP categorize a deterministic algorithm for data minimization of IP
addresses that produces a group of pseudonyms for a single given addresses that produces a group of pseudonyms for a single given
address. address.
5.2.3. IP address pseudonymization and anonymization methods 5.2.3. IP address pseudonymization and anonymization methods
As [I-D.bortzmeyer-dprive-rfc7626-bis] makes clear, the big privacy As [I-D.ietf-dprive-rfc7626-bis] makes clear, the big privacy risk in
risk in DNS is connecting DNS queries to an individual and the major DNS is connecting DNS queries to an individual and the major vector
vector for this in DNS traffic is the client IP address. for this in DNS traffic is the client IP address.
There is active discussion in the space of effective pseudonymization There is active discussion in the space of effective pseudonymization
of IP addresses in DNS traffic logs, however there seems to be no of IP addresses in DNS traffic logs, however there seems to be no
single solution that is widely recognized as suitable for all or most single solution that is widely recognized as suitable for all or most
use cases. There are also as yet no standards for this that are use cases. There are also as yet no standards for this that are
unencumbered by patents. unencumbered by patents.
The following table presents a high level comparison of various The following table presents a high level comparison of various
techniques employed or under development today and classifies them techniques employed or under development today and classifies them
according to categorization of technique and other properties. according to categorization of technique and other properties.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Whitelisting has the benefit that not only does the operator know Whitelisting has the benefit that not only does the operator know
which upstream servers can use ECS but also allows the operator to which upstream servers can use ECS but also allows the operator to
decide which upstream servers apply privacy policies that the decide which upstream servers apply privacy policies that the
operator is happy with. However some operators consider whitelisting operator is happy with. However some operators consider whitelisting
to incur significant operational overhead compared to dynamic to incur significant operational overhead compared to dynamic
detection of ECS on authoritative servers. detection of ECS on authoritative servers.
Additional options: Additional options:
o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020]
(NXDOMAIN: There Really Is Nothing Underneath) to reduce the
number of queries to authoritative servers to increase privacy. number of queries to authoritative servers to increase privacy.
o Run a copy of the root zone on loopback [RFC7706] to avoid making o Run a copy of the root zone on loopback [RFC7706] to avoid making
queries to the root servers that might leak information. queries to the root servers that might leak information.
5.3.2. Client query obfuscation 5.3.2. Client query obfuscation
Additional options: Additional options:
Since queries from recursive resolvers to authoritative servers are Since queries from recursive resolvers to authoritative servers are
skipping to change at page 24, line 27 skipping to change at page 24, line 27
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
11. Changelog 11. Changelog
draft-ietf-dprive-bcp-op-05 draft-ietf-dprive-bcp-op-05
o Final minor changes from second WGLC.
draft-ietf-dprive-bcp-op-05
o Remove some text on consent: o Remove some text on consent:
* Paragraph 2 in section 5.3.3 * Paragraph 2 in section 5.3.3
* Item 6 in the DROP Practice statement (and example) * Item 6 in the DROP Practice statement (and example)
o Remove .onion and TLSA options o Remove .onion and TLSA options
o Include ACME as a reference for certificate management o Include ACME as a reference for certificate management
skipping to change at page 26, line 27 skipping to change at page 26, line 30
draft-ietf-dprive-bcp-op-00 draft-ietf-dprive-bcp-op-00
o Initial commit of re-named document after adoption to replace o Initial commit of re-named document after adoption to replace
draft-dickinson-dprive-bcp-op-01 draft-dickinson-dprive-bcp-op-01
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dprive-rfc7626-bis]
Bortzmeyer, S. and S. Dickinson, "DNS Privacy
Considerations", draft-ietf-dprive-rfc7626-bis-02 (work in
progress), October 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, <https://www.rfc- DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
editor.org/info/rfc6265>. editor.org/info/rfc6265>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
skipping to change at page 28, line 11 skipping to change at page 28, line 24
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
12.2. Informative References 12.2. Informative References
[I-D.bellis-dnsop-xpf] [I-D.bellis-dnsop-xpf]
Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For", Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For",
draft-bellis-dnsop-xpf-04 (work in progress), March 2018. draft-bellis-dnsop-xpf-04 (work in progress), March 2018.
[I-D.bortzmeyer-dprive-rfc7626-bis]
Bortzmeyer, S. and S. Dickinson, "DNS Privacy
Considerations", draft-bortzmeyer-dprive-rfc7626-bis-02
(work in progress), January 2019.
[I-D.ietf-dnsop-dns-tcp-requirements] [I-D.ietf-dnsop-dns-tcp-requirements]
Kristoff, J. and D. Wessels, "DNS Transport over TCP - Kristoff, J. and D. Wessels, "DNS Transport over TCP -
Operational Requirements", draft-ietf-dnsop-dns-tcp- Operational Requirements", draft-ietf-dnsop-dns-tcp-
requirements-04 (work in progress), June 2019. requirements-05 (work in progress), November 2019.
[I-D.ietf-httpbis-bcp56bis] [I-D.ietf-httpbis-bcp56bis]
Nottingham, M., "Building Protocols with HTTP", draft- Nottingham, M., "Building Protocols with HTTP", draft-
ietf-httpbis-bcp56bis-08 (work in progress), November ietf-httpbis-bcp56bis-09 (work in progress), November
2018. 2019.
[pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>. [pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.
[Pitfalls-of-DNS-Encryption] [Pitfalls-of-DNS-Encryption]
Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
Encryption", 2014, <https://dl.acm.org/ Encryption", 2014, <https://dl.acm.org/
citation.cfm?id=2665959>. citation.cfm?id=2665959>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
skipping to change at page 29, line 15 skipping to change at page 29, line 25
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706, Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015, <https://www.rfc- DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
editor.org/info/rfc7706>. editor.org/info/rfc7706>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, <https://www.rfc- DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
editor.org/info/rfc8094>. editor.org/info/rfc8094>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
 End of changes. 26 change blocks. 
39 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/