What is the difference between DNS over TLS & DNS over HTTPS?
1 Star2 Stars3 Stars4 Stars5 Stars (9 votes, average: 4.00 out of 5)

What is the difference between DNS over TLS & DNS over HTTPS?

While they sound like the same thing, there’s one major difference and it’s causing a heated debate.

DNS over TLS (DoT) and DNS over HTTPS (DoH) sound like they would be interchangeable terms for the same thing. And they do actually accomplish the same thing – encrypting DNS requests – but there’s one big difference: the port they use.

And while it may seem silly for something that sounds so simple to have created two totally divided camps with deeply entrenched beliefs about which is better–the stakes are high. One side is more socially conscious, more user-oriented, their primary interest is privacy and human rights. On the other side is a more pragmatic group that even includes one of the architects of DNS, who make the case that network admins need to be able to see and analyze DNS activity.

There’s a lot to unpack here, but it’s worth delving into the details to give you a better idea about the difference between DNS over TLS & DNS over HTTPS—and why this is an important discussion.

So without first ado, let’s hash it out…

What is DNS? Why does it need TLS or HTTPS?

DNS over TLS vs DNS over HTTPS

DNS stands for Domain Name System. The best comparison, and also the most cliché, is that of a phone book. When most people surf the web, they don’t type in the actual IP address—they input the Uniform Resource Locator (URL). The DNS server takes that URL and finds the IP address it resolves to.

For instance, when you want to visit The SSL Store, you type in thesslstore.com, the DNS server will take that URL and find the IP address associated with it, in our case it’s But asking people to remember that would be pointless, hence the ubiquity of the URL (which Google is trying to kill).

If you ever want to find the IP address of a website you’re visiting, it’s easy on both Windows and Mac. Windows users simply need to type “cmd” into the search bar and open the Command Prompt, then type:

tracert anydomain.com
DNS over TLS vs DNS over HTTPS

It’s a little easier for Apple users, and a bit more elegant, too. In your Mac’s search bar, type “Network Utility” and click to open it. Then navigate to the Traceroute tab and enter the domain name in the trace field. Easy.

DNS over TLS vs DNS over HTTPS

Historically, DNS requests have been made using the UDP or TCP protocols—meaning that they’re sent in plaintext.

And as we’ll discuss, that can be a problem.

Why do we need to encrypt DNS requests?

If you’re living in the US, the UK or Australia, as the majority of our readers are, it’s easy to take for granted the rights and freedoms that we enjoy. In the greater scheme of things, our privacy concerns are pretty trivial. I found out last week that I was one of the lucky 50-million or so people that had their Facebook data compromised.

DNS over TLS vs DNS over HTTPS

And while that’s supremely annoying, it’s what we would mockingly refer to as a first-world problem. Though there are a few terrifying outliers, the worst that’s going to happen to most of us is identity theft. And that’s no laughing matter, but it’s also not a threat to your life or liberty. Outside of kiddie porn and snuff, there’s nothing you can’t access in the US, the UK and much of the western world.

That couldn’t be less true for other parts of the world. China has a notoriously restricted internet (one that Google is currently developing a clandestine censored search engine for).

Russia, North Korea, Iran, Saudi Arabia – just to name a few of the larger countries – are among dozens of nations that restrict their citizens’ use of the internet.

According to Freedom House, less than one quarter of the world’s internet users live in a country where the internet is designated as Free. That’s free in terms of rights and liberties–not price. 36% percent of internet users live in a country where the internet is fully restricted and another 28% live in a country where the internet is partially restricted.

Heck, a couple weeks ago the entire country of Ethiopia had its internet access turned off to try to quell what looked like, at the time, a potential military coup.

DNS over TLS vs DNS over HTTPS

And when your internet history can result in you being extra-judicially detained, or harmed or even killed—being able to obfuscate those DNS requests can be a matter of life or death. That may seem hyperbolic, but it doesn’t take a whole lot of research to turn up what can befall regular people who get labeled dissidents based on their internet usage.

That’s why, to some parties involved in this debate, this is a human rights issue—one that can stir up considerable emotion.

Nobody is arguing that DNS requests shouldn’t be encrypted, the argument is over how best to do it.

Ok, so what’s the difference between DNS over TLS & DNS over HTTPS?

