DNS Privacy
24/08/2022
The Domain Name System (DNS) is a hierarchical naming system that allows Internet users to use names instead of having to remember numerical IP addresses. With the increase in the number of devices connected to the Internet and the need to find an easier way to remember IP addresses, it became necessary to create a system that would meet these requirements.
Since its initial development, elements such as Domain Name Security Extensions (DNSSEC) have been incorporated into the DNS. While DNSSEC authenticates responses to domain name lookups, it does not provide privacy protection for those lookups, although it does prevent attackers from tampering with responses to DNS requests.
DNS queries are transmitted in plain text format, can reveal sensitive information about which websites a user visits, as well as information about other services provided on certain domains. This may make it easier to collect this information for unintended purposes.
At the IETF,[1] people have been discussing the development of various protocols such as DNS Query Name Minimization (Qname), DNS-over-TLS (DoT), DNS over Datagram Transport Layer Security (DTLS), DNS-over-HTTPS (DoH), and others currently under development such as DNS-over-Quic (DoQ) that try to add privacy to users’ DNS queries.
While their technical configuration elements are generally not available to all users, it is necessary to simplify the operation and application of these protocols to ensure the privacy of our DNS queries.
It is also worth noting that, although all the protocols developed to date seek to provide query privacy, this cannot be 100% guaranteed as DNS queries are sent in clear text. In fact, resolvers need this information in clear text to be able to process it.
Preferred Alternatives
When a user types a URL into their browser, a DNS query is performed to convert the domain portion of the URL to an IP address. Unless there is a DNS server on the local network, the name resolution request must go through the Internet service provider’s network and through any routers between the ISP and the DNS server.
Although different protocols seek to ensure DNS query privacy, in practice, DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) are the most popular and most widely used because of their technical and implementation characteristics.
The DoT protocol was created by RFC 7858 and allows all DNS queries and responses to be encrypted through the TLS protocol, allowing a secure data exchange between the client and the web server by transferring queries through an encrypted tunnel where only the two participants in the exchange can decrypt and process the data. This allows data to be sent over simple TCP connections in layer 4 and over port 853.
In terms of performance, this protocol allows maintaining DNS query resolution, offering functionality and compatibility in the resolvers on both the client and the server sides. In the event that a query cannot be performed, the DNS can still respond in clear text, allowing service continuity.
DNS over HTTPS (DoH) is another security protocol developed at the IETF through RFC 8484. It uses port 443 to send queries over HTTPS traffic, making it difficult to identify because DoH traffic is mixed with other HTTPS traffic.
Although DoH provides privacy to DNS queries, it concentrates most of the DNS data in the resolvers, providing them with information, for example, on Internet traffic routing, as well as access to large amounts of user data, something that is not desirable.
DoH can be problematic for companies or corporations that monitor their employees’ DNS queries for the purpose of blocking access to malicious or inappropriate sites. This creates a blind spot, as all the traffic is sent encrypted over port 443.
As for the protocol’s performance, despite the fact that DNS servers have been designed to efficiently “cache” the queries they receive and that the impact from the user side will not be as significant, incorporating additional negotiation layers (layer 7) —like DoH does— increases processing by the servers and therefore increases latency in the responses.
Which protocol is better?
DoH provides privacy by hiding all queries in regular HTTPS traffic but, in this case, name resolution is performed between browsers and resolvers, concentrating large amounts of query information in just a few resolvers.
Some browsers announced that they would be enabling the DoH protocol by default. However, this would have been counterproductive, as many users without extensive technical skills do not change the default settings of their devices and this would have forced them to adopt this protocol without understanding the consequences.
Each protocol is designed to prevent a specific type of threat. DoH, for example, was developed with the aim of preventing potential government espionage and/or censorship by encapsulating DNS queries within an HTTPS session.
The evolution of DoT has followed the same steps as other protocols such as HTTP, IMAP, POP, FTP, etc., which is a good thing. It also provides greater security, as DNS traffic is carried over encrypted transport.
Considering that privacy depends on what each user wishes to prioritize and is therefore subjective rather than objective, at the moment, DoT is a better alternative when compared to the risks of using DoH as a privacy protocol.
References:
Mockapetris, P., “Domain names: Concepts and facilities”, RFC 882, DOI 10.17487/RFC0882, November 1983,
https://www.rfc-editor.org/info/rfc882.
Consortium, I. S. (2019, March 6). QNAME minimization and your privacy. ISC-ISC.
https://www.isc.org/blogs/qname-minimization-and-privacy/
Bortzmeyer, S., “DNS Query Name Minimisation to Improve Privacy”, RFC 7816, DOI 10.17487/RFC7816, March 2016,
https://www.rfc-editor.org/info/rfc7816.
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, “Specification for DNS over Transport Layer Security (TLS)”, RFC 7858, DOI 10.17487/RFC7858, May 2016,
https://www.rfc-editor.org/info/rfc7858.
Reddy, T., Wing, D., and P. Patil, “DNS over Datagram Transport Layer Security (DTLS)”, RFC 8094, DOI 10.17487/RFC8094, February 2017,
https://www.rfc-editor.org/info/rfc8094.
Hoffman, P. and P. McManus, “DNS Queries over HTTPS (DoH)”, RFC 8484, DOI 10.17487/RFC8484, October 2018,
https://www.rfc-editor.org/info/rfc8484.
Internet Society. (2019, December 2). ¿Qué es un ataque de intermediario (MITM) ISOC.
https://www.internetsociety.org/es/blog/2019/11/que-es-un-ataque-de-intermediario-mitm-por-sus-siglas-en-ingles/
Internet Society, (2019, March 21). DNS privacy. ISOC.
https://www.internetsociety.org/deploy360/dns-privacy/
DNS Privacy Project. www.dnsprivacy.org.
https://dnsprivacy.org/
LACNIC, (2019, October). Panel Privacidad en el DNS,
https://www.lacnic.net/innovaportal/file/4020/1/panel-privacidad-dns-intro-v3.pdf
LACNIC 32. (2018, October 8). Panel – Evolución de la privacidad y seguridad del DNS [Video]. YouTube.
https://www.youtube.com/watch?v=c-YE1_aBa8k
LACTLD REPORT #12. (2020, December 29). Privacidad en el DNS. LACTLD.
https://lactld.org/wp-content/uploads/2021/01/LACTLD-Report12-ES.pdf
[1] The Internet Engineering Task Force (IETF) is an open international standards organization whose purpose is to contribute to Internet Engineering and which acts in various areas, such as transport, routing, and security.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.