I've heard the argument against DNS-over-HTTPS that it is supposed to be a security nightmare for network defenders because it enables encrypted DNS over port 443, compared to DNS-over-TLS which goes through port 853.

I don't understand this argument because, how is malicious traffic on DoH practically more difficult to detect and block than, say, a VPN connection over port 443 or a proxy connection via HTTPS over port 443? If you're a network defender, and you allow third-party VPN and proxy connections in your network, why would DNS-over-HTTPS make your job any more difficult than it already is, and why would DNS-over-TLS be so much better?

  • 9
    You can find some explanation in the DOH criticism section on wikipedia. It's mostly about making traffic filtering/blocking that much more difficult. This is a particular problem for ISPs (or companies) that must or want to filter/block web traffic.
    – Marc
    Commented Aug 6, 2020 at 7:15
  • 7
    I think the main problem with DoH from the perspective of a defender is not data exfiltration but reduced visibility into DNS requests. This means that more invasive (and expensive) methods like Deep Packet Inspection or SSL Interception have to be used. Commented Aug 6, 2020 at 7:15
  • 1
    @SteffenUllrich That's assuming your main concern is visibility into DNS requests. But if your main concern is simply security of the network, then...? That's what my question is about. I know it makes it harder to monitor what websites/servers devices in your network are connecting to, but monitoring =/= security, and security seems unaffected to me. Commented Aug 6, 2020 at 7:51
  • 4
    @hilltothesouth: "... but monitoring =/= security, and security seems unaffected to me. " - There is lots of security building on the visibility of DNS, like blocking known malicious domains, restricting access to previously unvisited domains (like used in pishing) etc. Security solutions like Cisco Umbrella are build on DNS based monitoring and filtering since this is a comparable light weight and less intrusive method. Commented Aug 6, 2020 at 9:15
  • 1
    @hilltothesouth this question makes a lot more sense. Thanks for the edit.
    – schroeder
    Commented Aug 6, 2020 at 10:24

5 Answers 5


I've heard the argument against DNS-over-HTTPS that it is supposed to be a security nightmare for network defenders because it enables encrypted DNS over port 443, compared to DNS-over-TLS which goes through port 853.

These network defenders are possibly corporate environments that rely on plaintext DNS inspection to enforce policies. Assuming that devices fallback to plaintext DNS if DoH/DoT are unavailable, the network administrators could block port 853 with little risk because it is only used by DoT. On the other hand, if they simply block port 443, then all HTTPS websites will become unavailable.

Similarly, if they see an influx of DoT traffic, it could indicate an anomaly. If some similar traffic spikes occur with DoH, then it might not be possible to directly distinguish HTTPS from DoH traffic.

As for the question from the title:

Why is DNS-over-HTTPS such a big security nightmare compared to DNS-over-TLS?

This should probably be worded as "Why is DNS-over-HTTPS seen as a security nightmare compared to DNS-over-TLS?". DoH and DoT are pretty similar on a protocol level, in both cases DNS messages are encrypted. See also my Cloudflare blog post explaining DNS encryption where I describe the technical protocol details, deployment choices, and various expectations from individuals and organizations.

Historically, the operating system has been accepting whatever DNS resolver was advertised by the local network. This is typically configured by the corporate network administrator, or the ISP. They expect to have the ability to provide services such as malware blocking, parental filtering, blocking of illegal content, and in some cases query logging.

DoH and DoT are great in protecting the privacy and integrity of DNS queries in untrusted environments such as airport Wi-Fi or even snooping/interference from the local government. However since it was emerging technology, not all existing DNS resolvers have support for it.

That put early adopters such as Mozilla in a difficult position, should they abandon the idea of improving privacy, or should they select a DNS resolver who supports DoH with a strong privacy policy? They ended up with the latter, but that meant that the default DNS resolver provided by the operating system was initially ignored. This is probably the reason for the negative pushback against DoH from ISPs and governments. If DoT was deployed in a similar way, I would have expected a similar criticism.