While both of these standards encrypt DNS requests, there are some important differences between DNS over TLS vs DNS over HTTPS. The IETF has defined DNS over HTTPS as RFC 8484 and it’s defined DNS over TLS as RFC 7858 and RFC 8310.

DNS over TLS vs DNS over HTTPS

DNS over TLS uses TCP as the basic connection protocol and layers over TLS encryption and authentication. DNS over HTTPS uses HTTPS and HTTP/2 to make the connection.

This is an important distinction because it affects what port is used. DNS over TLS has its own port, Port 853. DNS over HTTPS uses Port 443, which is the standard port for HTTPS traffic.

While having a dedicated port sounds like it would be an advantage, in certain contexts it’s actually quite the opposite. While DNS over HTTPS requests can hide in the rest of the encrypted traffic, DNS over TLS requests all use a distinct port where anyone at the network level can easily see them and even block them.

Granted, the request itself – its content or response – is encrypted. So you wouldn’t know what was being requested, but they’d know you were using DNS over TLS. And at the very least that’s going to raise suspicions. It’s kind of like taking the fifth in the US. It just lends itself to the perception you have something to hide and in a lot of countries that’s not a good perception to have about you.

The case for DNS over TLS

Paul Vixie is one of the architects of DNS. And given the subject, his opinion bears considerable weight. Over the weekend he responded to Nick Sullivan, the head of crypto at Cloudflare’s Twitter announcement about RFC 8484 (DNS over HTTPS) by voicing his opposition:

RFC 8484 is a cluster duck for internet security. Sorry to rain on your parade. The inmates have taken over the asylum.

Personally, in the duck department I’m partial toward the Mallard, but, at any rate, Vixie’s opposition is made less from the perspective of a conscientious human rights activist and more from the standpoint of a seasoned security veteran. Those same human rights drawbacks, the ability to identify DoT requests – are also a boon to security.

It’s not unlike HTTPS inspection. On its face, the idea of interrupting an HTTPS connection sounds like a bad idea, and there’s certainly a segment of the infosec community that has a singular focus on security and argues that the practice weakens encryption. But there are also enterprise network admins and security officers that would be loathe to give up the ability to inspect their traffic. Losing that visibility is part of what led to the Equifax breach. Attackers love to hide in encrypted traffic, a point reiterated by the recent Magecart attacks.

DNS over TLS has more nuance, which is useful from a network health standpoint. DNS over HTTPS on the other hand…

DoH is an over the top bypass of enterprise and other private networks. But DNS is part of the control plane, and network operators must be able to monitor and filter it. Use DoT, never DoH,” tweeted Vixie.

Vixie argues that DNS over HTTPS removes a key distinguisher that assists in traffic inspection. It also makes blocking other websites more difficult because instead of just shutting off the DNS requests coming through a specific port you have to block all of the HTTPS traffic which can lead to all kinds of headaches.

That’s a good thing from a human right’s standpoint and bad thing from a network security one.

What’s the better standard, DNS over HTTPS or DNS over TLS?

That’s what all of this debate is trying to decide! There are legitimately valid arguments on both sides. What’s not helpful are ad-hominem attacks that distract from an otherwise worthy conversation.

DNS over TLS vs DNS over HTTPS

Given the fact this is a human rights issue emotions are bound to flare, but it’s important to remember the side advocating for DNS over TLS, which favors a network security approach but potentially opens up some privacy concerns don’t hold that position because they’re cold or lack empathy, they’re just viewing this from a different perspective.

Sometimes what’s best from a qualitative standpoint, and what’s best from a human rights or even a morality standpoint don’t align. To many in the DNS over TLS camp, this has nothing to do with real-world privacy issues and everything to do with the fact they see DNS over HTTPS as an inferior standard to DNS over TLS.

This isn’t about working in deference to a social conscience to them, it’s about designing a standard that is the most efficient.

Nobody is fighting against privacy, even if not everyone is fighting for the same thing.

We’ll keep updating you on this as more develops.

As always, leave any comments or questions below…

Certificate Management Checklist

Manage Digital Certificates like a Boss

14 Certificate Management Best Practices to keep your organization running, secure and fully-compliant.

