Written by Peter Lowe in collaboration with Serena Raymond.
Last month, our CTO Mike Schroll wrote an article comparing DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). I won’t be rehashing that here. If you read that article, you’ll get the idea that at DNSFilter we generally prefer DoT.
But I do want to clarify a few things that came up when the article was shared on Hacker News in July.
DoH and DoT are nearly the same. The core differences between them are:
There was a great comment on the previous article by Mike that summed up the point he was making nicely: “The author didn’t refer to TLS, they referred to HTTPS which is HTTP+(TLS|SSL). The TLS part is common to both DNS-over-HTTPS and DNS-over-TLS. Browsers speak HTTP natively, but they don’t speak the DNS protocol.”
While Google could technically use DoT instead of DoH in its browser, DoH provides fewer barriers to entry. Browsers speak HTTP natively, so applying DoH encryption made sense for them purely from the standpoint that it was easier. To use DoT, browsers like Chrome and Mozilla would need to change the way their applications are built. Or, they’d need to add things to their application that would slow it down.
DoH is more privacy-oriented than it is security-oriented: All DoH traffic is hidden from the network administrator. What this means is when companies like Mozilla automatically enable DoH in their browser, it breaks filtering services. DNSFilter can no longer respond to DNS queries, so it can’t determine if a site should be blocked or not. It’s why we have documentation on preventing circumvention for DoH.
The decision to push DoH forward as a standard has large implications for system administrators and MSPs.
We’ve worked with Mozilla so that our product works in Firefox without end users having to turn off DoH. All of that happens automatically with our product without end users having to take action. And though we’re proponents of DoT at DNSFilter, we do plan on adding DoH support.
Now that I’ve sufficiently bored you by going over those details with a fine-tooth comb, let’s move onto what I really want to talk to you about.
I want to focus on the impact DoH has on MSPs. This is really important because no matter if you’re pro-DoH or pro-DoT, DoH is winning. It’s being implemented on operating systems and browsers, and it can impact the way filtering products (like DNSFilter) work within the browser as I mentioned in the above section you might have skimmed.
Before I start complaining about DoH on behalf of MSPs everywhere, I want to just say that DNS encryption of any sort is a move in the right direction! DNS is one of the few major protocols that is unencrypted, and that needs to change. Personally, I just don’t think DoH is the right choice.
The encryption scene is kind of the Wild West right now. There’s still a lot to be finalized with the DoH standard, and no one can seem to completely agree on what the right solution is. Granted, we’re contributing to that a bit by being contrary to the flood of DoH support. But we’re in favor of more standardization so this DNS mess feels a little less like a frontier town.
If you’re interested in learning more about DNS, this presentation by Paul Vixie is a must-watch. I’ll be referencing it a lot here.
Vixie states repeatedly in this presentation that DoH was born more out of a political motivation than a technical one. The decision was to have all DNS traffic hidden from the network administrators.
When you’re thinking about governments that use national blocklists to keep citizens from accessing certain sites, some people might think this is a good thing. DoH allows those end users to circumvent national block lists and access content. It also means the government has no insight into that person’s DNS traffic.
This seems great from a privacy perspective. But when you think about the political ramifications, this won’t necessarily be a win for private citizens. Governments that want to block content will do what they need to in order to block that content. And something like this may lead to some sort of registration requirements to access the internet in these areas—or it might even lead to certain browsers being blocked by countries.
DoH can even provide a false sense of security in these situations, because even though the DNS data is hidden, if you’re not using a VPN, the TCP data is readable. Here’s Paul Vixie explaining the details on that here.
MSPs with customers in these countries need to be especially wary of browsers implementing DoH by default, and operating systems too. Choosing DoT in these situations maintains network administrator control and means your customers won’t be negatively impacted by circumventing block lists their countries put in place.
Speaking of circumvention, it’s going to happen no matter where you live. We don’t want to circumvent encryption, we want to use it! But the way that DoH is implemented really requires network admins to go around it in order to keep their systems working.
Beyond that, individual users, like in the example above, will use DoH to go around DNS filtering policies.
DoH is seemingly great for privacy, but it opens up a lot of security concerns. While DoH protects users from man-in-the-middle attacks, it puts users at risk for malware, phishing, botnet, or ransomware attacks because their DNS queries are now unreadable and unblocked. Our marketing team has used this stat before, and for good reason: Forty percent of malicious URLs are on good sites!
Even if you’re security-conscious and go out of your way to not visit suspicious looking sites directly, sites you trust still pose a security risk. And if you think being cybersecurity aware means you don’t need protection, you’re wrong.
At the end of Vixie’s presentation around DoH, someone asked shouldn’t the corporations be outraged? After all, this implementation is going to break networks that rely on Active Directory implementations.
He’s right. It will break that. Part of the issue is that not many people understand the impact that DoH will have in these situations. Google and Mozilla, again as pointed out by Vixie, have done a lot of PR and marketing around DoH. They focus on the positives of the solution without delving into the concerns people have.
If you’re using local DNS resolvers, DoH will break these connections unless you go through serious retooling because the browser uses its own DoH resolvers.
But it’s not just software implementations that will break: Certain companies will break compliance if their users go around their filtering. This can cost huge sums of money for those companies and put workers at risk of losing their jobs.
The big thing is to stay informed. Know what these vendors are doing. Are they locking end users into DoH, or are they providing alternatives? A Google alert for DNS-over-HTTPS isn’t a bad idea. As an example, just recently Apple and Microsoft have announced they’re adding DoH support for their upcoming OS releases.
Every platform implements DoH differently, and it’s all subject to change based on the needs of those companies. So DoH is really a moving target, and you’ll need to understand the underlying architecture of your customers’ network more than ever before.
But also be prepared to spend more time making things work. Be prepared for things like Active Directory to break. It sounds like bracing for the worst, but as these implementations change it’ll become the reality for the MSP world.
The other thing you can do is be part of the solution. Educate yourself and support the encryption methods you like. Even after the DoT vs. DoH war is put to bed, that’s still not the final step in DNS encryption. Communication between DNS resolvers and authoritative DNS still needs to be encrypted in a way that won’t slow you down and won’t break anything. And that means there’s still work to be done.