Skip to content
Naked Security Naked Security

DNS over HTTPS is coming whether ISPs and governments like it or not

DNS over HTTPS (DoH), backed by Google, Mozilla and Cloudflare, is about to make web surveillance a lot more difficult.

The penny has finally dropped inside ISPs and governments that a privacy technology called DNS over HTTPS (DoH), backed by Google, Mozilla and Cloudflare, is about to make web surveillance a lot more difficult.

In the UK, this matters because under the 2016 Investigatory Powers Act (IPA), ISPs are required to store a record of which websites citizens visit for the previous 12 months, which is done by noticing Domain Name System (DNS) requests, e.g. to

DNS over HTTPS (and its close relative DNS over TLS, or DoT) makes this impossible because it encrypts these requests – normally sent in the clear – hence the panic reported in a recent Sunday Times article (paywall).

For more detail on how DoH/DoT works, read our previous coverage on the topic. The takeaway, however, is that Britain’s National Cyber Security Centre (NCSC), and probably the US Government think its unexpectedly rapid evolution imperils the monitoring of terrorism and other illegal content.

Big ISPs also worry it will interfere with complex Content Delivery Network (CDN) traffic caching, make customer management through support and captive portals difficult, and leave them fielding calls from unhappy customers when the third-party DNS servers offering DoH fall over.

Confusingly, the Sunday Times story also says DoH will stymie the UK’s controversial porn block, which enforces age checks before adults can visit big porn sites, although it’s not clear how – encrypting DNS hides the domains people visit but not inherently the fact web requests are being made from UK ISPs (although it would stop ISPs from implementing their own domain filters).

DoH’s sudden rise

Filter the hysteria and what you’re left with is a technological conflict between ISPs which have traditionally controlled the first leg of every internet connection and companies that control the software that sits on devices – this is primarily Google but also companies such as Cloudflare and partner Mozilla which promote privacy.

Today, users connect to the internet by paying an ISP for a connection. In effect, under DNS over HTTPS, they will then establish a second DNS connection to servers run by companies such as Google and Cloudflare to make web browsing private.

It’s come to a head now because Google is in the process of implementing DoH as part of its public DNS system (, which will be supported at some point in the world’s most popular browser, Chrome, and is already supported in Android 9 (this has been possible for some time on older Android versions by using Google’s Intra app).

Mozilla, meanwhile, has identical plans for Firefox implemented via Cloudflare’s service, which the company is still testing, while Cloudflare released a dedicated Android/iOS app last year.

Currently, if a government agency wants to know which sites you’ve been visiting they can ask an ISP. In theory, under DoH they could do the same by asking Google, Cloudflare or Mozilla.

Unfortunately, the problem isn’t simply whether those companies would agree to comply, but whether they could even if they wanted to.

For example, Cloudflare has previously said it only logs DNS requests for 24 hours and plans to prove that with a public audit of its behaviour run by KPMG. Compare that to ISPs which in many countries now collect domain data for up to a year.

Here to stay?

It should have been obvious that something like DoH was coming, since a slew of proposed technologies for encrypting DNS requests started gathering momentum in 2017. Last October, the IETF formally adopted DoH (aka RFC 8484) as the simplest route for this to happen quickly.

Not everyone was happy with this for architectural reasons, not least because it places a lot of trust in the resolver, principally Google, Cloudflare and anyone else who adopts it.

Hitherto, the internet has been built as a compromise between what the user could do and what the service provider would let them do. DoH, some claim, upsets this balance.

The counter-argument is that too many ISPs and governments have lazily used DNS as a quick surveillance fix, for legal, political but also commercial reasons.


An increase in privacy can only be a good thing. However, ISP’s can (and probably already do) perform rDNS (Reverse DNS) queries on the IP address that you connect to (regardless of you using DoH or not) to get the information they need. So it’s not impossible, but as the article also states, it is making surveillance more difficult.

Added to that, the Server Name Indicator (SNI) header is visible in TLS connections (that is, until Encrypted SNI (ESNI) is fully rolled out), thus the information of the website you’re connecting to may still be visible when you connect to the website’s IP address securely. This is common for cloud based web hosts, where IP’s are shared between websites.

In this article we’re talking about browsers – and only browsers. It’s positive that the browsers are increasing privacy for us, but keep in mind that it’s only privacy of our browser’s traffic that is being enhanced here. Unless using something like a DNS Proxy in your infrastructure.

‘DNScrypt-Proxy’ gives you DoH for all your application connections and supports DNS Security Extensions (DNSSEC) too, which are digital signatures based on public key cryptography – like the SSL certificates for domain names – it ensures the data is signed by the owner.


Reverse DNS only works if you’re using a non-encrypted resolver – conecting a browser to an DoH esolver and there’s nothing bouncing back. SNI is still an issue, yes, but also a lot more complicated for ISPs to log using today’s systems.

When you say “only browsers” that’s how most people browse the web! Interestingly, Cloudflare has proposed linking DoH to a sort of reformed VPN concept (‘Warp’) so the idea might in time migrate to something more comprehensive.


My point was that reverse DNS works for ISP’s (and anyone) that want to know the DNS name of the IP’s their customers connect to. DoH can hide the DNS names from the ISP’s but not the target IP address.
I quoted ‘only browsers’ because a ‘lot of people’ use apps in place of browsers :)


Reverse DNS fails when you connect to cloud services. Example If it leads you back to an Akamai server – it won’t tell the isp I who the tenant was inside that CDN.


If it leads you anywhere Aaron, it hasn’t entirely ‘failed’. It’s the start of the trace.
For cloud services I agree that finding this information is harder – however, all that is needed for anyone ‘investigating’ is the target IP to start with. The SNI could be visible unless ESNI in place.
Perhaps more valid (or simpler) for non-cloud based services.


