Is the Business World Ready for DNS Over HTTPS (DoH)?

DNS is one of the older networking protocols in the modern technology stack. It was first invented in 1983 and was given a standard in 1987 after the IETF was formally created. Now, it’s relied upon in almost every network communication—but funnily enough, it’s one of the last things people think to troubleshoot when there is a network issue.

The original design of DNS was simple: Allow systems to resolve the address of another system, resource, or website based on a naming convention and distributed lookup. Clients made requests over port 53 to the resolver that was configured to listen for the requests. If that resolver did not have the answer, it forwarded the request upstream until an authoritative answer was found. The response was then cached by the local resolver to increase response speed for future requests. Business networks also use DNS to keep internal resources connected, giving administrators control over DNS traffic inside of and out of the network so it can be managed and monitored. Clean, smooth, and . . . well . . . pretty insecure.

Few imagined, when DNS was first designed, how it could be used for malicious purposes, mainly because it used plain text in the requests and responses. Of course, bad actors leverage everything they can to gain access to networks and data, including exploiting DNS, through tactics like:

• Spoofing DNS responses to reroute traffic
• Cache poisoning to redirect legitimate queries to malicious sites
• Packet sniffing to discover information about a network from its queries
• Transmitting data undetected within a DNS query for communication with command and control servers

Additionally, for years there have been concerns about privacy. Since public DNS services are usually provided by your ISP, that means the ISP can collect all sorts of information about you—and in some cases, use it to generate income selling that information.

Evolution of DNS security

In the intervening years since its initial creation, there have been several motions to help secure DNS traffic. One of the first widespread efforts was DNSSEC. It was designed to use cryptographic signatures to help verify the authenticity of the responding DNS resolver and its data. While work on this standard started in the 1990s, it has taken some time to achieve widespread adoption, and we’re still not there yet. Additionally, while this measure helped ensure communication with legitimate resolvers, it still did not address issues of privacy since the responses are still in plain text.

The next big leap was DNS over TLS (DoT), which was designed to allow the connection to be made securely over port 853, using TLS, between a DNS client and the resolver it communicated with. This essentially allowed the resolver to first be verified, preventing any interference with the DNS request and affirming the identity of the resolving DNS server. The query and response were also encrypted, meaning the traffic could not be snooped by bad actors. But that had a somewhat slow adoption rate globally as well, and many organizations continued to use standard DNS over port 53, because it’s the default configuration for the protocol and is easy to set up and troubleshoot.

DNS and network security

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