The internet was not built with security in mind, and there are few parts of the internet infrastructure where this is more evident than the design of the domain name system (DNS).
The good news is that over the years the internet has been “retrofitted” with systems to make it more secure, and one of these retrofits is a system for encrypting DNS queries and responses traveling between client devices and DNS resolvers in enterprise environments.
Resolving DNS Queries
To understand what encrypted DNS does, let’s take a look at how a user on an enterprise network converts a domain name to its matching IP address. Typically a user’s browser or other application will send a DNS query to an enterprise DNS resolver, which will respond by returning the matching IP address from its cache, or by sending out a DNS query through the network gateway to an external DNS server to resolve the query and return the correct IP address.
Using this model, DNS queries and responses all travel across the local network, as well as the internet, in plaintext. Although this is insecure insomuch as it can be intercepted and read (and possibly even modified) by malicious actors, it also provides an opportunity for enterprises to apply security controls.
Visibility into DNS requests, enterprise resolvers can examine and filter domains and IP addresses using blacklists of malicious domains, restricted content categories, reputation information, typosquatting protections, and in many other ways. The DNS resolver can also log all of this activity. As an added layer of protection, the network gateway can be configured to block DNS requests to external DNS resolvers, ensuring that all DNS requests go to the enterprise resolver and therefore that these security measures are applied to all DNS queries.
Let’s go back to the DNS requests and responses themselves. As mentioned above, because they are all in plaintext there is the possibility for eavesdropping and manipulation of DNS traffic between the user and the resolver.
One way to protect the privacy and integrity of DNS requests and responses between user and resolver is to implement some form of encryption, and the common “retrofit” to achieve this is a system known as DNS over Hypertext Transfer Protocol over Transport Layer Security (HTTPS), often referred to as DNS over HTTPS or, more commonly, DoH. Essentially DoH encrypts DNS queries and responses using the HTTPS protocol.
Implementing DoH removes visibility into DNS requests for attackers, but also for enterprise network monitoring tools — unless there is a way in place to inspect TLS traffic, probably using local certificates and proxies. Visibility returns at the enterprise resolver — if not, the resolver would not be able to read the request.
But if external DoH resolvers are not blocked, and DoH is enabled on the user’s browser or OS and pointed at an external DoH resolver, then the internal resolver’s security measures will be bypassed. That’s because DoH requests are sent as HTTPS encrypted traffic using port 443, as normal, so the network gateway will not know that that traffic passing through it is actually a DNS query to an external DNS server which would normally be blocked.
That means, for example, that malware can use DoH to perform DNS lookups that bypass enterprise DNS resolvers and network monitoring tools, often for command and control or exfiltration purposes.
Using DoH can also surface network configuration and other problems. For example, an application which is configured to use a specific external DoH resolver will ignore the DNS resolver assigned to it by DHCP and use the external one instead. If the user is actually trying to connect to an internal domain then it could potentially leak internal network information.
Another example is when an enterprise uses different IP addresses to resolve the same domain name depending on whether the user is inside the enterprise network or outside it. If an enterprise employee on the network uses an external DoH resolver then they may be sent to the IP address for external users, making some internal services inaccessible.
What’s the Solution?
The implication of all of the above is that if you implement enterprise DoH, you need to take some specific additional steps to ensure that your overall security posture is not diminished and your network configurations are not compromised.
Block external resolvers
In particular, you need to ensure that all DoH clients can only send their DNS queries to the enterprise DNS resolver — all other DoH resolvers including external ones need to be disabled or blocked.
To do this you need to configure network security devices at the enterprise gateway to block known DoH resolvers so hosts cannot circumvent DNS security controls and cyber threat actors cannot easily use it to hide their actions. There are several publicly available lists of known DoH resolvers and their IP addresses.
Disable DoH in browsers
When it comes to individual web browsers, applications, and operating systems that support DoH, especially the ones that may enable it automatically, the NSA recommends that you “disable it in standard configurations and set canary domains so that DoH is automatically disabled. For example, Firefox and Chrome automatically disable DoH if enterprise policies are configured. Enterprise policies can also be used to configure DoH to use the enterprise DoH resolver.”
The NSA also recommends that you use DNS logging on as many network devices and hosts as possible to make up for the network visibility that is lost because of reduced DNS network monitoring capability.
Security Balancing Act
Ultimately, if you decide to implement DoH then you are committing yourself to a fine balancing act. DoH itself provides a level of security protection. But unless you take steps to block other DoH resolvers and take other appropriate measures then you risk it interfering with the working of your network monitoring tools. If this prevents them from detecting malicious activity within your network and fails to prevent malware or threat actors from exfiltrating confidential data then implementing DoH may end up diminishing your overall security posture.