DNS has traditionally suffered from a “last mile” security problem: Communications between a DNS client and its local DNS server are almost always “in the clear” (that is, unencrypted) and therefore subject to spoofing, interception and other interference. The IETF has proposed two mechanisms to address this issue: DNS over TLS (DoT) and DNS over HTTPS (DoH). However, both mechanisms can be used to circumvent organizations’ existing DNS infrastructure, which Infoblox believes is not in the best interest of their security. This post explains DoT and DoH in more detail and outlines our recommended approach for addressing DNS client security issues.
DNS over TLS (DoT) and DNS over HTTPS (DoH) Explained
While DNS Security Extensions (DNSSEC) add authentication and data integrity checking to DNS, they usually miss the DNS client: the local DNS server performs DNSSEC validation and establishes the authenticity and integrity of the data and then passes the result to the DNS client. That last leg of the communication, however, can be spoofed.
The IETF’s DPRIVE (DNS PRIVate Exchange) Working Group has developed two new mechanisms that help address DNS’s “last mile” problem: DNS over TLS, called DoT for short and documented in RFC 7858, and DNS over HTTPS, or DoH, and documented in RFC 8484.
Both DoT and DoH supply important functionality: Communications between DNS clients and DNS servers using DoT or DoH are encrypted, providing data privacy and integrity, and DNS clients may optionally authenticate DNS servers using either protocol.
DoT uses a unique TCP port, 853. DoH, however, uses the same TCP port used by other HTTP-S traffic, 443. Therefore, it is very difficult to distinguish DoH from other HTTP-S traffic.
For some time, Infoblox has recommended that customers block direct DNS traffic between arbitrary internal IP addresses and the Internet. This step prevents certain types of malware, including DNSChanger, from working, and forces internal hosts to use IT-managed DNS infrastructure. That internal DNS infrastructure may apply a name resolution policy using security mechanisms, such as response policy zones (RPZs). The use of DoH, however, makes it very difficult to prevent internal hosts from querying DNS servers on the Internet. (DoT is straightforward to block because it uses a unique, well-known port.)
Some applications that support DoH also may deliberately ignore local DNS client configuration. Mozilla’s Firefox browser, for example, has experimental support for DoH in some builds. When enabled, Firefox will ignore any local DNS configuration and send DNS queries over HTTP-S directly to Cloudflare. This bypasses any local security mechanisms, such as RPZs, and makes a user’s DNS resolution opaque to the IT organization. It also adds complexity to troubleshooting DNS problems because now one application (i.e., Firefox) on a device uses different DNS servers than other applications.
We don’t question the motives of the developers of DoH: One of their goals was to help safeguard web browsing on parts of the Internet where snooping on DNS traffic and manipulating DNS responses is routine. But we question its suitability for use on enterprise networks.
Infoblox Implementation Recommendations for DoT and DoH
Infoblox’s recommendation is that companies block direct DNS traffic—including DoT and DoH—between internal IP addresses and DNS servers on the Internet, including Cloudflare’s. This approach should force users to employ their company’s internal DNS infrastructure, allowing their IT organization to apply DNS resolution policy and troubleshoot problems.
Blocking standard DNS and DoT traffic between internal IP addresses is simple. Firewall rules like the following should suffice:
# Allow queries from authorized internal DNS servers to the Internet
allow tcp/udp in/out <authorized internal DNS server 1> on port 53
…
# Deny queries from other internal IP addresses to the Internet
deny tcp/udp in/out to all IP addresses on port 53
deny tcp/udp in/out to all IP addresses on port 853
Blocking DoH is trickier, since to a firewall it’s indistinguishable from HTTP-S, but the following firewall rules should work:
# Block DoH to Cloudflare
deny tcp/udp in/out to 104.16.111.25 on port 443
deny tcp/udp in/out to 104.16.112.25 on port 443
deny tcp/udp in/out to 2606:4700::6810:7019 on port 443
deny tcp/udp in/out to 2606:4700::6810:6f19 on port 443
# Block DoH to Google Public DNS
deny tcp/udp in/out to 8.8.8.8 on port 443
deny tcp/udp in/out to 8.8.4.4 on port 443
deny tcp/udp in/out to 2001:4860:4860::8888 on port 443
deny tcp/udp in/out to 2001:4860:4860::8844 on port 443
Our Position
While we believe circumventing internal DNS infrastructure is a bad idea, Infoblox thinks that solving DNS’s “last mile” problem is important and worthwhile. We’re working closely with our partner, the Internet Systems Consortium, to support DoT in an upcoming version of BIND and then in Infoblox’s NIOS.
