DNS-over-HTTPS Is The Wrong Partial Solution

Openness has been one of the defining characteristics of the Internet for as long as it has existed, with much of the traffic today still passed without any form of encryption. Most requests for HTML pages and associated content are in plain text, and the responses are returned in the same way, even though HTTPS has been around since 1994.

But sometimes there’s a need for security and/or privacy. While the encryption of internet traffic has become more widespread for online banking, shopping, the privacy-preserving aspect of many internet protocols hasn’t kept pace. In particular, when you look up a website’s IP address by hostname, the DNS request is almost always transmitted in plain text, allowing all the computers and ISPs along the way to determine what website you were browsing, even if you use HTTPS once the connection is made.

The idea of also encrypting DNS requests isn’t exactly new, with the first attempts starting in the early 2000s, in the form of DNSCrypt, DNS over TLS (DoT), and others. Mozilla, Google, and a few other large internet companies are pushing a new method to encrypt DNS requests: DNS over HTTPS (DoH).

DoH not only encrypts the DNS request, but it also serves it to a “normal” web server rather than a DNS server, making the DNS request traffic essentially indistinguishable from normal HTTPS. This is a double-edged sword. While it protects the DNS request itself, just as DNSCrypt or DoT do, it also makes it impossible for the folks in charge of security at large firms to monitor DNS spoofing and it moves the responsibility for a critical networking function from the operating system into an application. It also doesn’t do anything to hide the IP address of the website that you just looked up — you still go to visit it, after all.

And in comparison to DoT, DoH centralizes information about your browsing in a few companies: at the moment Cloudflare, who says they will throw your data away within 24 hours, and Google, who seems intent on retaining and monetizing every detail about everything you’ve ever thought about doing.

DNS and privacy are important topics, so we’re going to dig into the details here.

Name Servers and Trust

The concept of the Domain Name System dates all the way back to its ARPANET days, when a single text file on each ARPANET node – called HOSTS.TXT  – contained the mapping of system names on the ARPANET to their numeric addresses. When you wrote this file yourself, it was easy to be sure it was correct. As the network grew, it became unrealistic to maintain both the central and local copies of this file. By the early 1980s efforts were underway to create a system to automate this process.

The first DNS name server (Berkeley Internet Name Domain Server, or BIND) was written in 1984 by a group of UC Berkeley students, based on RFC 882 and RFC 883. By 1987 the DNS standard had been revised a number of times, resulting in RFC 1034 and RFC 1035, which have largely remained unchanged since then.

The essential structure of DNS is that of a tree-like configuration, with its nodes and leaves subdivided into zones. The DNS root zone is the top-level zone, which consists out of thirteen root server clusters, which form the authoritative DNS root servers. Any newly set up DNS server (e.g. at an ISP or at a company) will end up getting its DNS records from at least one of those servers.

Each further DNS zone adds a further domain to the name system. Each country tends to manage its own domains, with special domains (like .org, .com) which aren’t bound to any specific country managed by a separate entity. When resolving a domain name using DNS, this means starting with the domain name (e.g. .com), then the name (e.g. ‘google’) and finally any sub-domains. This can involve a few trips through DNS zones if the requested data has not been cached already.

DNSSEC: Adding Trust to DNS

Before we get around to encrypting DNS requests, it’s important to be sure that the DNS server we’re talking to can be trusted. The need for this became clear during the 1990s, culminating into the first workable DNS Security Extensions (DNSSEC) standard (RFC 2353) and the revised RFC 4033 (DNSSEC-bis).

A map of the internet in 2006. (Opte project, CC BY 2.5)

DNSSEC works by signing the DNS lookup records with public-key cryptography. The authenticity of a DNS record can thus be verified by the public keys for the DNS root zone, which is the trusted third party in this scenario. Domain owners generate their own keys, which are signed by the zone operator and added to the DNS.

While DNSSEC allows one to be relatively certain that the responses one gets from the DNS resolver is genuine, it does require DNSSEC to be enabled in one’s OS. Unfortunately few OSes implement a DNS service that is more than just ‘DNSSEC-aware’, meaning that they do not actually validate the DNS responses. This means that today one cannot be sure that the DNS responses one receives are genuine.

The Problems with DoH

