Privacy and security specialists are in the middle of a very public fight over the future of Internet encryption. In September, cable companies and other telecommunications industry groups in the United States sent a letter to Congress protesting Google’s plans to encrypt domain name servers (DNS) in the browser. Mozilla sent a letter [PDF] of its own this month, asking lawmakers to reject the industry’s lobbying efforts, saying they were based on “factual inaccuracies.”
At stake is how DNS traffic—the network queries that translate people-friendly domain names into server IP addresses—should be encrypted.
When a user types a domain name into a web browser or a networking device, the browser (or device) asks the nearest DNS server for the IP address associated with that domain name. The DNS server responds with the IP address for the browser or device to use.
By default, these requests and responses are sent over the network in plain text, which means someone can potentially intercept the queries and redirect users to a different destination. Plain text DNS queries also allow network administrators to tell where users are going on the Internet—the actual activities may be encrypted, but knowing the destination can provide valuable information.
No one is arguing that DNS shouldn't be encrypted. Bad actors shouldn't be able to intercept and redirect users to malicious sites that host malware or phish user credentials and information. The disagreement is over how that encryption should be done.
There are two options: Hypertext Transfer Protocol Secure (known as “DNS over HTTPS”) or Transport Layer Security (called “DNS over TLS”).
DNS over TLS emphasizes security and gives network operators more control, while DNS over HTTPS emphasizes user privacy. From a usability standpoint, users won’t notice any differences with either approach. But from the perspective of network administrators, the two approaches pit security against privacy.
Two Ways to Encrypt
Modern networks rely on Transport Layer Security (TLS) to securely exchange data, such as for web browsing, file transfers, VPN connections, remote desktop sessions, and voice-over-IP. One side of the connection, typically the server, has a digitally-signed certificate issued by a trusted certificate authority. The other side of the connection, typically a client, relies on the certificates to verify who it’s communicating with.
Since TLS is already widely deployed to handle privacy, authentication, and data integrity, extending the protocol to cover DNS is very logical. DNS over TLS (IETF RFC 7858) defines how DNS packets would be encrypted using TLS and transmitted over the widely-used Transmission Control Protocol (TCP).
By default, DNS travels over Port 53 via TCP or User Datagraph Protocol (UDP—an alternative to TCP). With DNS over TLS, all encrypted packets are sent over Port 853.
Most public recursive servers, including Cloudflare, Quad9, and Google, already support DNS over TLS, and enterprises running their own DNS infrastructure can enable it, as well. Google set up DNS over TLS for Android Pie (Android 9) to allow users to set a DNS server for both Wi-Fi and mobile connections, and many applications and devices are already designed to work with this option.
"We solved the problem by adding TLS to DNS," said Paul Vixie, the inventor of DNS and CEO of Farsight Security, but he acknowledged the solution isn't "Web-friendly" in the sense that there isn’t an attractive user interface to enable the feature. "It doesn't feel like the Web,” he says. “It didn't come from the Web people, so they made their own."
DNS over HTTPS (IETF RFC8484) is very much designed for the Web, as it throws all the data packets into the HTTPS stream with all other encrypted Web traffic. Unlike its competitor, DNS over HTTPS does not encrypt the individual queries, but instead passes them through an encrypted tunnel between the client and server. Since the connection uses HTTPS and HTTP/2, all the packets look the same. Anyone monitoring Port 443, the standard HTTPS port, won't be able to identify DNS queries from all other Web traffic.
Pros and Cons
For the privacy-minded, DNS over TLS isn't good enough because anyone monitoring the network will know that any activity on Port 853 must be DNS-related. While an observer won't know the actual contents of the query because both the response and request are encrypted, the fact that anyone could know that queries are being made is enough to raise warnings flags for some. While secure, DNS over TLS isn’t as privacy-friendly as DNS over HTTPS.
Another downside of DNS over TLS—as far as opponents are concerned—is that it requires software developers and device makers to make changes so that their applications and hardware support the protocol. The resolver may have the certificates to handle the encryption, but if the program or device can’t (or won't) establish the connection, DNS over TLS isn’t protecting the user.
DNS over HTTPS is more democratic, as anyone using a supported web browser automatically gets encrypted DNS. DNS over HTTPS stops all third parties—bad actors, Internet service providers, government agencies, law enforcement, and network operators (including corporate IT staff)—from seeing anything about what sites viewers are browsing. That's exactly what privacy advocates want, but it's the opposite of what network administrators and security teams need.
Privacy vs Security
DNS over HTTPS treats privacy as absolute—but parental control applications, antivirus and security software, enterprise firewalls, and other networking tools don’t share that ethos. Having DNS over HTTPS turned on by default in the web browser means all DNS queries are relayed to the designated DNS server, which may not be the organization’s own DNS server, or even the ISP’s.
Mozilla has announced that DNS over HTTPS will be the default for Firefox users in the United States, and that change is currently being rolled out. Firefox will automatically relay all DNS traffic to Cloudflare’s 126.96.36.199 service and ignore the user's existing DNS settings. That bypasses all associated network-based filtering rules, such as those that block malware from communicating with command-and-control servers, or that stop users from accessing malicious or illegal sites.
DNS is a "reasonable place to restrict access" to bad entities, Akamai’s April said. Network operators block hostnames used by Wannacry and other malware or redirect users who try to access malicious or banned sites. Operators of public Wi-Fi networks modify DNS queries to first load a network sign-on page for new users. DNS over HTTPS breaks these use cases.
This is partly why Mozilla is not turning on DNS over HTTPS for Firefox users in the United Kingdom, as UK law requires ISPs to block access to illegal websites, such as those related to child pornography. Losing visibility over the network is dangerous, April said.
DNS over HTTPS versus DNS over TLS is also a battle over the user’s web browsing data and who gets to access it. DNS queries from Firefox will go to Cloudflare, which means Cloudflare is going to be sitting on top of a lot of DNS data. The tech companies that operate centralized DNS servers—such as Cloudflare and Google—will ultimately benefit with DNS over HTTPS, as they will be the ones with more visibility into what people are browsing, Vixie said.
Privacy advocates believe that users should be in charge of their web browsing, not ISPs. But Mozilla’s decision forces Firefox users to use Cloudflare regardless of their own preferences.
Most users won’t notice any difference when encrypted DNS becomes the default—which has already happened for Chrome users. For enterprises and ISPs, the socially-conscious, user-oriented approach forces a tradeoff: the price for increased privacy is reduced security.
The reality of the modern Internet is that ISPs and enterprises play a role in keeping threats away from users. Ideally, web browsers should let users choose whether or not to use DNS over TLS or DNS over HTTPS, and give users the option to control which DNS provider to use.
This story was updated on 2 December 2019.