Whenever I talk about DNS encryption, I get a lot of feedback from people saying they had no idea what’s been going on in this area. And that’s not surprising; there’s a lot going on right now, and it’s all happening way faster than usual.
The aim of this post is to talk about how things have been developing over the past five years and to look at some of the good, the bad and the ugly things happening in DNS encryption today. In particular, what’s the status of the IETF standards DNS over TLS (DoT) and DNS over HTTPS (DoH), and what’s the deployment status of clients and servers for those technologies?
DNS over TLS (DoT)
Work on DoT started four or five years ago, triggered by the Snowden revelations, which revealed the extent of the pervasive monitoring that was happening in the DNS. Taking a strong stance on this, the IETF declared pervasive monitoring an attack on the Internet (RFC 7258). They formed a working group (WG) called DPRIVE, whose goal was to look at encrypting from the stub to the recursive resolver.
After a few years of wrangling with various solutions, the WG decided the way forward was to use DoT. They soon established a new dedicated port — port 853 — for the service, which became a standard two years ago.
DoT implementations
At this point in time, there are now a whole range of DoT implementations out there. There are a number of existing client and server implementations, twenty test DoT servers, and more recently, DoT services being offered by Quad9 and Cloudfare.
Many implementations — for example, Android Pie and systemd — employ a mode of doing DoT known as opportunistic DoT. In these cases, the system resolver actively probes the resolvers it gets from DHCP on port 853. If it discovers a server offering DoT on that port, it’ll use it in preference to doing cleartext. If it can’t, it does normal DNS.
It’s worth noting that when we look at the DoT implementations currently on offer, most are at the system resolver level. We are missing native implementations in Windows and in Mac OS and IOS, but there’s every reason to hope they’ll appear in the next few years. If you want to stand up a DoT server, it’s easy. There’s a lot of software that supports it and there are plenty of guides on how to do it.
Encrypted DNS
What do you get when you encrypt DNS? Well, actually you get a lot; some of it good, some bad, and some ugly.
The good
The most obvious good thing you get is that you defeat passive surveillance. But you also get the option to configure the client with authentication information, meaning it can use PKIX (Public Key Infrastructure for X.509 Certificates) or DANE (DNS-based Authentication of Named Entities) to authenticate the server at the far end of the connection. This in turn lets you: prevent redirects (as the client is able to choose to hard fail if it can’t authenticate that server), enable clients to detect the interception of their DNS queries, and arguably increase trust in the service you’ve chosen to use. For example, if you’ve chosen to use a resolver because it does DNSSEC validation or a certain type of filtering, authentication guarantees you that service.
And while we’re still on the good, as a nice side effect, DNS encryption also gives you data integrity of transport, meaning spoofed responses can’t be injected into an encrypted stream.
The bad and the ugly
One question you sometimes hear asked is: why even bother to encrypt the DNS? After all, the Server Name Indication (SNI) still leaks. The good news is, not for long. There’s a solution in TLS 1.3, which has proof of concept code and a draft in the IETF — so it looks like encrypted SNI will soon be a reality.
What’s perhaps more of a concern right now is that, as already mentioned, DoT runs on a dedicated port, which leaves open the possibility that the port could be accidentally or even intentionally blocked. DoT can, in principle, also be run on port 443 as a fallback, but that’s not the default.
Then there’s the more general issue of which resolver you’ll use for your queries. As a single entity that sees all your DNS queries, you really have to ask which resolver you can trust to provide that service.
Most of the servers at the moment are anycast servers in the Cloud, or servers operated by a handful of individuals. DoT just isn’t being served within a lot of networks today. So if you want to choose to actively encrypt your own DNS, you have to go outside your network.
However, this can cause operational problems — for example, breaking split horizon DNS. It’s certainly possible that a client might have some fallback mechanism where it initially tries to resolve externally on an encrypted connection, but then reverts to doing it internally via UDP if need be. The problem is, at that point, the private names have already leaked, and what’s worse, with an encrypted stream, the operator can’t actually see this happening.
Operators are faced with the very real concern that encrypted DNS will bypass their local monitoring and security policies, and so create a conflict for them. As a result, we have a case where providing additional privacy for users is directly producing an operational concern for operators.
Sara Dickinson presenting on DoH during the 29th DNS Operations, Analysis and Research Center (OARC) workshop in Amsterdam, October 2018.
DoT to DoH
The goal of the DPRIVE WG was to encrypt the DNS with the smallest possible delta on top of the existing infrastructure. No one has ever really suggested doing anything other than encrypting from system resolvers to the resolver already used, so these cases of bypassing the network were expected to be short‑term or rare.
With DNS over HTTPS (DoH), things are quite different. The deployment model is going in a very different direction and it’s being led by browsers. This means browser developers are talking about potentially doing DNS over HTTPS directly from the browser to a set of pre‑configured cloud resolver services.
So, where does HTTPS fit into the picture if we already have a solution in DoT?
Well, DoH is a much more recent development, work only having started on it about eighteen months ago. That said, despite being new, things have been moving remarkably fast with DoH. A working group was whipped up very quickly at the IETF to get a new protocol defined, the draft went through, and it’s already a published RFC (RFC 8484).
Where DoH differs from DoT
At the specification level, there are a number of differences between DoT and DoH. For instance, for DoH, the use cases are much more ambitious. One use case called out in the specification says that DoH will allow web applications to directly access DNS information using existing browser APIs, which puts DoH in a very different context right from the get go.
Also, with DoH, when it comes to discovery, according to the spec, you must use a URI template to connect to a DoH server. Today, however, we have no standardized discovery mechanism where you can do this, so there is no option of doing opportunistic discovery probing, although there are proposals in the works to deal with this.
All this gets interesting when you think about the connection models. Obviously with DoT you are doing dedicated connections. And there’s a comparable model with DoH, where you open an HTTPS connection and the only thing you send on that stream is DoH queries. But there’s also the potential for a mixed mode scenario with DoH. This would mean that an application like a browser could have an existing HTTP connection open, and through some discovery mechanism it could determine that the far end has a DoH server, allowing it to start sending its DNS queries over the existing connection, completely mixed in with the HTTPS traffic.
Now, there is a use case to say this could be beneficial from a privacy standpoint. If I have a browser open to a tab for, say, mybank.com, and mybank.com does DoH, then I can send my DNS queries to mybank.com and I’m not then leaking them to a third‑party because that bank already knows all the content I’m looking up. But what makes things even more interesting from an operational perspective is that, of course, if these mixed connections do contain DNS queries, it becomes impossible to block just the DNS traffic that’s happening there. That could be very good for users who are in oppressive network environments, but for operators this is a brand new challenge to think about.
DoH status
In terms of deployment and implementation, DoH has probably achieved in eighteen months what DoT did in five years. There are multiple test services, and CloudFlare, Google, and Quad9 all offer DoH.
In terms of the clients and servers that are available, while browsers such as Firefox and Chrome are very much leading the way, there are also some desktop applications available for those interested in going down that route.
DNS in browsers
There are actually a number of browsers that do their own DNS.
Chrome has had its own DNS implementation for a while and there are a handful of others out there that already use encrypted transports.
Firefox has had a DoH implementation since Firefox 60, so for well over six months. This isn’t currently enabled by default, but there are experiments underway (see below).
Chrome has a full DoH implementation that’s neither exposed nor advertised at this point, but which we can expect to see appear in the very near future.
Why is the browser community looking to encrypt directly from the browser? Well, for one thing, waiting for OS support is the slower option. Browsers control the clients, so they can put new releases out in a matter of days or weeks without waiting on the much longer time scales for OS changes. Also, it gives them a unique selling point and an opportunity to improve user experience in terms of latency within the browser.
Well OK, but why choose DoH instead of DoT? According to Mozilla, there are various reasons for going with DoH, including the fact that from the browser developer’s perspective, leveraging the HTTP ecosystem makes a huge amount of sense — they understand proxying, they understand caching in that world — they think they can accelerate the DNS by doing this. You have a whole community of people saying don’t bother with a new port, just put encrypted DNS on port 443, it never gets blocked, it just works.
Lastly, it’s kind of a ‘shiny new things’ scenario for the browser folks, because when you start doing DoH, there is the potential to do all sorts of cool things: you can define new media types, you can do server push, and there are proposals for doing what’s been described as ‘resolverless DNS’. So there’s a whole range of potential for this that’s quite unexplored at the moment. Indeed, some people have even suggested this is a way to do DNS 2.0 without actually doing DNS 2.0. I’ll leave you to make up your own minds.
The Firefox experiment
Back in May, Firefox announced in a blog that they wanted to do an experiment, and in that blog they said a couple of things that really caught people’s attention. One is that in the long term, they want to turn DoH on by default for their users. The other thing they said is that they have an agreement with CloudFlare for a DoH service, because CloudFlare has a very strong privacy policy in what it does with its DNS data.
They then coined a brand new term — Trusted Recursive Resolver (TRR) — and said that “because CloudFlare is our TRR, it means that we think Firefox can ignore the resolver provided by the network and go straight to CloudFlare”. So that was the proposal at the time. They went ahead and did the experiment in June and they blogged about it in August. They did it by opting in half of their Firefox nightly users and sending all queries in parallel to the system provided resolver and out to CloudFlare. Then they compared the results.
What I found particularly interesting is, when they wrote up the results for this, they enumerated the questions that they were trying to answer, and number one was: ‘does the use of a cloud DNS service perform well enough to replace traditional DNS?’. It wasn’t about validating any nitty gritty details of the protocol. It was about answering this much bigger question. The conclusion they came to was that if you use CloudFlare, you take a 6‑millisecond performance overhead, and given that you get encryption for that, the cost is acceptable.
So, the experiment continues. Firefox have announced that they are committed to investigating the cloud providers as the option that they want to look at, and in September 2018 they announced another experiment, which they are moving to Firefox beta.
Trusted Recursive Resolver
This notion of TRR is worth looking at in more detail. Since those original posts, Mozilla have been very careful not to commit to saying what their config will be, and if you ask them in various places they’ll say they’re still trying to figure this out. So it’s not a done deal, and the DNS community is in limbo waiting for this decision from browser vendors — a decision which could have an enormous impact on how stub-to-recursive DNS works.
One of the things it will do is alter what is, today, the implicit trust model of DNS. When you choose to log on to a given network, you accept implicitly that you are going to use the resolvers provided by the network. This could change to installing an app, and somewhere in the however many pages of Terms and Conditions, there’ll be a line saying the application is going to send its DNS queries to the resolver of its choice using DoH. So this is an interesting question, and one of the concerns it’s raised in the community is; does this mean we are heading towards a potential centralization of DNS resolvers? Given that, today, browsers have lists of CAs that they trust, can you imagine a future where we have lists of DNS providers that they trust? If you want one that isn’t there, you would have to go in and manually configure it.
Reactions
The reactions to this news, as you might imagine, are mixed. Some say it’s good that this is provoking discussion about the fact that DNS needs to be encrypted, as it helps bring operators face-to-face with the reality that this is coming their way. Some people are highly uncertain and somewhat concerned about what this will bring about. For others, this is the single worst idea that they have ever heard and it’s the end of the DNS republic as we know it.
In general, there are certainly reasons why some would feel uneasy. Many operators, for instance, have a legal and regulatory obligations to manage the DNS coming into their networks and are not prepared for this change. If this got turned on tomorrow, they could find themselves in all kinds of trouble. This has led some operators to say they’ll be forced to either block this traffic or proxy it, because they need to have control of their network. After all, historically they’ve had the luxury of unencrypted DNS.
Then there are questions about the legal issues. Within the EU’s General Data Protection Regulation (GDPR), users are required to give informed consent if their data is going to be transported outside the EU. But how many people do you know from outside the tech community who can give informed consent about what should happen to their DNS queries when (a) they don’t understand DNS, (b) they probably won’t look at changes in the terms and conditions, and (c) they’ll encounter cases where the provider doesn’t state clearly what jurisdiction their data falls under.
This brings us back to thinking about the fundamental threat model involved with DNS. There’s no arguing that a TRR can be useful in some networks. If I’m in a coffee shop, for example, I’d probably much rather go to somebody like Quad9 than use said coffee shop’s DNS resolver.
In terms of ISPs, in the US, the lack of net neutrality means that many users there view their ISPs as a threat because they are aware that those ISPs are directly monetizing DNS queries and selling them to advertisers. The converse is true in the European Union. Because we have GDPR, our ISPs are very tightly restricted in what they can do with our DNS data, and so nine times out of ten your ISP is probably a better choice in terms of privacy than any Cloud based DNS resolver. So, in terms of those questions about where you choose to send your queries, there are multiple options.
Another slightly scary aspect is if you start thinking about this concept of applications choosing TRRs. What happens if some governments decide that if an app is to be available through the local app store, they have to use certain government‑maintained TRRs. What if some TRR operators start providing monetary incentives to app developers to use their TRR? Will any of this be transparent or obvious to users?
The bottom line here is that there are lots of questions, not a whole lot of answers at the moment. (For more examples and issues, I’d strongly encourage you to read a blog by Bert Hubert (PowerDNS) where he goes through some of the other implications of moving to a third‑party DNS provider.)
Lastly, I just want to call out something which comes from a slightly different perspective. One thing that enterprises are going to have to worry about here is what challenges they are going to face if they need to manage the DNS configuration for lots of end devices.
Today it’s straightforward because you can do it with Dynamic Host Configuration Protocol (DHCP). However, in this world, each app could have its own configuration for where it’s going to send its DNS data. We don’t know what the other browsers are going to do. We don’t know what other apps are going to do, but there is as real possibility here that we will lose a central configuration point on an end device for where you choose to send your queries and that DNS will disappear into content delivery rather than being part of the infrastructure of the device.
What should YOU do?
With all this in mind, here are some words of advice:
- If you’re an operator, think about running DoT on your server — there are already devices that will be probing on port 853, and that number is small today, but it will increase as Android Pie deployment increases and as the various operators pick up the new release. So it’s the right thing to provide them the opportunity to do encrypted DNS within the network.
- Think about running a DoH server — wherever the story with the browsers go, it’s a good thing if users have the option to use a local DoH server in a trusted network. So we think it’s the right thing to start getting people thinking about doing this and running it and what the challenges will be.
- Watch this space and keep an eye on all the current work that we’re doing — there is work on discovery for DoT and DoH and we don’t quite know where that’s going to go. There is a draft that I talked about a couple of years ago in the BCOP group on best current practices for operators of DNS services, because this is now an important thing. Users might choose whether to use your service or not solely on the basis of your privacy policy. So, we need to be transparent about this and accountable to our users.
If you are interested in this topic, at the recent DNS OARC workshop I gave a more detailed talk on this (slides, video) and also keep an eye on the dnsprivacy.org website, on Twitter, and there is also a session in the RIPE 77 BCOP Task Force session talking about doing DNS over transports other than UDP and the operational challenges of that.
My concluding remark would be, basically; stay tuned. We really don’t know where we’re going to be with this in a year, or perhaps even in the next couple of months, and there’s a lot of concern in the operator community about where this could go and the implications for them.
Adapted from original post which appeared on RIPE Labs Blog.
Sara Dickinson is co‑founder of Sinodun IT, based in the UK, a small consultancy doing all things DNS.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Those who prostitute themselves on corporate media outlets (a.k.a. social media) shouldn’t care at all. They already sold privacy…