draft-ietf-dprive-bcp-op-13.txt   draft-ietf-dprive-bcp-op-14.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: January 11, 2021 R. van Rijswijk-Deij Expires: January 14, 2021 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
July 10, 2020 July 13, 2020
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-13 draft-ietf-dprive-bcp-op-14
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 non-normative framework to assist This document also presents a non-normative framework to assist
writers of a Recursive operator Privacy statement (analogous to DNS writers of a Recursive operator Privacy Statement (analogous to DNS
Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
described in RFC6841). described in RFC6841).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 11, 2021. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 45 skipping to change at page 3, line 45
system and these are now seeing some deployment. This latest system and these are now seeing some deployment. This latest
evolution of the DNS presents new challenges to operators and this evolution of the DNS presents new challenges to operators and this
document attempts to provide an overview of considerations for document attempts to provide an overview of considerations for
privacy focused DNS services. privacy focused DNS services.
In recent years there has also been an increase in the availability In recent years there has also been an increase in the availability
of "public resolvers" [RFC8499] which users may prefer to use instead of "public resolvers" [RFC8499] which users may prefer to use instead
of the default network resolver either because they offer a specific of the default network resolver either because they offer a specific
feature (e.g., good reachability or encrypted transport) or because feature (e.g., good reachability or encrypted transport) or because
the network resolver lacks a specific feature (e.g., strong privacy the network resolver lacks a specific feature (e.g., strong privacy
policy or unfiltered responses). These open resolvers have tended to policy or unfiltered responses). These public resolvers have tended
be at the forefront of adoption of privacy-related enhancements but to be at the forefront of adoption of privacy-related enhancements
it is anticipated that operators of other resolver services will but it is anticipated that operators of other resolver services will
follow. follow.
Whilst protocols that encrypt DNS messages on the wire provide Whilst protocols that encrypt DNS messages on the wire provide
protection against certain attacks, the resolver operator still has protection against certain attacks, the resolver operator still has
(in principle) full visibility of the query data and transport (in principle) full visibility of the query data and transport
identifiers for each user. Therefore, a trust relationship (whether identifiers for each user. Therefore, a trust relationship (whether
explicit or implicit) is assumed to exist between each user and the explicit or implicit) is assumed to exist between each user and the
operator of the resolver(s) used by that user. The ability of the operator of the resolver(s) used by that user. The ability of the
operator to provide a transparent, well documented, and secure operator to provide a transparent, well documented, and secure
privacy service will likely serve as a major differentiating factor privacy service will likely serve as a major differentiating factor
skipping to change at page 18, line 42 skipping to change at page 18, line 42
operator is happy with. However some operators consider allowlisting operator is happy with. However some operators consider allowlisting
to incur significant operational overhead compared to dynamic to incur significant operational overhead compared to dynamic
detection of ECS support on authoritative servers. detection of ECS support on authoritative servers.
Additional options: Additional options:
o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020] o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020]
(NXDOMAIN: There Really Is Nothing Underneath) to reduce the (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 [RFC8806] 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
performed using cleartext (at the time of writing), resolver services performed using cleartext (at the time of writing), resolver services
need to consider the extent to which they may be directly leaking need to consider the extent to which they may be directly leaking
information about their client community via these upstream queries information about their client community via these upstream queries
skipping to change at page 27, line 48 skipping to change at page 27, line 48
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>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
editor.org/info/rfc7706>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<https://www.rfc-editor.org/info/rfc7816>. <https://www.rfc-editor.org/info/rfc7816>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
skipping to change at page 29, line 18 skipping to change at page 29, line 14
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019, RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>. <https://www.rfc-editor.org/info/rfc8490>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<https://www.rfc-editor.org/info/rfc8806>.
12.2. Informative References 12.2. Informative References
[Bloom-filter] [Bloom-filter]
van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L. van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L.
Allodi, "Privacy-Conscious Threat Intelligence Using Allodi, "Privacy-Conscious Threat Intelligence Using
DNSBLOOM", 2019, DNSBLOOM", 2019,
<http://dl.ifip.org/db/conf/im/im2019/189282.pdf>. <http://dl.ifip.org/db/conf/im/im2019/189282.pdf>.
[Brenker-and-Arnes] [Brenker-and-Arnes]
Brekne, T. and A. Arnes, "CIRCUMVENTING IP-ADDRESS Brekne, T. and A. Arnes, "CIRCUMVENTING IP-ADDRESS
skipping to change at page 43, line 44 skipping to change at page 43, line 44
2. We offer DNS over TLS as specified in RFC7858 on (insert IP 2. We offer DNS over TLS as specified in RFC7858 on (insert IP
address). It is available on port 853 and port 443. We also address). It is available on port 853 and port 443. We also
implement RFC7766. implement RFC7766.
1. The DoT authentication domain name used is (insert domain 1. The DoT authentication domain name used is (insert domain
name). name).
2. We do not publish SPKI pin sets. 2. We do not publish SPKI pin sets.
3. We offer DNS over HTTPS as specified in RFC8484 on (insert 3. We offer DNS over HTTPS as specified in RFC8484 on (insert
URI template). Both POST and GET are supported. URI template).
4. Both services offer TLS 1.2 and TLS 1.3. 4. Both services offer TLS 1.2 and TLS 1.3.
5. Both services pad DNS responses according to RFC8467. 5. Both services pad DNS responses according to RFC8467.
6. Both services provide DNSSEC validation. 6. Both services provide DNSSEC validation.
3. Upstream capabilities. 3. Upstream capabilities.
1. Our servers implement QNAME minimization. 1. Our servers implement QNAME minimization.
 End of changes. 10 change blocks. 
15 lines changed or deleted 14 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/