DNS filtering uses threat intelligence and research to identify and categorize domains, and then redirect disallowed queries to a block page, preventing a user from accessing malware downloads, phishing sites, and background scripts that are inserted into compromised web pages. This helps organizations limit risk within the environment as an important layer of security, and to comply with regulations that require them to, for example, prevent children from being exposed to objectionable material (usually referred to as content filtering). But this means network admins rely on the fact that the DNS queries can be intercepted and examined somewhere in the chain to route the requests appropriately.
And because DNS and DoT each have their own port and protocol, administrators have more visibility and control because they can, for example, block DNS requests to other resolvers at the firewall, preventing a user from bypassing the protections they have in place by changing their DNS settings. This can also prevent malware from using DNS channels to communicate with their command and control.
How we got here
Recently, there is a new standard that has begun to gain traction, especially with the intense focus on privacy we face today. DNS over HTTPS (DoH) is the new kid on the block, and has the support of privacy advocates, including the browser vendors. Most browsers (and soon Windows itself) support connections to publicly available DNS providers configured to use DoH. Conversely, there are also has many enterprises and other organizations unhappy with the decision. The main reason behind this concern is that DNS over HTTPS uses the same ports and protocol as secure web traffic, making it more difficult to identify. This has three main effects:
- It’s more difficult to restrict unauthorized DNS traffic—you can’t limit traffic on the port it uses because it is the same port used by all web traffic
- It’s nearly impossible to control browsing or track DNS queries (like blocking websites with objectionable content or hosting malware) because the traffic is encrypted straight to the public DNS servers
- The only way to use DoH is to bypass internal DNS servers, preventing access to local resources and bypassing DNS protections admins have in place because enterprise DNS servers don’t yet support DoH
The second point is concerning, now that news has started to surface that malware creators have started using DoH channels for communication with their command and control servers. This traffic is no longer easy to spot in a network.
Much like the VHS vs. Beta argument years ago, debates have raged over which secure DNS solution is best. But it seems the browser providers and some public DNS providers have settled on DoH because it is easier for consumers, putting some stress on network admins. Chrome, Firefox, and now Microsoft have all focused their efforts on supporting this infrastructure. Most of these efforts are focused on the home user, however, which will present challenges when using these browsers in a business environment. Unfortunately, each manufacturer has a slightly different implementation and controls around it, meaning an administrator who wants to prevent users from having to configure DoH (or using it natively) have to navigate several different instruction sets.
So back to the original question: Is the business world ready for DoH? Not by a long shot. It will likely take some time for applications and business infrastructure to fully support this new secure DNS method, assuming it takes off. Until then, configure your policies to prevent its use, continue using your DNS protections and infrastructure, and let’s wait for all this to settle out. In part two of this series, we will examine what settings need to be configured to prevent use of DoH in each of the major browsers.
Gill Langston is head security nerd for SolarWinds MSP. You can follow Gill on Twitter at @cybersec_nerd
