Routine activities such as managing DNS and DHCP, assigning IP addresses, creating and managing subnets and reporting and auditing device connection history can take more than their fair share of time and resources. Moreover, concentration of DNS, DHCP and IP address management expertise in fewer hands makes organizations heavily dependent on a few individuals without adequate backup.
The way enterprises, applications on the network, and endpoints are working is changing significantly.
Security enhancements now being widely deployed, known as DOT (DNS over TLS) and DOH (DNS over HTTPS), are designed to prevent eavesdropping and improve privacy by encrypting DNS traffic that originates from end users. This is part of a wider initiative to encrypt all end-to-end communications over the Internet.
DOT and DOH, the two technologies that have emerged out of a desire to encrypt DNS traffic, take different approaches. DOT is typically implemented at the device layer so that all DNS communication is encrypted, regardless of the application. A DOT-enabled DNS resolver can be deployed internally within the organization, but more commonly they are hosted externally on the Internet so that they can be used by anyone to encrypt all DNS traffic originating from the client as it navigates the Internet. How these DOT resolvers are configured within the operating system is still the subject of much debate, and efforts are underway to define an automated discovery mechanism so that users can take advantage of DOT (or DOH) without having to perform any manual configuration.
DOH is similar but application specific. Commonly DOH is used by web browsers that nominate a trusted resolver to provide a DOH service. Some browsers (such as Firefox) will have these trusted resolvers hard-coded by default (but can be changed) and can result in DNS queries being sent to an unauthorized DOH resolver operated by an external company with whom you have no commercial or legal relationship. Other browsers (such as Chrome) may perform tests to see if the operating system has been configured with any DOH enabled resolvers, and if so then use those. The important thing to remember is that the mechanism for selecting a DOH resolver is determined by the application, not the operating system. As more DOH-enabled applications are installed, it is conceivable that numerous unauthorized DOH resolvers could be utilized, not all of which are necessarily trustworthy.
In both DOT and DOH cases, all DNS traffic is now encrypted all the way through the enterprise network and out to these external DOT or DOH-enabled resolvers. Devices and browsers that use DOT and DOH completely bypass the internal corporate DNS servers, communicating directly with external DNS resolvers that are not under your organization’s control. IT administrators have no visibility into this DNS traffic and any DNS security controls that have been implemented are completely bypassed, providing no protection whatsoever. Attackers can exploit this by developing malware that utilizes these encrypted security channels to bypass the corporate security infrastructure. An recent example includes a piece of malware called PsiXbot which uses DOH to communicate with a command and control server, completely bypassing all security controls. This attack method can be used to exfiltrate data or deliver additional exploits into the network.
To prevent DOT and DOH protocols from being abused is not as simple as it might seem. DOT can be blocked relatively easily at the perimeter as it uses a well-known port (853), however DOH uses port 443, which is also used for https traffic – blocking it will also block a very large percentage of web traffic. Because DOH DNS queries are embedded inside encrypted https requests, it can quickly get very expensive and troublesome if the perimeter security firewall has to decrypt these https packets, inspect the embedded DOH queries and then remove or substitute them whilst finally re-encrypting the packet and forwarding it onto its intended destination.
Browser vendors are introducing signaling mechanisms to control whether DOH is enabled or not. Firefox introduced the concept of a “canary domain” to control whether it performs DOH enabled queries – if the domain is resolvable and a specific type of response received, then DOH will be disabled. But each application can provide a different signaling mechanism, or none at all, in the case of malicious applications.
DDI vendors in the security ecosystem like Infoblox and BlueCat Networks are beginning to publish lists of public DOH servers that can be used to block queries to specific IP addresses and URLs so that DOH enabled applications cannot contact unauthorized DOH resolvers. This can be a little like “whack-a-mole” as new servers could spring up undetected or potentially change IP address – all it takes is for a new app to be published that people download onto their phones and when they use the company WiFi they could already be using an external DOH-enabled DNS server. Unfortunately, this is not a complete solution and relies on timely discovery of new DOH resolvers and rapid distribution of block lists. However, until a standardized mechanism is agreed that addresses these problems (which will never happen because there will be application authors that do not wish to comply), there isn’t really any other viable solution available, apart from https inspection, which can be very expensive in terms of performance impact and cost.
To learn more, check out the following resources:
- This is Sara Dickinson’s post that sparked off a lot of discussion in the community: DoH – It’s DNS Jim, but not as we know it!
- This recent SANS Institute report confirms the unmitigated usage of encrypted DNS, particularly DNS over HTTPS, that could allow attackers and insiders to bypass organizational controls.
- This half hour video from Infoblox on the impact of DoT & DoH on the enterprise DNS is well worth a watch.
- Netscout provides another good overview of the topic.
- Many experts say DNS-over-HTTPs causes more problems than it solves including PowerDNS’ CTO, Bert Hubert and Hackaday’s Maya Posh.
- ISC (the developer of the popular BIND DNS server) resources include Alan Clegg’s webinar and Vicky Risk’s blog post.
- Finally, a fantastic overview article describing what is at stake from Wired magazine.
“RFC 8484 (which adopted DNS-over-HTTPS as a standard ) is a cluster duck for internet security. Sorry to rain on your parade. The inmates have taken over the asylum.” Paul Vickie – Internet Pioneer, DNS Authority
DNS, one of the most important and overlooked technologies powering the Internet, is experiencing more change with the introduction of DOT and DOH than it has in the last 30 years. Established enterprise security controls are being bypassed, a situation that can be exploited by attackers. Elegant scalable solutions beyond lists of DOH servers to block queries are not yet available as industry adapts to the new multi-verse world of DNS.
– Paul Roberts
A significant number of your employees are now working from home as the pandemic continues to spread globally and the need to protect people’s health takes number one priority. In this situation, companies have had very little time to prepare for such large scale remote work and think about how to secure these devices that are now accessing corporate resources from outside the perimeter. But work from home doesn’t mean you have to compromise on security. Read this white paper to learn about:
- Top security challenges around teleworking
- Evolving threat landscape in the current scenario and top attacks that could target your remote users
- How to secure your work from home users using foundational network services