To conclude, I don't think that DoH is such a "security nightmare" as claimed. It is just that some organizations are concerned about losing control over DNS. Previously it was centrally controlled by the operating system, but as DoH/DoT is still pretty new, there is no real standard on configuring it so many applications have their own mechanisms to do so. This is probably the "nightmare" that some admins have, the extra complexity that they have to go through to ensure that their filtering policies are applied.

  • 2
    "This is probably the reason for the negative pushback against DoH from ISPs and governments." The pushback is also from users that dislike any kind of software trying to pretend it knows better than the user and just ram it down its throat some decision (hardcoded DOH setting, that only slowly evolved to a selection among 2 and a selection process of other operators that just discards even DNSSEC compliance...). Other browsers made the more sensible approach of switching to DoH only if the configured nameserver is known to support it (with other problems then about discoverability) Commented Aug 7, 2020 at 22:09
  • "It is just that some organizations are concerned about losing control over DNS." The control is just moved from A to B, it still exists and for some it is even worse because A is decentralized (or can be, because the users chose) where B, at least in first invocation, is completely centralized, hidden from users, and difficult to change. Browsers started that trend, but other applications will do the same, which may yield to a split world view where, depending on the application, you reach completely different recursive nameservers, that could lead to completely different responses. Commented Aug 7, 2020 at 22:11
  • 2
    @PatrickMevzek I'll have to strongly disagree about "A is decentralized whereas B is completely centralized." If anything, now things are more decentralized than ever with applications being able to individually override the OS settings. Commented Aug 8, 2020 at 4:56
  • 3
    Pure facts though. PReviously: anyone could use any DNS and in practice often the ISP, so fully decentralized. When Firefox started to switch DOH, all requests where going to a single IP, which is what is known as centralized. The protocol itself does not change anything, any variant of DNS can be as centralized/decentralized as one wish. The problem is how DoH was introduced in browsers. As for "applications being able to individually override the OS settings. " I am not sure it is 100% benefit, it is a double edge sworded. But I guess it goes with the trend, like QUIC being in applications. Commented Aug 8, 2020 at 5:08
  • 1
    "But if you operate your own recursive resolver, you will actually make yourself more identifiable (less privacy)." Not true at all... The resolver can forward to any other one, and can also have smarter resolution by spreading the load among multiple other recursive nameservers. Just centralizing to one server is not an immediate 100% gain in privacy. It helps in a way, and creates problem in another. It is not by itself a foolproof way to regain privacy. Commented Aug 9, 2020 at 18:22

Again, it's all about the threat model!

Technologies are just technologies and can be used both for good and for evil. DNS over HTTPS (DoH) intends to solve the privacy concerns there are with unencrypted DNS, whereas DNSSEC can solve the integrity concerns without a need for encryption. Together with DNS over TLS (DoT) they are all fighting the threath of a malicious network operator that spies on your DNS traffic or forges responses.

On the other hand, both monitoring the DNS traffic and forging records can also be used for good intentions like detecting and blocking malicious traffic that is depending on DNS resolution. This is where solving these technical threats can actually decrease overall security, especially on corporate networks. The threat models of an organization are naturally different from the threat models of any individuals working for the organization.

Not so easy to detect

It's true that being unable to block DoH is rather irrelevant, if VPN connections are allowed. On corporate networks VPN connections (as well as DoH) can be either forbidden by policy (weak) or blocked by TLS inspection (efficient, but sometimes illegal or requires special privacy considerations).

Compared to DoH, DoT is easy to block, as it has a dedicated port 853 (tcp&udp) per RFC 7858.

For more detailed insights on the subject I'd recommend: Drew Hjelm: A New Needle and Haystack: Detecting DNS over HTTPS Usage (SANS Institute 2019). It also has some examples of the real security issues:

2.3. Public Threats from Encrypted DNS

Organizations need to start evaluating the risk associated with the DoH protocol because attackers have already begun using DoH to look up command-and-control (C2) servers. The best-known example of DoH as a C2 mechanism came in April 2019 with the Godlua backdoor (360 Netlab, 2019). A newer variant of the Godlua backdoor runs on Linux and Windows and uses a DoH request to grab a part of its C2 information.

Another way an attacker could use DoH in an attack is to trigger a redirected webpage as part of a spam campaign. Researchers at MyOnlineSecurity (2019) found a sample where an email attachment had a Base64 encoded string that would query Google DoH for a TXT record. The TXT record would have a JavaScript redirect to a spam webpage whose address often changed.