Hashed Out by The SSL Store is the voice of record in the SSL/TLS industry.
  • Just heard Paul Vixie give a talk at the Wild West Hackin Fest in Deadwood, SD last Friday, he elaborated on some of these comments. Videos of the talk should be out soon.

  • The IETF has defined DNS over HTTPS as RFC 8484 and it’s defined HTTPS over TLS as RFC 7858 and RFC 8310.

    Seems there’s a typo. Did you mean DNS over TLS?

    • HTTPS over TLS makes no sense. In fact HTTPS is an applicative layer protocol that uses HTTP and add an encryption though the TLS (Transport Layer Seucrity) protocol. I might say something wrong but i’m pretty sure that the current HTTP/2 uses TLS 1.2 (most of the time) even though TLS 1.3 was released few months ago. So as you said it’s DNS over TLS or DNS over HTTPS.

  • The IETF has defined DNS over HTTPS as RFC 8484 and it’s defined HTTPS over TLS as RFC 7858 and RFC 8310. Seems there’s a typo. Did you mean DNS over TLS?

    Seems like a typo? WE ALL KNOW IT WAS. Annoying jackass.

  • VPNs are already here operating over 443, so it seems the cat is already out of the bag as far blocking DNS traffic or just monitoring DNS traffic on a statistical level. DoH is also already here – it seems customers and DNS providers want it, it is a de-facto standard.
    If a network manager wants to constrain untrusted users, they’ll have to work out something permitting a “trusted” man-in-the-middle to examine/record all 443 traffic.

  • Hi, Patrick, and thanks for the article. I especially appreciate the statement “What’s not helpful are ad-hominem attacks that distract from an otherwise worthy conversation.”

    If only people would actually learn this. Like Robert above attacking Riyan, who was very politely pointing out a typographical error. Kudos to Riyan, and the antithesis of kudos to Robert – I suppose some people never actually read the articles, only post in the comments.

    Going back to the article – I never once would have considered a human rights aspect to the argument at all, thanks for enlightening me to the fact that there actually does seem to be a legitimate reason for supporting DoH over DoT (one that I am having trouble getting behind as DoT just makes more sense, not to mention seems almost crucial from a network security perspective). Definitely some food for thought.

    • Of course, I’m mostly an end user, but it seems to me that at the very least, both camps should cooperate on meeting in the middle with a secure version to satisfy my right to privacy while giving me the freedom to legitimately surf wherever I wish, barring illegal activities.

    • Hi John L. Galt I see this issue akin to building a wall around the U.S. You might think you want it until the political regime you don’t agree with gains power and you are stuck in it. Just my opinion but Same with DoT. This would give network and security admins some power until the black hats interfere and by black hats I mean the STATE. With that said I see DoH as the only choice, but I can understand your opinion also.

  • I assume that when monitoring network traffic is concerned network administrators want to primarily see which destinations outside their domain of control are visited.
    As I understand from this article proponents of DoT argue that when somebody uses DoT this would raise suspicion which is a good indicator for further investigation. When that same person uses DoH this suspicion will not be raised (because it’s the same sort of traffic of visiting regular websites). So from a security (monitoring ‘healthy’ network traffic) standpoint it seems logical that DoT is preferred by people who want to be able to monitor network traffic. However when everybode uses DoT (because it has become a standard that every operating system implements) than it seems that the raising of suspicion argument in favour of DoT becomes moot and that it effectively no longer makes a difference if a user uses DoT or DOH. I want to stress out that I’m not a network (security) expert so please correct me if my analysis is incorrect

  • To even think up routing a basic protocol *over another* basic protocol… only the same batshit insane people who thought having an OS platform (HTML5) *on another* OS platform (your actual OS) was a goos idea, come up with something *that* insane!

    Even Xzibit would tell you to take it down a notch at that point!

    I wonder when JSLinux will become mandatory… browser in a browser included, … and they will route IP, nay, Ethernet over XML/JSON over HTTPS.
    OH WAIT! They already went full retard, err, WebSockets!

    I personally taked to the WhatWG leaders, have my background in neuro-psychology, and I hereby attest that these people need to be put in a mental asylum!
    The harm they do to society as a whole, is on a terrorist group level. A successful one.

  • Paul Vixie time is long over, for someone who created DNS that originally had zero security – why should his opinions carries any weight on the current highly evolved DNS?

    He only exposed his self interest and selfishness attacking DoH for making Sysadmins jobs tougher.

    And by calling everyone in the DoH camp, mad lunatics, he just threw away any credibility he had left.

  • I understand that DoT allows network admins to confirm traffic on port 853, but how is this useful in managing traffic when the DNS requests (and responses) are encrypted? Unless I’m missing something, you need to be able to see the DNS requests (and responses) to manage traffic to and from the IP addresses returned in the DNS responses. And since DoT encrypts the traffic, this isn’t possible. As an example, a network admin can’t block or reroute access to specific sites using information from DoT traffic (assuming the ubiquitous use of DoT) because the DNS information is encrypted; they can block DNS traffic universally on port 853, but wouldn’t this be almost as disruptive as blocking all traffic on 443, since DNS is needed in most cases?

    I’m not an advocate or opponent of either DoH or DoT; I just want to confirm that the arguments advocating for DoT are legitimate and in good faith. Assuming the use of DoT becomes ubiquitous, it seems to me that monitoring encrypted traffic on port 853 isn’t useful for traffic management or security research since the data can’t be read. Am I missing something here?

  • I really don’t see the problem or big deal here.

    DoH seems clearly best for “Internet” traffic, so governements can’t block or see your traffic…

    Or maybe they can anyway, because eventually ISPs will realize they can implement DoH themselves. After all they are both open standards and it is no good that only a few provide them.

    So basically, when DoH get obiquitous enough, as regular DNS is today, Google & Cloudflare will be pressured to use the default system DNS settings. Most home users will not touch that and will use their ISPs DoH servers, privided by their routers DHCP. So the ISPs will (or can) again learn what sites their users go to, just like today. And just like today, ISPs will be preasured by most governements (even many of the suposedly “freedom” respecting ones), to give up that info to them.

    China-like governments will probably block or prosecute users that don’t use their default ISP’s or whatever “sanctioned DoH prividers” they chose. So instead of the current Tor, users that care will need to have a local software in their browser or computer to use the regular ISP “sanctioned” DoH provider for the “approved” traffic, to pretend they are “obedient”, and for sensitive sites they will hit other DoH servers.

    It is better than currently requiring Tor and alikes for privacy, but still for most users governements will by default be able to “see” their traffic, the same way they do now, via the ISPs.

    On the other hand, DoT is clearly better for “company and VPN traffic” than DoH. So don’t use DoH inside your company, use DoT. I mean, why would you want to use DoH as a sysadmin over DoT?

    Basically to resolve any internal IP you need to use the company provided DoT servers. There are NO DoH server available to you to use. So you just use those.

    There is anyway now a push for zero trust security, moving away from VPNs and into all company services, even internal ones to be moved to publicly reachable HTTPS URLs. Those are authenticated sites that only properly identified users can access. In such a world DoT is not going to help as regular people can and probably will chose DoH, specially if they own and control their devices.

    That is another important point for company traffic and company infosec policies. You can’t trust a device of a non employee at all. You can trust to a certain level a device of an employee, as that person probably doesn’t want to lose the job. But if you really need to trust a device, then you need to provide the employee with a device owned and controlled by the company, any configuiration that is not allowed (like playing with DNS settings) can be locked down or used to lock out the employee access….
    … or again, you could just make sure your HTTPS services are properly protected and behind a proper Identity Provider (implemented by you preferably) with MFA and other countermeasures against identity theft, password loss or compromise, etc.

  • Brilliant explanation of technical subject matter! Thank you for demystifying the debate for me. I feel fortunate to live in a country where I’m able to choose between either standard and substantially accomplish the same objective.

  • You stated “DNS over TLS uses TCP as the basic connection protocol and layers over TLS encryption and authentication. DNS over HTTPS uses HTTPS and HTTP/2 to make the connection.” Don’t both of them use TCP for their layer 4 protocol and either HTTPS or DNS at the application layer?

  • The problem I have with either technologies is that I don’t trust the devices that live inside my house.
    Decent ones will allow for custom certificates to be uploaded in order to do MITM inspection by myself, but this does not appear to be an industry standard/practice, unless the EU would enforce it.
    Sure my concerns pale compared to what a lot of folk have to endure.

  • How about performance. Is one better than the other from a network speed perspective? I send the request and get the response back the fastest with least processing hit? I know it’s minimal, but that is what would choose it for me.

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *


Patrick Nohe

Patrick started his career as a beat reporter and columnist for the Miami Herald before moving into the cybersecurity industry a few years ago. Patrick covers encryption, hashing, browser UI/UX and general cyber security in a way that’s relatable for everyone.