With recent announcements from Mozilla about wanting to use DNS-over-HTTPS by default and partnering with Cloudflare to at least test this, I’ve been giving the matter of DoH quite a bit of thought. This is therefore the first of two possibly three articles dealing with various aspects of DNS over HTTPS. For those that are unaware the idea behind DNS-over-HTTPS ( henceforth DoH ) is that DNS isn’t by default secure or private so let tunnel it over HTTPS so that those pesky firewalls don’t get in the way and secure it that way. This will allegedly make DNS faster, more private and just all round better. Personally I think it will do few if any of those things and that the problems it will create will far out weight any perceived benefits. As Bert Hurbert said this looks a lot more like a land grab by CDN and browser vendors – I’m inclined to agree.
The first problem I have with the DoH is that it’s trying to solve a very specific problem that predominantly afflicts mobile users and then the likes of Mozilla are trying to impose the solution to that problem on the rest of us. Mozilla make this clear in their Cartoon introduction to DoH.
“This means that the resolver that you’re using can change multiple times per day. If you head to the coffee shop for an afternoon work session, you’re probably using a different resolver than you were in the morning. And this is true even if you have configured your own resolver, because there’s no security in the DNS protocol.”
The corollary of this is if you’re not a mobile user and don’t connect to multiple networks a day, then your DNS resolver isn’t actually going to change often at all. Further if you configure your own DNS settings then they aren’t going to change just because the network changes, your DNS queries may be snooped but your DNS server won’t change. So for mobile users this is a problem, it’s also a problem which is solved by taking advice which has been around for years, if you’re on an untrusted network use a VPN. If the network you’re on wants to see your DNS traffic (for whatever reason) it will be just as easy for them to block HTTPS traffic to the well known public resolvers as it would be for them to block VPNs or secure DNS traffic – at which point you’ll fail back to using the local DNS server, or you simply won’t have working DNS. The other advantage of using a VPN is that it secures all of your traffic rather than just the DNS requests made by your web browser.
So what if you’re not a mobile user, who for some reason is worried about DNS security but not worried enough to use a secure DNS client or VPN solution? Well then assuming that as the DoH people like to claim that you’ve not taken any steps to pick a specific DNS service you’ll use whatever DNS servers the local network suggest which will be typically either:
1) The DNS servers your company network team want you to use
2) The DNS servers your ISP/cell co provides
I would suggest that if for some reason you feel that you can’t trust your ISP then you probably have more things to worry about and a VPN is probably the right choice for you. In a corporate environment again you do rather need to trust the DNS servers your company uses and not using them ( if that’s even possible ) is likely to cause problem so more of that later. This idea that most users are unaware of their DNS settings and are unlikely to change them, also indicates that the proponents of DoH ( e.g. Mozilla ) also expect that end users will be unaware of their DoH settings and won’t change them from whatever default the browser/app vendor chooses. Which seems rather reminiscent of the search engine wars where every program, browser, application wanted to change what your default search engine was – I suspect we may easily see a re-run of that but with everyone wanting to set your default DoH servers. Further I’d expect that the less scrupulous application vendors ( of which there are many ) may well not give you the choice of which DoH servers to use at all. Which leads me on to my first big problem with the concept of DoH.
Today DNS settings are set once on a device and then the same settings are used by every application on that device and the results are cached locally and shared between all the applications on that device. This means that once you’ve visited articles.scramworks.net in one browser your computer will have that result cached so if you then access it via an RSS aggregater or another browser your system already knows the address and doesn’t need to do another look up, with DoH every application using it will have its own cache so will have to do its own look ups. Apart from this being inefficient it also means that every application may potentially get a different DNS response. Today if you’re having problems with DNS look ups and you call support they can check in one place see what DNS server you’re using and trouble shoot that with relative ease. If each application is potentially using a different DoH server and getting differing results then the load on support desks is going to increase hugely and their ability to assist is going to decrease. Just finding out which DNS sever an application is using is going to become a task, let alone then being able to trouble shoot it. I suspect many help desks will take the approach of not assisting.
Next up security.
A comparatively recent development in the DNS world is a thing called a RPZ. This allows your company, ISP or the DNS provider of your choice to block malicious domain names so that you don’t accidentally go to them, as well as allowing virus command and control channels to be disrupted. This idea has been amazingly successful and is quick and cheap to implement and protects every application on your computer no matter what it is. It’s also the principle behind the increasingly popular ad blocking Pi Hole. With DoH you now have the spectre of applications bypassing such protection to go off to some other random DNS server which may have a different idea as to what should be blocked. You end up sacrificing locally implemented protection ( and in some cases legal requirements ) in favour of whatever protection the DoH provider of a given app provides and they can of course redirect any DNS name to any server they like. Now I’m sure Cloudflare isn’t going to do anything untoward but if DoH becomes widespread I’d not want to bet on every application particularly if it means they can avoid your ad blocker. The other security argument that the DoH advocates seem to be depending on strongly is that they can run their DNS servers in a more secure fashion than you, your ISP or your companies IT team. Now that may or may not be true, but again the solution is surely to either improve those DNS services or to use a DNS service you do trust to be secure, rather than to trust the decisions of the application vendors to be acting in your best interest? The question of legally mandated blocking is also interesting as in the UK ISPs can meet legal requirements to block specific sites by doing so at the DNS level, if using DoH becomes the norm then this is unlikely to continue to be considered sufficient, at which point things like deep packet inspection and state firewalls start to become the required technology which would result in all of your traffic being monitored.
Finally privacy.
The privacy argument is as far as I can tell based on two issues:
1) DNS isn’t encrypted
2) To support geographically based DNS and CDNs ( such as cloudflare ) a thing called EDNS0 was introduced to DNS which passes on part of your IP Address to the final DNS server so it can give you the “best” answer.
These two things combined mean that potentially anyone between you and the final DNS server will get to know part of your DNS and so might be able to track you to some extent depending on how much of your IP address is passed on. This problem is already been mitigated by QNAME minimization where your DNS server only asks each DNS server it queries the minimum it needs to. The final DNS server still gets to see just what server you’re looking up, but as presumably you want to connect to that server that really doesn’t tell them much they weren’t going to find out in a few seconds anyway. There are also several methods under consideration for encrypting DNS, but these seem to have been rejected by the DoH advocates as taking too long and they can do this more quickly. However even with EDNS0 many DNS requests will go no further than your local DNS server which will answer from its cache, and those that go out to the wider internet will contain just a part of your IP address ( so if there are multiple users in your house which user requested an address can’t be determined ) so you have a degree of privacy. DoH does in theory reduce this if they reduce the effectiveness of Geo load balancing by not telling the remote DNS server as much detail about where you are, something that can be accomplished in most DNS servers. However in return for that increase in privacy you’re exchanging sending some details about your internet facing address to some DNS servers, which doesn’t allow you as an individual home user to be identified, with sending both your IP address and your browser fingerprint to your DoH provider. So whilst there may be a reduction in the number of people that might possibly be able to look at the requests originating from an EDNS0 subnet or internet facing IP, you’ll be providing far more granular information to the DoH provider as between the browser finger print is highly likely to allow them to identify individual users behind a shared IP address.
So much for what it can do to solve the problems the DoH advocates claim to exist, there are also a few problems it creates rather than solving. A few I’ve already touched on:
- By-passing of DNS based security and AD blocking
- Increased complexity in trouble shooting
- Increased load on support desks
- by-passing legal restrictions/censorship which may result in increased monitoring and invasion of privacy
There is another issue which I think that the DoH advocates greatly under estimate: split DNS
On the off chance you don’t know split DNS basically means you local DNS differs from DNS visible on the internet. This is used widely within corporate networks but is also implemented in many home routers so that you can access the router by a name, and so that you can access other devices on your home network by name rather than IP address. The main approach DoH seems to have ( and they do say they’re still working on this ) is that:
“If it doesn’t resolve on the internet we’ll try local DNS”
Which is fine if your company doesn’t use any of the same name internally as eternally, say maybe webmail.company.com has one address on the outside world and another address internally because it uses an internal IP address. Yep things like that are really rare right? Who after all wants to be able to use the same bookmarks to access the same resource via public ( through a firewall ) address when on the internet and via a different address locally. You aren’t using a dynamic DNS server to access your local media server when you’re away from home and the same address to access it directly when at home are you? I mean who’d want to do that?
Whilst there is a need to make DNS more secure and to increase it’s privacy, for those that are concerned about such things there are solutions today that will work for every application on your device. There are also solutions being developed that will secure DNS (DNSCrypt or DNS-over-TLS) without balkanising DNS on a per application basis or causing most of the problems listed in this article. The DoH advocates claim that these are taking too long, but rather than trying to assist those standards they’ve decided to implement their own thing, which coincidentally hands them an awful lot of data – for as they say most people don’t know to change these things and leave them at the default. Which does make it look very much like a land grab with not much concern for unintended consequences to solve problems that are already being worked on and addressed within the existing protocol.