Reverse DNS will typically lead to a meaningless address. Say “example.test” has uses an ISP using “isp.example” for the PTR records. By default, a static IP of will have a pointer record leading to something like “203-0-113-311.ips.isp.example.” The ISP will also have a corresponding A record. Cloud and CDNs also point back to meaningless domain names.

As far as I know, example.test will only have to care about reverse IP lookups for email, possibly.


If you have your own DNS server using DNSCrypt to encrypot DNS queries, the ISP still can know where have you been connected ?
Thanks in advance


So what happens when my company has internal web resources, that Google or Cloudflare cannot resolve? Will users now not be able to use internal business apps because browser lookups fail because they are not using my internal DNS resolvers who know about inside and outside web sites?


The browser would use local name servers as in classical DNS. Or if browsers entirely switch to DoH, LANs may have to incorporate internal DoH servers. That’s one solution at least – there’s better ways probably.


This is why you run a VPN until this is implemented. And even then I’m stay with my VPN!


Perhaps, but there are still question marks over a lot of VPN providers in terms of reliability, expense and – ironically – privacy.


Except most and by most I mean probably around 99% of VPN’s sell your data even when they say they don’t.

If the VPN is free then it’s basically a 100% chance information is being sold but even almost all of the paid ones can’t really be trusted.

You need to do quite a bit if research to find one that says they don’t in their TOS and also sticks to it. So don’t think just because you use a VPN that your information is secure.


So what we’re NOT gonna do is ignore privacy and consent, which have both been left out of this technical equation! As the US lacks a national privacy law like the EU, and absent law enforcement consistency in applying our patchwork of laws and regs, content users privacy and ability to mask, along with consent make this a very tangled web to untangle. We need to do better. We as adult users need controls for privacy (safe and private browsing settings are a joke, mostly); security (protect/mask me if I ask, safeguard my communication in transit); and I have the right to be anonymous. Period.


Why share all your DNS information with a VPN provider if you don’t have to?

Unencrypted DNS requests are shared with everyone on the same network as you, your ISP and your DNS resolver. DNS requests encrypted with a VPN are shared with your VPN provider and the DNS resolver. DNS requests encrypted with DNS-over-HTTPS or DNS-over-TLS are shared with your DNS resolver.


I good VPN provider does not log users’ internet activities, however if someone would use the free ones then they are susceptible to there data being logged. Furthermore, the service I use encrypts all traffic.


I’ve been using it for quite a while. I use cloudflare on Android through the adguard app and I also have my router set to use cloudflares DNS.

I’ve found both cloudflare and Google’s DNS to be significantly faster than Comcast’s with the added privacy bonus. I’ve decided to stick with cloudflare because I’ve seen Google’s DNS go down multiple times and I’ve never had an issue with cloudflare.

There are also now DNS that will act as adblock which offer an extra layer of security. These days malware can and has been served through ads, even through Google’s own AdSense network so blocking ads has become every bit as important as running AV scans.

It’s unfortunate for websites you want to support but no matter who is their ad provider it’s insecure so you are better off just blocking them and if a site you want to support has another way of giving them money to show that support then it’s better to do it that way

Also now we have brave browser which uses crypto currency generated by browsing and interaction with sites. They are still building that system out but eventually the user will earn money for browsing and they can easily donate some of it to any site that participates. The ads are served by the browser itself and not the website so they are in theory more secure as they can be vetted before they go live

It’s a brave New world lol.


Would be good to have this support in Sophos XG too.. practice what you preach right? Feature request added a year ago, still not added.


What reporters have been missing 100% is the eventual reaction to this effort from a policy and follow-on technology perspective. If DOH is implemented in way that holds HTTPS hostage, then governments/network operators/enterprises will make HTTPS unavailable and will force anyone who wants “Internet” access to pass through an entirely new layer of privacy-stripping that is far more intrusive than what exists today. Technology is not legislative. Beware the law of unintended consequences; they are particularly harsh in this model.


Not sure how governments would make HTTPS “unavailable” (ether technically or legally) but the point about privacy and Internet conections is surely what has led to the development of DoH in the first place.


I’m unclear on how you think legislative actions cannot create technical conditions. Look down one comment in this list for proof of both. Someone states “it is not working in China.” This model will expand. Blocking end-to-end protocols and forcing proxy use is not only possible, it is perversely encouraged by DoH. Hardware companies will have a brand new device to sell, and will create a market around “anti-terrorism proxies” or some other absurd pitch, further encouraging governments to legislate such things. Free nations will not gain much with DoH that DoT doesn’t offer, but citizens of authoritarian nations or nanny state nations will lose freedom in a way that is not being considered. Every action in an arms race has has a reaction, and this reaction is not going to be good for end users. Introduce the fission bomb of absolute client security, and you should be prepared for the hydrogen bomb of disconnection. I am not encouraging lack of security; my hope is to see security done in a different way that wasn’t so inflammatory and potentially destructive. There are ways DoH can be implemented that are less explosive, but that was not the intent of the protocol. Maybe the division I see in the future between “free” and “unfree” networks is inevitable.


Wonderful article. I have implemented DoH on my home router and have gone one step further by writing firewall rules to rule any DNS leak out of my network. Not a single DNS query leaves my network unencrypted regardless of where it is originated. And, impatiently looking forward to the anonymised DNS initiative by DNSCrypt 2.0. Hope to see that merged into DoH for one final shot in DNS security. And thanks to Firefox and Cloudflare for standing by the right side.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!