Numerous DoH C2 proofs-of-concept are publicly available, meaning that the threat of malicious actors using DoH is likely to increase soon.

  • 7
    Encrypting your data gives you privacy but the NSA hates it when they can't see your Facebook messages because that encryption is making them unable to snoop on the bad guys' (and your) data to "make everyone safer". Commented Aug 6, 2020 at 8:28
  • @esa-jokinen Thank you for linking the SANS Institute whitepaper. I haven't read through all of it yet, but even these researchers seem to wonder if, other than the different port which can easily be blocked, DoT is any more secure than DoH. The very next paragraph after the ones you shared states: "As of this writing, there was less risk posed by DoT as a malicious vector than DoH. First, information security news outlets have not widely reported the use of DoT-based malware using TCP port 853... Malicious activity using DoT may be a future risk, but the current threat is not high." Commented Aug 6, 2020 at 8:42
  • 16
    @JohnZhau: Or NSA loves it when HTTPS prevents other intelligence agencies from seeing the same messages they already have access to on Facebook's servers. ;) Commented Aug 6, 2020 at 9:04
  • @hilltothesouth: Yeah. Just couldn't cite the whole paper here. Commented Aug 6, 2020 at 9:06
  • 1
    "DoT is any more secure than DoH", HTTP brings its own set of vulnerabilities, fingerprinting (see tools.ietf.org/html/rfc8484#section-8.2), etc. So it is a compromise. In a purely hypothetical pure Internet without broken software or hardware around, DoT makes more sense as fewer layers. Until of course you switch to DNS messages being JSON encoded instead of "as on the wire of DNS/53", which brings you other benefits (or problems) in HTTP land that you won't have in DoT. Commented Aug 7, 2020 at 22:16

You're right that their argument makes no sense, but it's not supposed to. It's just supposed to derail DNS-over-HTTPS, which is the approach that is actually taking off because it's less likely to be blocked by existing middlebox junk. Assuming the queries are to well-known open public nameservers, it's equally easy to add new rules to block them regardless of which protocol is used, but the people who are fighting against DNS-over-HTTPS are fighting against the normalization of DNS queries being private; once that achieves critical mass as the default in browsers and client applications, blocking it will just break everything, making it practically unblockable.


A point that the other answers have only lightly touched on is that the user themselves might want to block certain DNS queries. For example, I use Pi-Hole on my home network to block DNS queries that are known to serve advertisements. Though outbound DNS queries are blocked, a device could potentially use DoH to circumvent that.

  • 3
    DoH really has nothing to do with whether you can block ads. If the app serving them does respect your DNS preferences, you can configure a DoH server that blocks ads, and if it doesn't, then it could just as easily hardcode the IP addresses instead of using DNS at all. Commented Aug 8, 2020 at 4:10
  • @JosephSible-ReinstateMonica, This answer is lacking detail. What I believe they're getting at is that blocking port 53 TCP/UDP on the perimeter forces one to use the internal DNS server. Since TCP443 is universally open, DoH can bypass this control.
    – phbits
    Commented Aug 8, 2020 at 16:02

Traditionally, blocking/allowing services has occurred at the Transport layer. DNS was confined to use port 53 on TCP/UDP. Web traffic would use TCP 80/443. So on and so forth. This makes network management easier since services are segregated via protocols and ports. DNS-over-TLS maintains this design principal since the service uses TCP port 853.

As an example, consider the common occurrence of forcing use of the internal DNS server. This can be achieved by implementing a router/firewall ACL like the following:

block drop all
pass in proto udp from to $internal_dns port 53
pass in proto tcp from to $internal_dns port 53
pass in proto tcp from to $internal_dns port 853

Now we have all sorts of traffic traversing TCP 443 whether it be an SSL VPN, web browsing, and now DNS-over-HTTPS (DoH) just to name a few. Blocking this traffic requires more sophisticated equipment as the traffic is encrypted via HTTPS and joins other HTTPS traffic on TCP port 443. The device must be able to identify DoH via an Application Layer signature which is only available on specialized equipment. Such equipment may not be affordable for smaller organizations or they may lack the bandwidth to manage it.

You can see how DNS-over-HTTPS is a much more difficult problem then to allow or block a protocol and port combination like DNS-over-TLS. It is a shift from traditional network design to one that requires more visibility into all the different encrypted traffic traversing TCP port 443.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .