DNS-over-TLS vs. DNS-over-HTTPS

DNS-over-TLS Vs. DNS-over-HTTPS

As the need for DNS encryption evolves, there seems to be a growing debate between DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH). With Google (and Firefox ) adopting DoH as their DNS encryption method for their browsers, there seems to be a belief that DoH is superior to DoT.

But that’s not the case.

The reality is that DNS-over-HTTPS and DNS-over-TLS are slightly different standards for implementing the same DNS protections.

Both prevent:

• Spoofing – Forged DNS requests, these usually come in the form of a man-in-the-middle attack where a malicious actor will temporarily redirect users to a fake login page to collect personal information or login credentials
• Tracking – When untrustworthy entities can view your DNS requests and collect information on you, this data can be sold to advertisers*

To simplify this further, the end goal of DNS encryption is to prevent DNS requests from being read and from being modified .

*Privacy policies are not just a box you need to check. They tell you exactly how a company will use your data. The absence of a privacy policy is a warning sign. We take privacy seriously at DNSFilter, you can check out our Privacy Policy and the security best practices we follow to keep our customers safe.

DoT and DoH aren’t implemented at the same layer

The main difference between DoT and DoH are the layers at which the encryption is enabled. DNS-over-HTTPS is applied at the application layer (two layers removed from the Internet layer) while DNS-over-TLS is applied at the transport layer (one layer removed from the Internet layer).

When it comes to implementing DoT or DoH, it really depends on what exactly you’re looking to encrypt and where .

Since Google and Firefox are browsers, they are already using HTTPS, so implementing DNS-over-HTTPS makes the most sense for them. DNS-over-HTTPS isn’t used by Firefox and Google because it’s superior to DoT. It’s used because browsers operate at the HTTPS layer by default, so DNS-over-TLS doesn’t make sense (as things stand now) for a browser to implement. 

Google can’t use DNS-over-TLS in their browser because they can’t modify the code on Windows or MacOS operating systems (which only support DoT at the moment)  in order to encrypt DNS requests done outside of the browser. And that works for Google and Firefox, because they only need to encrypt DNS requests inside of their browsers.

Meanwhile at DNSFilter, we need to operate DNS encryption not just in the browser, but at the operating system level. That’s why we use DNS-over-TLS: Because it can be enabled at a lower layer and protect DNS requests outside of the browser (e.g. Slack messages, links embedded in Excel, or miscellaneous desktop applications). And right now, DoT is the primary way to enable standardized DNS encryption at the operating system level. 

Note that DoH is being enabled at the OS level for new versions of iOS, MacOS, and Windows. Because Android is a Google product, and Google Chrome uses DoH, Android devices are already using DoH at the operating system level.

Which is better?

DoH is on everyone’s minds because it’s what Google uses, but it’s not necessarily better than DoT. It’s just different , and in some ways it’s actually inferior to DoT. 

In a lot of ways, DoT is more efficient because of which layer within the TCP/IP model it is enabled in. Remember, DoH is two layers removed from the internet layer while DoT is only one layer removed. 

Because there is another layer of encapsulation in DoH, it results in:

• More coding required
• More libraries required
• Packet sizes are larger than DoT
• Ever-so-slightly higher latency

These are a few of the reasons why DNSFilter chose DoT over DoH. Basically, we would have needed to send more data across another layer. Though it should be noted that both DoT and DoH increase latency, DoT has lower latency because of where it’s enabled.

But the most important reason for us, and our users, in choosing DoT was the ability to enable DNS encryption at the lowest possible layer since our users do not just send DNS requests over their browsers. That’s why we use DoT.

But that doesn’t mean we think DoT is the only answer. We are planning on having a DoH implementation for clients who need it.

As an example, Android devices, such as Chromebooks, use DoH. This is because Android devices were created by Google. While Windows and MacOS do not currently support DoH, Google was able to modify their Android devices so that DoH would be possible.

Microsoft has even announced adding support for DoH , while also keeping their DoT support. 

Though, just because Microsoft supports DoH for their operating system doesn’t mean the higher latency or additional coding requirements go away. No matter what, DoH is still implemented at a higher layer than DoT. The only change would be that now DoH can be implemented at the operating system level. 

This addition of DoH support is likely less about Microsoft giving their users more options and more about them following Google’s lead.

Other DNS protocol variations

DoH and DoT are not the only encryption protocols available, though at this point they are more robust and the most widely used. But before encryption standards were available, there was also DNSSEC.

DNSSEC was an early DNS standard that provided no encryption or privacy for your DNS requests. It only prevents man-in-the-middle attacks. And if it is not applied properly, it will break your website. You can check out a feed of websites broken by improper DNSSEC implementations here . 

DNSSEC is prone to frequent outages and it was never widely adopted. Due to that, and because it only does a portion of what DoH and DoT do, are just a few reasons that at DNSFilter we don’t recommend using DNSSEC, though we do support it.

DNSCrypt is another DNS encryption option, though far less popular than the two protocols we’re comparing right now. Like DNS-over-TLS, it is applied at the transport layer. DNSCrypt prevents localized man-in-the-middle attacks and encrypts DNS traffic between the user and recursive DNS servers, though it does not provide end-to-end encryption. 

But the biggest difference between DNSCrypt and other standards (like DoT) is that there is no RFC (Request for Comments) like there is for DoH or DoT. This means it hasn’t been peer-reviewed and battle-tested. Implementations can vary greatly, and all of the definitions and specifications for DNSCrypt come from a single source.

You can access the RFCs for DoT and DoH here.

DNS encryption is still evolving

There is no right answer when it comes to DoT or DoH, because these standards support varying use cases. But if DoH continues to be adopted like it has been, we might see DoT go by the wayside.

With that being said, it’s not just a matter of choosing DoT or DoH. There is still work that needs to be done in both DNS encryption and SNI (Server Name Indication) encryption.

SNI is the layer above TLS and an extension of the TLS layer. Once you make a DNS request and TLS makes a secure connection with that IP address, SNI tells the server in clear text (not encrypted) what the name of that domain is. While this does not impact things like man-in-the-middle attacks, it does impact privacy. Currently, SNI is not encrypted, though it is something that is being worked on.

While DoT and DoH are the most secure and standardized methods for encrypting DNS, they do not encrypt the request that goes to the authoritative DNS. That request is received in clear text. This is a point of vulnerability in both DoT and DoH, as well as DNSCrypt. Right now there is no standard for encrypting this information.

As a DNS resolver, we support and welcome a standard for encrypting messages to authoritative DNS, and we’d love to work with providers to help put this in place.

But the point I’m trying to make here is that neither DoT nor DoH are perfect DNS encryption solutions at this moment. More work still needs to be done, like enabling 0-RTT for all DNS-over-TLS and DNS-over-HTTPS implementations.

While everyone is talking about DoH, it’s not because it’s the most secure or most efficient solution. It’s because right now, it’s the solution that’s getting the most press. When VHS overtook Betamax , it wasn’t because VHS was better in every way. Betamax actually provided better video quality, but VHS was cheaper and allowed people to record longer programs. VHS and Betamax both achieve the same end (recording and displaying video), similar to how DoT and DoH both provide encryption through slightly different methods.

One of the biggest impacts of the “DoH vs. DoT” debate is the way MSPs implement network-level DNS filtering. With DoH becoming the de facto standard, it makes performing DoH bypasses on system-level DNS settings nearly impossible. There’s no standard method at this time for alternative workarounds. We’ll go into this subject in more detail in a later blog post, as there is a lot to consider when discussing the impact on MSPs.

For more reading on DNS-over-TLS and how it’s implemented by DNSFilter, visit our support documentation .