DNS over TLS (DoT) and DNS over HTTPS (DoH) are two new versions of DNS designed to encrypt the communication between DNS clients and recursive DNS servers. These are both good things by solving a longstanding “gap” where DNS queries were transmitted unencrypted. The unfortunate part of these things is how it has been implemented. Apple’s implementation, in particular, effectively changes the way DNS works at the operating system level.
New Changes Bring New Problems
So why do these new DNS privacy standards create problems? Let’s first talk briefly about one of the two protocols: DoT. DoT traffic is encrypted, but its use of a well-understood port (TCP port 853) makes it easier for network administrators to monitor and control encrypted DNS when it appears. Similar to standard DNS, it’s also used by a single stub resolver, making it easier to manage on a client-by-client basis. That makes it easy to control and monitor.
DoH is the real troublemaker here. It leverages HTTPS to provide encryption and authentication between a DNS client and server. Still, since it uses the same TCP port (443) that all HTTPS traffic uses, it becomes a real challenge to troubleshoot DoH-related DNS issues because of the inability to distinguish DoH-based DNS requests from regular HTTPS requests. DoH relies on a handful of centralized and external cloud DNS providers. Users will essentially bypass existing corporate DNS services since DoH DNS requests are encrypted and invisible to third parties, including cybersecurity software that may rely on passive DNS monitoring to block requests to known malicious domains.
But that’s not all. Apple’s recently released versions of iOS and macOS now support both DoT and DoH protocols. That’s an important development as it affects a greater number of devices. For example, as users upgrade to newer versions of Apple’s operating systems, be it on their handhelds, tablets, desktops, and laptops, these changes are automatically deployed without user interaction.
From an implementation standpoint, these settings can be applied selectively, ranging from the entire operating system through MDM profiles or network extension to individual applications or selected network requests of applications. The latter is the most interesting, where developers can create applications that use DoT and DoH directly from individual apps – and potentially introduces the potential for a proliferation of resolvers maintained by various entities. Beyond Apple, we expect future Microsoft operating systems to leverage similar implementations.
Communications Service Providers Are Not Immune
Communications service providers (CSPs) have invested heavily in their networks to provide a safe, reliable and fast network experience for their subscribers. We all are depending on the Internet more than ever. Beyond providing entertainment at home, for many, it is now their primary means for work, education and, for some people, their healthcare. CSPs rely on their DNS investment as a significant element of their network control plane to ensure fast network experiences and keep users safe from malware and other Internet-borne threats.
If CSP DNS infrastructure is no longer be in the path of subscriber DNS requests, they can’t offer DNS-based network-level content filtering and protection. That means that parental controls won’t work, and households with children will need to set up and manage parental controls on a per-device and even a per-application basis. And as I mentioned in a previous blog, parents are not keen on being sysadmins.
Let’s not forget about security. With CSP infrastructure bypassed, DNS-based security controls that protect subscribers from common threats such as lookalike domains and malware sites are also bypassed, increasing exposure to data exfiltration and malware proliferation on the provider network. It’s one of the reasons why the United States National Security Agency (NSA) recently posted guidance that organizations host their own DoH resolvers and avoid sending internal DNS traffic to external third-party resolvers. Within months of being released, we saw malware that used DoH to encrypt malicious communications allowing it to hide in regular HTTPS traffic and install malware that can steal data or add a victim to a botnet.
From a regulatory perspective, implementing regional or in-country obligations will be a significant challenge when there is no business relationship or legal authority over a company outside of the CSP’s network or country. Consider that CSPs must block access to pornography for children or block access to terrorist websites in many countries. How can providers meet these obligations if their content controls no longer reside on their network?
Last but not least: speed and performance. I stream—a lot. And I can’t stand buffering. DNS is the first message to initiate most IP conversations, and low latency is critical to get the best performance and experience. That’s why many CSPs have invested in on-net content caching to provide subscribers with the best content experiences. DoT and DoH DNS requests will travel off-network, effectively bypassing this local on-net content. That means that some subscribers can receive less localized content or be directed to non-geographically optimal CDN caching locations.
And DNS is used to optimize connectivity to streaming video caches and other content based on the client computer’s IP address. With DoT and DoH, how CDNs localize clients (meaning, the ability to direct traffic to the most geographically optimal CDN caching node) is affected. If CSPs cannot view subscriber DNS queries, they may not be able to route subscribers to the geographically closest or most efficient CDN node.
The Solution: Provide On-Network DoT and DoH Services
Using DoT and DoH to encrypt traffic between DNS clients and recursive DNS servers is not going away (with the adoption of DoH taking the lead), and this adoption will only increase. The only way for CSPs to tame the beast is to deploy encrypted DNS servers on their networks. The solution? Offer on-premise DoT/DoH capabilities to the subscriber base.
Luckily, Infoblox Encrypted DNS for CSPs provides efficient encryption while delivering Infoblox best-in-class DNS. Infoblox Encrypted DNS enables Infoblox to encrypt last-mile DNS communications between their endpoints and DNS servers regardless of which protocol the endpoint supports while solving performance concerns associated with the additional overhead related to encrypted DNS communications. The ability to accommodate encrypted DNS allows CSPs to maintain control over their DNS investment and continue to offer the safest and fastest experience possible with microsecond latency.
