DoT and DoH have been in the news a lot over the last couple of years. The reason being is that they have the potential to change the way the internet functions. With Apple’s recent releases of iOS 14 and macOS 11, as well as, new protocol efforts ongoing at the IETF, we can now see just how many things are changing. Even the United States National Security Agency (NSA) has newly posted guidance for organizations to host their own DoH resolvers and to avoid sending internal DNS traffic to external third-party resolvers.
Significant but Under-reported Changes
With little fanfare, Apple fundamentally changed how DNS and HTTP function together within their operating systems. The impact of these changes leaves many enterprises with gaping holes in their network’s security. Before the latest OS releases, DNS was configured using DHCP from the OS or an administrator’s network or static assignment. The process worked the same as it has since the 1980s, where the DNS setting is available to all the OS applications that use it. Apple has moved from this easy to understand and secure model, to a new model that adds significant complexity. Making things more problematic, Apple has sparsely documented this new set of behaviors via videos and developer documentation from WWDC. Given the documentation’s sparsity, I will outline the two most concerning changes they have made.
Apple DoT/DoH DNS priority list for iOS14 and macOS
Apple’s new support for DoT and DoH creates further steps and a (potentially) more complicated DNS resolution path:
- Resolution of captive portal test zones using the network provided DNS resolver
- Encrypted resolvers set by VPN configuration
- Encrypted resolvers set by MDM products
- Encrypted resolvers set by device owners
- Encrypted resolvers set by domain owners
- Encrypted resolver set by apps
- Traditional unencrypted resolvers set by Users or DHCP
While the first four make sense, items 5 and 6 are where businesses should tread carefully to avoid introducing risks.
For step 5, encrypted resolvers can now be specified by domain owners using Adaptive DNS Resolver Discovery. Once this process has occurred, all subsequent DNS queries to that domain are sent to the encrypted resolver specified by the domain owner. This will bypass DNS firewalling of known malicious fully qualified domain names and prevent the use of analytic techniques that find DNS data exfiltration and other misuses of DNS. Beyond the standard itself, Apple’s only documentation is a few minutes of video during the most recent WWDC.
In step 6, the same set of risks is introduced by giving individual applications control over the DNS resolution path. Imagine a social networking app abusing this to collect even more data about their user’s behavior within the application. While it is also possible for applications to directly build a DNS resolver within, as Mozilla has with their browser, doing so does not make it a good idea. It creates new risks without solving the privacy problem.
The best way to prevent the security risks introduced by steps 5 and 6 is to block encrypted DNS services not provided by your network and, instead, provide your own encrypted DNS service that works with steps 3 and 4.
Support for Experimental DNS HTTPS and SVCB Records
While these new record types offer exciting applications in speeding up the internet, the negative is that they also bypass traditional DNS protections like RPZ. In particular, a new “hints” functionality allows a fully qualified domain name (FQDN) domain to be searched with several values being returned. One of those new values is the IPV4 and IPV6 hints. These hints contain IP addresses that will not be examined against your threat feeds by RPZ. Content delivery networks, like Cloudflare, already support these new record types. Any malware that gets hosted on their CDN will be accessible to the updated Apple devices without being blocked by your DNS Firewall. These record types are also used by the domain resolution process above.
A Look Ahead
The IETF has signaled that it will ratify HTTP/3 and Encrypted Client Hello in 2021. These protocols offer increased performance and security with a hidden impact on your security policies. These new standards clear up a weakness used by transparent proxy and secure web gateways to filter internet access on devices that can’t, or the user won’t support an explicit proxy. Most IoT and BYOD devices on enterprise networks fall into this category.
The results of these changes are significant upheavals in enterprise and service provider deliveries of security and content filtering services. Implementing encryption through the DNS resolver on your network allows you to remain in control of your user’s network experience and will allow you to continue to provide security and content filtering per your policy requirements. It’s great to see that the NSA’s recommendations mirror what we’ve previously advised customers. It also helps demystify DNS security for businesses. Google, Apple, Mozilla, and Microsoft have rolled out DoT and DoH in the last few years to protect the consumer internet. These changes are intended to promote encrypted DNS use regardless of who operates the DNS service. Unfortunately, these changes to secure traffic on the consumer-facing internet negatively affect enterprise networks’ security. Fortunately, businesses can protect networks from undue risk by running a DoH resolver and blocking access to other ones.
Additionally, the loss of transparent proxy functionality will be felt acutely by security teams for years to come. A transparent proxy could be used with most devices on the network. The last place that security teams have left to enforce policy across most devices agnostically is the DNS resolver. The NSA’s advisory helps businesses get there.
