[Updated] I'm clearly not the only one who thinks that DNS over HTTPS is a big deal. The United States Congress has sent a letter to Google about this (under the pretense of anti-competition issues raised by ISPs who would be unable to see and subsequently sell DNS information about their customers) and the Mozilla foundation is assuring the UK government that this will not be the default configuration for Firefox in the UK.

The push for more and more privacy continues apace, which is wonderful for individual citizens... but it is less good for enterprises that are serious about trying to defend their information assets. In the last few months first Firefox and now Google Chrome have announced that they have rolled out initial support for DNS over HTTPS. What are enterprises to do?

What's the Problem?

Prior to DNS over HTTPS and DNS over TLS, all DNS resolution within an enterprise could be expected to occur over UDP and TCP ports 53. Further, this data would be unencrypted. This proves to be very valuable, especially as the majority of web activity has transitioned to TLS. In the (very) old days, even without visibility into the DNS requests, you could simply connect to a host on port 80 or 443 and find out which site was running there. Once we moved into the age of virtual hosting and HTTP 1.1, this became far less feasible since you would simply find yourself looking at some default web server page rather than an actual "site."

In other words, with access to the DNS data, we could correlate outbound connection addresses to DNS queries to gain some insight into the kind of communication that is occurring. A move to DNS over TLS, which operates over port 853, makes these requests opaque. DNS over TLS, however, really isn't a big problem for an enterprise; simply block outbound connections from internal hosts to port 853.

DNS over HTTPS really ups the ante. Using this technology, the web browser sends an API request over HTTPS on port 443 to a known resolver. This is, effectively, indistinguishable from a normal HTTPS web session. Certainly, today, we could make an effort to identify all known DNS over HTTPS resolvers, but that is a Sisyphean task; within a very short time, I am certain that there are likely to be thousands to millions of DNS over HTTPS resolvers.

Don't Panic

First, stand back and take in the overall landscape of the issue. If you have a well managed (i.e., centrally controlled with systems built from images and tightly controlled via Group Policy), I'm not sure there's a problem. In such an environment, you surely wouldn't allow users to install arbitrary software (including web browsers). Additionally, you should be controlling the configuration of the software through Group Policy, which would mean that we can prevent the browser from attempting to establish an outbound TLS connection for DNS resolution internal to the browser.

While that all sounds good, you might be saying, "Our controls aren't quite that tight." If that's the case, there's still hope. We can leverage the concept of "normal" behavior for systems operating on the Internet. If a user opens a web browser and tries to connect to a website, we would fully expect there to be a DNS request first. Therefore, if we see an outbound connection on port 443 without a preceding DNS lookup over port 53, we can assume that the resolution happened over some other path. In the context of DNS over HTTPS, it would be fair to assume that DNS over HTTPS was the path.

If we arm ourselves with an organizational policy that requires all internal systems to send all resolution queries through our central DNS servers, we have a hammer with which to smack down potential offenders. How can you find these outbound connections for which there were no preceding DNS requests? Look no further.

David Hoelzer is the author and maintainer of the SANS SEC503 Advanced Intrusion Detection course, the leading class for advanced network analysis in the industry. With more than 30 years of experience in information technology and security, he is the author of and a contributor to a number of open source defensive tools. In addition to acting as the Chief of Operations for Enclave Forensics, Inc., an incident response, secure coding, and managed services corporation, David is also the Dean of Faculty for the SANS Technology Institute (STI).