By Paul Adair, Principal Product Manager, and David Ayers, Senior Product Marketing Manager, Infoblox.
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 and new protocol efforts on-going at the IETF, we can now see how much things are changing. Even the United States National Security Agency (NSA) has newly posted guidance that organizations host their own DoH resolvers and 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 in 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, with that DNS setting available to all 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, below are 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 five and six are where businesses should tread carefully to avoid introducing risks.
For step five, 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 six, the same set of risks is introduced by giving individual applications control over the DNS resolution path. Imagine the TikTok 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 provide your own encrypted DNS service that works with steps three and four.
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 queried and return several values.
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 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 result of these changes is significant upheaval in enterprise and service provider delivery of security and content filtering services. Implementing encryption at the DNS resolver on your network allows you to remain in control of your user’s network experience and to continue to provide security and content filtering that your policies require.
It’s great to see the NSA’s recommendations mirror what we’ve previously advised customers and help 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 affects 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.