But let’s imagine that you are using DNSSEC. You’re now ready to encrypt the communication to add a level of privacy to the transaction. There are a number of motivations for keeping one’s DNS queries secret from prying eyes. The more innocent reasons include dodging corporate and ISP filters, preventing tracking of one’s internet habits and so on. More serious motivations include avoiding political persecution for expressing one’s views on the internet. Naturally, encrypting one’s DNS queries prevents people from snooping on those queries, but this ignores most larger security issues with DNS and of course every other communication protocol.

Here, the main contenders are DoT, using TLS, and the proposed DoH, using HTTPS. The most obvious difference between the two is the port they run on: DoT has a dedicated port, TCP 853, whereas DoH mixes in with other HTTPS traffic on port 443. This has the questionable benefit of DNS queries not being distinguishable at all, meaning that it removes options for network operators (private and corporate) to secure their own network, as one of the architects behind DNS, Paul Vixie, pointed out on Twitter last year.

The second main difference is that whereas DoT simply sends DNS queries over a TLS connection, DoH is essentially DNS-over-HTTP-over-TLS, resulting in its own mime Media Type of application/dns-message and significant added complexity. By mixing DoH in with existing protocols, it means that every DNS request and response goes through an HTTPS stack. For embedded applications this is a nightmare scenario, but it is also incompatible with nearly every piece of existing security hardware out there.

DoT has the other advantage that it’s already implemented and has been in use for far longer than DoH, with many parties, including Cloudflare, Google, some national ISPs and standard DNS server software like BIND supporting DoT out of the box. On Android Pie (version 9, for those keeping track) and later, DNS over TLS will be used by default if the selected DNS resolver supports DoT.

Why switch up to DoH just as DoT is finally gaining traction? By having rogue apps like Firefox circumvent the system’s DoT-based DNS and use its own DNS resolver over DoH instead, this makes for a highly opaque security situation. That DNS resolving would move into individual applications, as we see happening now, seems like a massive step backwards. Do you know which DNS resolver each application uses? If it mixes in with TCP port 443 traffic, how would you even know?

Encryption Doesn’t Stop Tracking

Two big parties behind DNS over HTTPS are Cloudflare and Mozilla, the latter of which has produced this cutesy little cartoon in which they try to explain DoH. Not unsurprisingly, in it they completely omit to mention DNSSEC (despite it being referenced as ‘crucial’ in RFC 8484), instead proposing something called Trusted Recursive Resolver (TRR), which seems to basically mean ‘use a trustworthy DNS resolver’, which for Mozilla means ‘Cloudflare’.

Unrelated to DoH, they mention a standard called ‘QNAME minimization’ (RFC 7816) which aims to reduce the amount of non-critical information the DNS resolver sends along to DNS, as covered by this Verisign blog article. As said, this standard has no bearing on DoH and would even work fine without any DNS encryption. Like DNSSEC it’s a further evolution of the DNS standard that improves its security and privacy aspects.

The kicker is in the ‘What isn’t fixed by TRR with DoH?’ section, however. As pointed out by experts on many occasions, encrypting DNS doesn’t prevent tracking. Any subsequent requests to the IP address that one so secretly resolved would still be visible clear as day. Everybody will still know that you’re visiting Facebook.com, or that risky dissident website. No amount of DNS and internet traffic encryption will hide information that is crucial to the functioning of a network like the internet.

The Future Internet is a Single Point of Failure?

Mozilla’s answer to the IP tracking problem is to essentially say that there is no problem, because of the Cloud. As more and more websites and content distribution networks (CDNs) get lumped onto a handful of services (Cloudflare, Azure, AWS, etc.), the meaning of that single IP becomes less and less meaningful, you just have to trust whichever Cloud service you pick to not steal your data, or go down for a day.

This year, there was a massive downtime event on June 24, when a configuration mistake at Verizon led to Cloudflare , Amazon, Linode and many others being unavailable for much of the day. Then on July 2nd of this year Cloudflare as a whole went down for about half an hour, taking down with it many websites that rely on its services.

Coincidentally Microsoft’s Cloud-hosted Office365 also had a multi-hour outage that same day, leaving many of its users stranded and unable to use the service. Meanwhile, on US Labor Day weekend, a power outage over at AWS’ US-East-1 data center led to 1 TB of customer data vanishing as the hardware it was stored on went FUBAR. Clearly there are some issues to be ironed out with this ‘centralizing the internet is good’ message.

What’s Old is New Again

