Google DNS over HTTPS – Good for Users, a Challenge for Enterprise…

RFC 8484 defining DNS over HTTPS (DoH) has been around for a while with organizations such as CloudFlare already offering production solutions in the space. That being said, there is nothing like having Google announce general availability of their DoH service to really get the industry buzz going. Well that’s exactly what happened on Wednesday, June 26th, when they announced general availability of their Google Public DNS over HTTPS.

The result of this is going to be a steady stream of discussion from media and relevant players in the field talking through the good and bad for the foreseeable future. This is fueled by the fact that there is a competing standard to DoH in the form of DNS over TLS (DoT). Unfortunately, the bulk of this commentary will be focused on the individual consumer and how it affects them without making much distinction from the enterprise use case. So, we wanted to take a moment to look at things through an enterprise rather than consumer lens.

The Basics

While we won’t go deeply into what DNS (Domain Name System) is here, for those of you that aren’t familiar, you can think of it as the yellow pages for the internet. It essentially provides lookup and translation of the common language descriptions we use for web locations, such as www.empowerednetworks.com, to the IP addresses that they represent (182.107.41.75 at the time this was written).

DNS is one of the oldest protocols still in use on the Internet today; the current implementations of DNS clients and servers found in the latest operating systems like Windows 10 or MacOS Mojave are based on RFC 1035, which was written in 1987. The Internet was a very different place in 1987, and scant attention was paid to security matters in many of the foundational protocol specifications including DNS.  In the RFC 1035 DNS spec, the interactions between the client making the DNS request and the DNS servers providing the answer are carried out using the UDP protocol in plain text on port 53. This means that it is possible to see the content of the DNS queries in the packets while they are in transit on the network. 

These characteristics made it possible for bad actors to compromise the conversation and modify the content of the responses without the client being aware. Later modifications, in the form of DNSSEC (Domain Name System Security Extensions), provided a mechanism to address the issue of being able to verify DNS records as trustworthy.  DNSSEC, however, did not provide a mechanism to protect the DNS channel itself; queries and responses still flow in clear text. As such, although an observer of the network traffic could no longer alter the DNS queries without detection, they were still able to see the content and the information about which sites a user was visiting contained therein. 

Encrypting the Query

The obvious solution to the perceived problem of an unprotected query channel was to wrap the channel in some form of encryption.  We already commonly encrypt web browsing traffic and API-related traffic, so why not do the same for DNS?

Enter DNS over HTTPS (DoH defined in RFC 8484) and its alternate solution, DNS over TLS (DoT defined in RFC 7858and RFC 8310). Both aim to encrypt the content of the DNS queries but do so in slightly different ways that have significant implications for enterprise. In both cases the contents of the DNS queries are encrypted and leverage TCP rather than UDP as a network transport. DoH utilizes the HTTPS protocol to encapsulate the DNS query payload while DoT does the same thing but with TLS directly. Either way, the content of queries and the associated information about where the user is going are no longer visible through simple inspection of the network traffic.

The Good and the Bad

DoH utilizes HTTPS as an encryption mechanism for the DNS queries, literally encapsulating DNS traffic in HTTP for exchange. As such, communications are carried out over port 443, the same port that all other encrypted web traffic uses.

On the pro side, the content is indeed encrypted, and, by virtue of the HTTPS protocol, you have the ability to directly leverage useful HTTP features (caching, redirecting, proxying, compression, and the like) to achieve some traffic optimization.

On a less positive note, the integration of the DNS queries into the larger HTTPS stream introduces challenges to enterprise network and security professionals. These folks rely on access to the information in the DNS query stream to help prevent malicious activity (as much as 90% of malware utilizes DNS as a mechanism of action) and enforce corporate standards of network use. While it is possible to utilize web proxies in order to allow access to the contents, the requirement to tweeze these DNS specific packets out of the larger HTTPS stream requires more use of expensive resources that are often already taxed. This could become even more challenging when one considers that the DoH standard allows for the possibility of direct interaction between a user’s browser and an external DoH server without using the OS level DNS resolver as is done today. The result is potential circumvention of a number of security precautions and controls implemented at the OS level. 

Let’s flip the page to DNS over TLS now. DoT also provides encryption of the DNS queries, utilizing TLS directly, but, unlike DoH, it does so via communication over a dedicated channel, port 853, separate from other communication such as encrypted web traffic. This separation makes it easier for the network and security teams to identity and interact with this traffic. This same separation also keeps the DNS query process out of the web application domain and avoids the direct browser to DNS server communication channel that we alluded to above. 

A down side for DoT that is often cited is the fact that by maintaining the DNS traffic in a separate channel, it is still easier to track the activity of individual users than with DoH. But keep in mind that we are approaching this from point of view of a corporate environment where security and appropriate use take precedent over individual free access to external sites.

For those that have some familiarity with the debate between DoH and DoT, I’m keenly aware of the human rights related arguments for the benefits of DoH. While being able to hide DNS queries in a larger stream of HTTPS traffic may have legitimate benefits for an individual in a part of the world that does not enjoy the level of personal freedom that we have in North America, remember that this post is intentionally looking at things from an enterprise point of view. Corporate employees typically must (or should!) abide by an acceptable use policy that normally anticipates monitoring of all traffic and activities by the employee for company purposes.  Users in a corporate environment have no expectation of privacy when using company facilities.As such, I’m being pragmatic and leaving the human rights arguments out of this particular discussion.

In Conclusion

I’ve tried to lay out the basic differences between the two options for DNS encryption but, at the end of the day, you will have to decide which, if either of these, are appropriate for your environment. Remember that this is about keeping the information about the types of DNS queries being made private rather than ensuring the integrity of the responses to those queries, we already have DNSSEC for that.

We won’t give you a hard decision on which solution to use though you may sense our preference. In the end, we suspect that the major DNS service and technology providers will provide both options. Which one you choose for your enterprise, if any, will come down to making a decision about what is the best compromise between security, cost, and operational impact.

In keeping with the enterprise focus of this post, we will make a couple of suggestions for those of you who are technically inclined. First, take the time to read the RFCs. They aren’t particularly long (though a bit dry) and will give you a good sense of what each solution is about without the filter of second-hand interpretation (ours or anyone else’s!). Second and with an architectural bent, regardless of which channel you use for recursive DNS queries outside of your organization (unencrypted over port 53, DoH over port 443, or DoT over port 853), you should not be allowing your corporate users to directly access any external DNS resolvers, full stop. Resolution should take place through an internal network of resolvers that handle any recursive external query requirements through a small number of recursive servers. This minimizes your DNS attack surface for DNS linked exploits and allows for easier control of the types of locations your employees are accessing. 

It’s critical, when considering whether to implement the use of any technology in the enterprise to ask yourself “cui bono?” To whom goes the benefit? Clearly, in this case, Google perceives some significant business benefit to making DoH service available.  Does that benefit align with your goals for securing your enterprise and controlling your IP? 

As a final note, it may be reassuring to know that, at this point in time, although DoH services like the one offered by Google are available, the infrastructure to take advantage of them are generally not. To the best of my knowledge, none of the mainstream operating systems provide client-side support for DoH or DoT name resolution today. So you still have a bit of time to figure out which way makes the most sense for your organization.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.