 Hi, everyone. I'm Eric Dorland, and this is DNS Transport Security in WM. We're going to go over a bit about how the current set of protocols, or what the current set of protocols are, a number of DNS service riders that exist that probably didn't exist a year ago that you can use with these protocols. And then just a very quick overview of how to configure this free WM box. So just a little bit about who I am. I've been into a WM developer since 2001, I think, something about like that. That's a while ago. I work in New York as an SRE for Google, but I don't work on DNS. I don't work on any of this DNS stuff, except for packaging DNS crypt proxy, which I'll talk a bit about later. So yeah, with that setting the expectations really low, let's get started. So why would you want to encrypt your DNS traffic? In certain jurisdictions, particularly in the United States, it's possible it is legal for ISPs to collect your web browsing history and sell it to other companies. Obviously, the widespread adoption of HTVS has helped make it harder for companies to sniff your web browsing traffic or your web browsing history, but DNS requests can still leak the sites that you're going to visit. And obviously, encrypting your requests and responses can prevent this kind of collection. And it also helps thwart mass surveillance tooling that governments have deployed, that we know of. But of course, this helps. It doesn't solve the whole problem or it doesn't prevent someone sniffing your traffic from knowing where your packets are going and you would need to use something like Tor to get that level of anonymity. But if you can obscure your DNS requests, that does help. So just a quick word about DNSSEC. DNSSEC is a very nice tool and protocol. DNSSEC provides integrity of your DNS responses and it provides a chain of trust so that you can reason about that the root zone can assign the comm zone and then consign the comm zone consign your zone and you can get the sort of trust established so that you know that someone can't interfere with assigned DNSSEC zone. But that being said, DNSSEC doesn't provide privacy. All of the requests that happen with DNSSEC are in the clear. You can still look at them. You can't fiddle with them without being detected, but they're still available for someone to look at. So what I'm going to be talking about is sort of the privacy aspect where you encrypt the traffic so that it can't be observed either. So DNSSEC is great, but that's not what we're going to talk about today. So quickly going over the protocols. So we're in the standard sort of protocol space here where there are a number of standards. It's not quite up to 15, but give it some time. The first protocol we're going to talk about is called DNSCrypt. It was established around 2011, but it's sort of a written implementation. There's like a written protocol document, but there has been no standardization of it. It was initially developed for the company that ran OpenDNS, and they still, you can use this protocol with their resolvers. There's no real, they don't use the classic sort of certificate authority chain of trust model. You usually have to manually sort of or statically configure the fingerprint for your resolver so that you can trust it. And the protocol is just really just embeds DNS requests inside of an encrypted packet. It's very custom. The next protocol that is actually standardized is DNS over TLS. It's in these two RFCs. This is TLS in the same way that HTTPS uses TLS. So you've got the regular sort of CA chain of trust for authenticating the resolver. It runs over port 853. And there is also a DNS over DTLS, which is the sort of datagram version, the UDP version of TLS in RFC 8094. But I couldn't find any actual real implementations of this. So it doesn't seem to be very popular. Most people are just doing the DNS over TLS. And then finally, there's DNS, this is a newer standard DNS over HTTPS or DOE. In a lot of places, the internet really just means that you can talk over port 443. So having a protocol to run DNS over port 443 is a little bit helpful in that sense. There's a number of HTTP-centric security features that could potentially be leveraged for this, like certificate pinning or key pinning, HSTS, those sorts of things. You could actually do that. And obviously, with HTTP version 2, you've got better multiplexing and headline blocking prevention or sort of fixes in the protocol to do better headline blocking. So you don't have to worry so much about poor performance that you might get with HTTP 1.1. And I think most interesting, there's in this. So the standard is still in draft, and we'll get to that in a second. But there's a provision for using HTTP 2 server push, where the server, a DOE server, could actually push you DNS responses for things you hadn't asked for yet. Because maybe it knew that people who statistically, if you request domain A, it means within five seconds you're going to request domain B. So it might just push that response to you instead of waiting for you to request it. Sort of interesting. I don't think anyone is actually doing that, but it's available in the standard. Unfortunately, the DNS of HTTPS is there's actually two different protocols. The original one, which was developed by Google, that is actually coded in JSON. And it's also over HTTP 1.1. And then there's the newer IETF draft that is over HTTP 2, and it uses the regular DNS format. And I don't think anyone other than Google supports the original one. But that one did came out two or three years ago at least. So it was a sort of earlier implementation of this idea. So those are the main protocols for doing this. So I'm just going to talk about the different server providers that exist out there. So earlier this year, Cloudflare announced their very probably best IP address 1.1.1.1.1 resolver. It was on April 1st that they announced this, which was great. It's always a good time when people announce actual products on April Fools. They support both DNS over TLS and DNS over HTTPS. So I just sort of like documented their logging policy here. I've obviously condensed several page document into three bullet points. So if you're very interested, you should probably actually read it. But from what I could tell, they'll keep full logs for 24 hours. And then they will aggregate and anonymize those logs and keep them indefinitely. And they also share some amount of anonymized data with APNIC for some research project that they're doing. So that's not bad, at least as far as logging policies go. And they definitely have the best IP address. They've sort of won that arms race of coolest IP address. I don't know if anyone could actually beat them at this point. And then there's Google Public DNS. This was sort of the first, I guess, big provider that was providing a DNS resolver for the public back in 2009. And it's the classic 8.8.8.8.8. And there's also, I should have mentioned before, everyone has IPv6 versions of these things as well. Although you can see from Cloudflare and Google, they're much harder to remember, a bit longer. So Google supports DAO DNS over HTTPS. It supports the original protocol that it developed that uses JSON at that URL. And there's this experimental URL where you can use the newer HTTP to DNS wire protocol. Obviously, having an experimental name that would not rely on it for a production workload or anything, but it's there to play with. They don't support DNS over TLS. And their logging policy is relatively similar. They keep full logs for 24 to 48 hours. They keep partially anonymized logs for two weeks where they've stripped out the IP address. But there's some metro level information that's been retained. And then they take some sample that is also kept indefinitely. But they also point out that they'll never combine the data they get from Google Public DNS with any other logging data that they may have. And then finally, there is this resolver that was this project that was released called Quad9 back, I think, in November of last year. I didn't actually put in the slides. But it is a partnership between IBM, the packet clearing house, and the global cyber alliance. I don't remember this getting a lot of press when it came out. Obviously, they've got a pretty cool 9.9.9.9, although their second IP address is very different for some reason. But if you look very carefully, their IPv6 addresses are incredibly memorable. They're much shorter than everybody else. So they're definitely winning on the memorable IPv6 addresses. The other thing about this resolver, they promised to block DNS lookups to malicious domains. I didn't look very hard into what they consider malicious, but they have some sort of blacklist that they will use. They also don't forward the EDNS client subnet option. This is an option in newer DNS that is used by CDNs, where the resolver will send the subnet of the requester to the authoritative server, so they can do some sort of load balancing potentially, or give you an address that's closer to you potentially. But obviously, this leaks a bit more information about who you are or where you're coming from. So these guys strip that out. So that's a little bit of a you may get worse performance, or you may get worse behavior from certain service providers, but maybe a better privacy trade-off. And they actually have a different set of endpoints that are very similar that don't do these DNS blacklists. And it does forward the EDNS client subnet. And their logging policy says something like it claims it never logs the IP addresses to disk, which I'm a little dubious that that could possibly be true, and that they will keep anonymized logs indefinitely. So those are, I think, the big ones. There's a number of other server providers that you can get that will do encrypted DNS. There's a comprehensive list at this URL. Most of these other providers don't use anycast. So they don't have this very cool single IP address that works from anywhere in the world that you get with anycast. So you have to be a little more careful about choosing a server that is sort of network close to you or physically approximate to you. Otherwise, performance will be pretty poor. The other thing is the smaller providers may provide somewhat less protection due to there is less traffic coming out of them on the other side to hide in. For almost everyone here, the request to the assortitative, like you request to Cloudflare's resolver, and that's encrypted. But then they'll go and do the lookup to the authoritative servers. And right now, that is not encrypted. So if you're using a resolver that doesn't get a lot of traffic, you're losing a lot of the anonymity because if your attacker can observe the resolver, they can just see what your requests are because you're the only one using it or there's very few people using it. So that can be a little bit tricky to make that decision. But if you don't want to trust one of these larger providers, obviously there's a bunch of different options. The list is probably about 60, 80 different servers you can use. And the other option you can do is you could use multiple different providers. I know DNS Crip Proxy, which I'll get to in a second, can sort of run Robin between different providers. So no single provider. If you do that, no single provider could see all of your DNS queries as well, which might provide you some additional protection. So I'm going to go pretty fast here. To turn this on in Debian, there's a few options. One is Unbound. Unbound is a resolving DNS server that's pretty popular. It supports DNS over TLS when forwarding, but it doesn't support DNS over HTTP. And it actually sort of supports DNS Cript, but not on the forwarding side, just on the client side, which is probably pretty useless, but it's there if you somehow wanted it. Excuse me. So to set up Unbound, you would just apt-get install it. And then to sort of use the example here with Cloudflare, but you can obviously pop in any addresses that you wanted. And you would just have to put a little config snippet into the Unbound conf.d directory there and reload Unbound. So DNS Crip Proxy is another option. This is the package that I maintain. It's the only one, I think, that supports all three of these protocols. It does DNS Cript. DNS over TLS and DNS over HTTPS. It used to only support DNS Cript, but there's been a recent 2.0 upgrade where the whole thing has been rewritten and go. It was pretty hard to actually finish packaging it. I just did a good upload of it this morning, so hopefully all of this does still work. And you can just use it by, if you have to install DNS Crip Proxy and resolve conf, it will automatically make that your local DNS resolver. And I've got to configure to use Cloudflare out of the box, but you can use it with, you can obviously change the configuration. And now I don't know if everyone's aware of this, but SystemD also has a sort of stub resolver that can forward DNS requests to also have a local DNS cache. SystemD ResolvedD, it's called, and it now has support for DNS over TLS as of SystemD 239. It's disabled by default. If you add that little line there and configure it to use one of those providers that has DNS over TLS, you can get it to encrypt the traffic as well. And they claim that it will likely be turned on by default in a future release, so you won't even have to do that much. Last but not least, so Firefox announced recently that they're going to start supporting DNS over HTTPS directly in Firefox 62. And there's some instructions on how to set that up. Firefox 62, I think, is the current developer. It's currently a developer release, and they're going to do a full release in September, so it'll be the next version of Firefox to come out. And they also claim that they're going to enable this by default. And by default, it's configured to use Cloudflare, but you can change that in the configuration options there. So a few other tools in Debian that support this. For the interest of time, I'm going to keep going. And so if you remember, if you start to configure this and you run into a problem, just remember this following mantra, it's not DNS. There's no way it's DNS. It was DNS. So in conclusion, just a couple other links that are pretty interesting. When I was doing research for this, I came across thednsprivacy.org. They're building a bunch of tools and have a lot of good documentation about how to encrypt DNS. And they seem to have a goal of advancing the state of the art of DNS privacy. There's also this really interesting paper called Oblivious DNS, where it's kind of similar to Tor a little bit, where you have this Oblivious DNS server in the middle, and you do a DNS request to your normal resolver that is encrypted. And then that gets forwarded to the Oblivious DNS server, which then goes and asks the actual authoritative server. And it means that the resolver and the authoritative server don't can't see what the original request was or where it came from, and the resolver doesn't actually know what you asked for. So it's a pretty cool paper. I didn't have enough time to go into it, but it seems pretty interesting. So just to summarize, I think what's probably going to end up happening, the DNS over HPS is still a draft standard, but I suspect it's going to get standardized. Firefox will turn on by default. SystemD is also going to be turning on DNS over TLS by default. The DNS script protocol is probably dead. I don't see anyone really going forward with that protocol, even though it was the first one in this space. The Oblivious DNS stuff may become interesting, but I don't think it was actually an implementation of it yet. So that'd be cool. And I think most last mile ISPs are not going to offer any of these features. Your Verizon's and your Comcasts probably won't do this. And that's my presentation. Thanks, everybody. Any questions? Please come up to the mic. Is anybody trying to get ISPs to adopt it, or is everybody happy that we now depend on Cloudflare for DNS? I mean, I don't know that everyone's happy about that, obviously. But I haven't seen anything like that. Yeah, if anyone knows, I've not seen any real effort to try to convince normal ISPs to implement encrypted DNS. It'd be cool. It'd be great, but a lot of times there's not a direct monetary incentive to do that. Then they're probably happy that they don't have to run DNS servers. Any other questions? I think we're basically out of time. All right, thanks very much.