It’s in many ways astounding that in this whole discussion about privacy and tracking there’s no mention of Virtual Private Networks (VPN). These solve the issues of encrypting your data and DNS queries, of hiding your IP address and so much more by simply moving the point where your PC or other internet-enabled device ‘exists’ on the internet. VPNs have been very commonly used by dissidents in authoritarian regimes for decades to get around internet censorship and along with specialized forms such as the Tor network are a crucial element in online freedom.

If one can trust a big commercial entity like Cloudflare in a scheme like DoH, then finding a trustworthy VPN provider who’ll not store or sell your data should be just as easy. Even better, the Opera browser comes with a free, built-in proxy that offers many benefits of VPN.

In summary, one can state that DoH honors its acronym by poorly doing what DoT already does. More focus should be on getting DNSSEC fully implemented everywhere along with DoT and QNAME minimization. And if true privacy by dodging tracking is your goal, then you should be looking at VPNs, especially if you’re a dissident trapped in some authoritarian regime.

51 thoughts on “DNS-over-HTTPS Is The Wrong Partial Solution

    1. How so? I mean, users can select any DNS provider they want. Normally, without user interaction it will default to your ISP. Personally, I trust Google more than I trust Comcast. I have control over where my DNS requests go, and I choose Cloudflare (but would be OK with anyone that wasn’t Comcast). How is this taking away control?

      1. One difference is that Google’s not just letting you connect your PC to 8.8.8.8 for free over DoH instead of UDP53, they’re letting your Google Chrome browser connect to Google’s DNS servers instead of to whatever your PC is using. Will you (as a Chrome user) have a choice about that?

        A dumb question I have about it is whether you’ll be able to connect to a non-public DNS. Where I work, and at most companies whose infrastructure I’ve seen, there’s a public-facing DNS for example.com and http://www.example.com, but there are also internal-only DNS names like http://www.internal.example.com for reaching internal-only websites. Google’s 8.8.8.8 and Cloudflare’s 1.1.1.1 aren’t going to be able to resolve those, and in many cases the IP addresses are also RFC1918.

        There are starting to be a number of DNS-based malware protection services. Cisco’s OpenDNS, and some of the other big DNS providers, will respond to queries for some-malware-site.com with error messages, and to queries for sometimes-unsafe-site.com with their own web server’s IP, which will then look at the full URL and decide if it’s known bad or known good, and then sometimes for unknowns it’ll proxy the request and look for malware before sending it to you, and optionally maybe do other filtering for spam sites or whatever. DoH interferes with these too, unless you’re configured to send the DoH query to them.

    2. It is time to move on. Human interaction needs words. Eventually the browser (An Application), will either have to encrypt ANY requests, or give your data to the DNS moguls. Time to have a browser encrypt traffic. Wait, better yet, TOR.

      Thoughts ?

  1. > Most requests for HTML pages and associated content are in plain text

    Really? I’m very surprised when I come across a plaintext site these days. In no part thanks to services like LetsEncrypt.

    1. https://www.cbronline.com/news/internet-encryption-sandvine

      “The report also found that video now accounts for 58 percent of “downstream” (consumer-side) internet traffic, with Netflix alone accounting for 15 percent of global internet bandwidth use. (We won’t speculate what the rest is).”

      But IMHO, if you have someone gulp down a gig of data watching one movie and someone else gulping down 50 megs of data by going to 500 different web-pages on 10 different servers, the person going to the different web-pages is generating QUITE a bit more trackable data even though the percentage of bandwtdth is much lower.

  2. First of all, DoH is a protocol, its not some DNS-hosting provider.
    Anyone can run a DoH server and it will work, what you’re talking about here is DNS over Cloud.

    “And in comparison to DoT, DoH centralizes information about your browsing in a few companies:” thats just wrong, your local ISP can just like CF run their own DoH server and your OS resolver can also just use DoH.

    I don’t understand why people fight for the right to access users DNS traffic, did you complain as much when we added TLS to most webpages?

    Doing filtering in DNS is just fake security, if you want proper filter then you have to force your users to install a custom CA and inspect ALL encrypted traffic (And then DoH is not a problem anymore)

    I do understand that people don’t like that individual applications do DNS them self as it might leak info and I understand that you don’t trust a US company, it might also cause problems for split horizon but then again, should we just sit and wait until our operating systems implement something more sane or should we just act now and hopefully solve some problems?

    And as you write, DNSSEC doesn’t solve any of this at all, almost no stub-resolvers do dnssec validations and those who do usually break hard when people abuse DNS for captive portals.

    1. I work for a CDN. DoH is breaking all sorts of things that we use to determine what server/POP we serve from, because we don’t get the EDNS Client Subnet, unless we also happen to support DoH and other restrictions by an outside party. Never mind that the main proponent that is pushing this is CloudFlare, a CDN we compete with. Why should we be held hostage by them? They get the data (where the client is) and we don’t. Advantage CloudFlare.

      From a CDN of view, this is going to give you a less than favorable experience.

      1. Old comment but non the less…
        Using old and problematic tech cause issues. ECS was never made proper. The ratified RFC 7871 carries this comment in the Abstract: “…it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.”, and the blatant problems in it show that and to add, ECS is a major privacy issue. Do you think Netflix uses ECS to manage where clients connect to? ECS is and always was the wrong solution to the problem, it destroys DNS resolver caches and makes offline DNSSEC signing impossible to implement.

        You don’t have to use DoH with Cloudflare, there are other providers to use instead.

      1. You make an index to the full file.
        Split the file into chunks and add a timer onto each chunk. Every time it changes you reset the timer. So all you send upon a request is the list of timers. Within that block is another subgroup of timers. So it’s a bit like a gps reference. Then you refresh the minimum block size to resolve your url. You get a window of related urls around your current query and that speeds up the next search.

      1. There are ludicrously few applications where blockchain might actually be good, and no end to the number of applications where idiots suggest it’s better than existing solutions.

        This is DEFINITELY not one of those situations where blockchain would be useful. We are not replacing DNS lookups with a blockchain. Just no.

  3. I feel like the thrust of this article is two-fold:

    1) DNS over HTTPS doesn’t prevent a MitM from seeing which host IP you are talking to
    2) DNS over HTTPS makes it hard for network operators to inspect your traffic

    Without TOR, you’re not going to solve problem 1. This is a security layer, not the complete solution. Number 2 I couldn’t give a whit about. If someone wants to see my packets, they can ask me and I can decide if I want to let them. Corporate network admins, local ISPs, and backbone providers have gotten used to being able to see everything I do, but that’s not because I wanted it that way. They’ll be just fine without deep packet inspection, unless they’re trying to do things I _don’t_ want them to do, in which case I’m not going to be sad on their account.

  4. Google’s implementation uses your system configured dns provider, but uses that provider’s DoH if it is available. This is an important difference compared to Firefox, which bizarrely ignores your configured DNS.

    I do wonder if there are a bunch of unintended consequences for the browser doing its own DNS lookups, rather than using the OS for DNS. Blocking known malicious domains, for example, would be difficult.

    1. DoH fails if the OS DNS system includes domains that do not exist in the public DNS records. For example, I can’t make print.foo.lan point at my 10.0.1.5 printer using public DNS records and certificates. So the maintenance page of that printer will be only work in firefox if I type the IP-address. If I have multiple internal websites that use virtual hosting on the same IP-address, typing the IP-address is not going to work at all.

  5. DNSSEC is a great technology but its much more complicated to administer a DNSSEC resolver than a DoH resolver — and DNSSEC is not implemented end-to-end down to client resolvers such as Windows, MacOS, etc. Even if it were; this is a case of systems not providing adequate security for decades and browsers finally starting to do a good job routing around the deficiency, which is a great thing.

    “Encryption doesn’t stop tracking” suggested by the experts is ONLY partially true. Many websites are now use CDNs with shared IP addresses for many websites such as AWS ELB, Cloudflare. TLS Version 3 introduce SNI encryption. It will no longer be reliable for an adversary to reliably track your traffic; even if they happen to know you are visiting a Cloudflare, Google or Facebook IP — they will have no idea to be sure what internet domain name you may be accessing.

    Its arguably not a “single point of failure”, because DoH implementations may fall back to other options if the central DNS server IP addresses are not working; a technology called Anycast is widely used on the internet to bind a single IP address to many sites and servers — Routing issues from a major provider such as Verizon are STILL a possible single point of failure before the internet yesterday, last year, and long before DoH was a thing.

  6. Encrypting internet traffic, and stopping internet tracking is both easy and hard.

    The simplest solution is to use a trusted third party that you don’t “care” if they track you. Then have an encrypted connection to this third party, then they connect you to the server of interest. Downside, this is a point of failure.

    If I were to design a new system, then I would likely use a chain of trusted third parties.
    Then rely on two chains to get me from point A to B. Where non of these trusted third parties knows the full picture.

    Lets say that we contact the 1st and 2nd trusted third party.
    We have now have an encrypted connection to these two. This our ISP knows. But the 1st third party doesn’t know anything about who the 2nd one is. And vice versa.

    We inform the 1st to contact our 3rd. We know who the 3rd is, and the 1st knows this too. But our ISP doesn’t.

    We then ask our 2nd to contact our 3rd, where we can exchange encrypted credentials that states to this 3rd that we are talking to them through 1 and 2. These credentials are randomly generated by the 3rd and sent to us through the 1st and we pass it back through our 2nd, proving that we make a full circle. Meaning that we can now exchange a secure communication channel that the 1st and 2nd ones have no method of breaking. Since data sent through the 1st the 2nd one doesn’t know of, and vice versa.

    Also we can use the same method to establish a 4th trusted third party.

    Our 3rd and 4th can then talk to the website we wish to access. And prove to the website that we talk to them through two trusted third parties, ensuring that the website as well doesn’t know where we are. We can use the same method as we did to connect to our 3rd and 4th trusted third party.

    This means that the:
    ISP only knows who our 1st and 2nd third party is.
    1st and 2nd third party knows who our 3rd and 4th is.
    Our 3rd and 4th doesn’t know who we are. We never told them.
    And we can establish an encrypted connection to the website. (through OTP we can ensure that our 1st, 2nd, 3rd, 4th third part nor our ISP knows what data we are sending.)

    Downside, setting up this mess every time you desire to access something is a bit of an annoyance. Though, one can build and expand this mesh network of trusted third parties at infinitude….

    And yes, the DNS request is done by one of these third parties. (preferably the 3rd or 4th that doesn’t know who you are, but will know what website you are going to in the end. (unless you add in a 5th and 6th trusted third party….))

      1. Then one would need to generate a lot of unwarranted traffic.
        Secondly also generate sufficient amounts of data for each one of these “false” visits.

        Thirdly, one hasn’t really done anything to stop anyone from seeing where one goes.

        And lastly one probably doesn’t want one’s noisy and sporadic visits to go to highly untrustworthy sites.

        In the end, generating noisy traffic is likely a fairly poor solution. Since these “false” visits wouldn’t be hard to distinguish from actual traffic. Not to mention that it would eat up a sizable portion of one’s data plan and/or bandwidth for it to be even remotely effective.

  7. There’s a typo..

    “DoH not only encrypts the DNS request, but it also serves it to a “normal” web server rather than a DNS server, making the DNS request traffic essentially indistinguishable from normal HTTPS”

    Surely that should be “also serves it from a “normal” web server”.

  8. The argument about network operators and security monitoring here is a carefully misrepresented way of saying that the author wants to be able to read and modify your DNS lookups. Any further argument they make about the “right” way to encrypt DNS can be disregarded as concern trolling: they don’t want it to happen at all.

    1. No, my concern is with being unable to track traffic on my own home network from the apps that are running on my own systems. To me that’s a crucial thing to have and losing it reduces my own security. Having this option taken away from me with DoH is unacceptable and means that I’ll never use it.

      1. How does DOH take it away in a way that DoT does not?

        1/ As the article points out, tracking is still possible by looking at the actual traffic. So there’s no case that this makes it impossible to track, especially on the scale of a small household network.

        2/ DOT would also prevent you from directly reading the DNS traffic, as will any other encrypted DNS scheme– that’s the goal. So you’re fundamentally not arguing that DoH is bad, you’re arguing that encrypting DNS is bad.

        To be blunt, I’ve never seen an environment where I thought the ability to inspect DNS provided more actionable security capability to a defender than the ability to manipulate DNS results provided to the attacker. It certainly does not in a small home network environment where full netflow data could reasonably be gathered, stored, and analyzed.

        1. You’re missing the point. This isn’t about whether the DNS traffic is encrypted. That’s not the point of those network administrators DoH fans seem to be so fun of harassing either. The point is being able to see DNS traffic on the network and being able to pinpoint where it originates.

          As with DoH everything is just HTTPS (TCP 443) traffic, this isn’t possible and any number of malware apps could be doing their own thing via this channel, without you ever becoming aware of it.

          If I could block DoH on my network, I would. But the security fail of DoH is that it is self-defeating when it comes to the security of one’s own network.

          This even on top of the idiocy of adding an entire HTTP stack & server to anything that wants to use DoH, which means even more poorly validated and unpatched code out there for every single network-enabled Arduino project out there.

          1. I’m super confused and I don’t think it’s my fault.

            The goal of network operators inspecting DNS is not to pinpoint the origin of DNS traffic. I know; I’ve been one and have sold security-as-a-service to them. They want to identify abuse of service, block illegal content, satisfy lawful intercept, and observe malware– in that order. And if the legal environment lets them, monetize. So, not sure where you’re getting that.

            Not only that, but since literally all properly terminated TLS sessions other than those for DoH and DoT are use a domain name for a CN/altname, if you see a TLS connection on your network it was preceded by a DNS request. So if you have the ability to identify the origin of a TLS request (and if you don’t I’m even more confused), you have identified the origin of a DNS request. So your goal would be trivially met that way as well.

            There is also no case that this represents new capability for malware. Malware authors have been doing at least this much and often much more to conceal C2 for years– they just had to roll their own or buy it.

            Your final point is just super weird to me. Like, nobody is putting a gun to anyone’s head and making them build products with DoH. They’re not turning off plaintext DNS any time soon. So, don’t like it? Don’t ship it. Just know that you’d better have a correct, validating TLS stack on there anyway because you have no idea who you’re talking to once you get that possibly-tampered-with plaintext DNS response.

      2. You may want to do that, but realize that being able to do that at all is only a side effect of there being a privacy leak in the system in the first place. It’s also not a comprehensive solution either because there’s nothing stopping misbehaving devices or applications communicating directly with an IP.

    1. People should run recursive resolvers on the same network or in the immediate vicinity of the network. If we don’t trust an ISP’s DNS server (I certainly don’t), then we wouldn’t talk over their connection to the DNS server.

      That DNSSEC doesn’t protect last-mile DNS is not really the issue.

  9. One thing that basically everyone I see talking about the DoH/DoT/etc. battle is missing is that all modern browsers will include a Server Name Indicator(SNI) in the TLS negotiation that gives the full DNS name in the clear for monitoring. There is an ESNI out but it’s not widely adopted, except by Firefox as far as I can see (¯\_(ツ)_/¯). So if an ISP really wanted to still monitor where traffic is going they’d just need to spend a bit more and do an inspection on the first couple of packets for a HTTPS session and still get the same data.

    I agree with many other that DoH is not a great idea. I can work with DoT as I can block outbound on my network and force resolution through my own DNS servers, I would not want my apps to be able to easily bypass my pihole for resolving those tracking IPs :).

  10. “And if true privacy by dodging tracking is your goal, then you should be looking at VPNs, especially if you’re a dissident trapped in some authoritarian regime.”

    Or viewing Netflix overseas.

  11. I wish someone would inform Cloudflare that (by default) blocking scripts and cookies doesn’t make you a bot.
    Just getting a bit tiresome hitting that F###ing “just a moment” screen lately.

    Thinking it might be time to change my screen name. Adobe/Cloudflare hater ?

  12. an IP address doesn’t necessarily map to a single site, so knowing what IP address you establish a HTTPS session to proves nothing.

    Many government initiated blocks to a website by IP address have taken down hundreds if not thousands of legitimate web sites in the past.

  13. Again, let’s put the corporate greed above the privacy! I have implemented DoH on my home router in a flash; as easy as installing any other Linux apps and in fact have written firewall rules to rull any DNS leak out of my network as well. Not a single query leaves my network unencrypted! Whether you like it or not, DoH will come and anonymised DNS would follow as well which I and likes of myself looking forward to it. In corporate environments, they spoof all the HTTPS traffic anyway as they deploy their own certificates issued by their internal CA. So, not sure what you are worried about!? DoH is the future and anyone caring for their privacy over corporate inconvenience should push for it. Thanks Firefox and Cloudflare for standing by the right side. Everyone caring for their privacy in the absence of net neutrality in particular, should rush to implement DoH or other types of encrypted DNS in their apps and network infrastructure. An the more undetectable, the more indistinguishable and the more anonymised, the better. Good article but the conclusion fall in the evil side of course.

  14. For all of those people who are still not looking at the big picture, consider this: DoH makes it damned near impossible to know what’s going on IN YOUR OWN NETWORK. Can we block ads via PiHole or something similar if browsers can use a DoH resolver? Can we implement our own tracking of what our devices query? No. This means that Trojans can have much more robust ways of finding their CaC servers. Spyware can’t be tracked as easily. There are lots of places where this is going to cause nothing but problems, ostensibly for the ever slight “benefit” of protecting us from our ISPs who can already see where we’re connecting.

    Plainly and simply, this is yet another move towards, “Take our shit (Alexa, Chrome, Ring, Android, Firefox, whatever) and deal with the fact that you have no insight in to what they’re doing, and we like and want it this way. You are no longer in control. Get used to it.”

    Anyone who is concerned with ISPs snooping can trivially run their own recursive resolver that directly queries the root level servers using DNSSEC. Get a Pi. Get a NAT router that allows you to run an open source resolver. Run a VM. Run it locally on your own machine.

    DoH is an assertion that people can’t take care of ourselves, and we should just blindly trust Google and Cloudflare. I’d love them to tell us why, with their absolutely horrible track records, we should trust them any more than we’d trust our ISPs. Or, better yet, why trust them more than we trust ourselves.

    They just want $$$.

    1. Lease a VPS and pay by crypto and setup your own DoH server if you don’t trust Cloudflare (no one should trust Google though) or use anonymised DNS which is a new initiative by DNSCrypt 2.0 and block all the public DoH and DoT servers in your firewall so your apps will be forced to fall back to your Pi-Hole. Your argument is void because one can use a knife to kill people or peel fruits. We cannot stop selling knives because some people may use them as weapons. Those trojans, malwares, etc can also use the unencrypted DNS on a port different than 53 and you still won’t notice a thing. It’s a pity that in 2019 we are still favoring unencrypted over encrypted regardless of what it is and what purpose it serves. As mentioned in the comments over and over again, it is also no concern to corporate environments as they already spoof all https traffic anyway by having root certificates issued by their internal CA deployed on their employees machines. So, DoH or DoT is yet another TLS encrypted protocol that will be bumped this way.

      Apart from preventing prying eyes on your dns queries, the advantage of using a trusted encrypted dns is to avoid being tracked by looking at your browsing habits which can be used in ads campaigns by giants like Amazon or the big brother of all, Google. So, don’t be surprised if you routinely receive catalogs of sex toys in the mail because you browsed an adult shop website last Saturday! Net Neutrality is dead and every bit of your information if can be used for monitisation, will indeed be used for sure. So, protect your info as much as you can or be haunted by every small and big business out there.

      1. I think the scenario in question here starts with barely-trusted “IOT” devices. Today you can examine their DNS traffic to see who they are connecting to. Tomorrow they’ll be making HTTPS connections that are not preceded by DNS queries.

        If the target IP address is a big cloud provider, you can only wonder whether it’s phoning home to do its job, or connecting to a malicious command/control server.

        Also, I clicked the ‘report’ button on your comment by mistake. Sorry about that.

  15. Zerotier using default routes to a gateway in Romania, a bind9 dns forwarder in Amsterdam, and browser virtualization with x2go is a good way to get around state actor monitoring platforms. Or… yeh know, just use the coffee shop WAN. Oh, and TOR is owned by the US DOD, so good luck with that *roll eyes*

  16. “Here, the main contenders are DoT, using TLS, and the proposed DoH, using HTTPS. The most obvious difference between the two is the port they run on: DoT has a dedicated port, TCP 853, whereas DoH mixes in with other HTTPS traffic on port 443.”

    ….

  17. DoH seems to add a lot of complexity over plain-old DNS over UDP, but from a system’s point of view, the HTTP is already there for most systems, either because they include a web server / browser, or because most modern RPC systems are HTTP-based anyway.

    And what’s the cost of HTTP? Well, at the very least you already be using HTTP/2, but Cloudflare, Mozilla, Google and others are already deploying HTTP/3 ahead of the final RFC which will be hopefully happen early next year. With DNS-over-HTTP/3, you should get roughly the same latency of UDP (amortized over multiple DNS requests), along with header compression and body compression which should offset the overhead of classic HTTP (at least in part).

    There are already several HTTP/3 transport libraries to choose from, and they’re all free software and maturing fast. So there are zero excuses for not using them in your DoH implementation.

Leave a Reply to JulianCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

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