 OK, everybody, welcome here for the next lecture. Our speaker here is Karsten Strodman, and he is really infected by a DNS virus already since 30 years. He can't get rid of it, it seems. So I don't know, can you give it to me as well, you think? You might have it. Oh, my god. So rescue us, please. Thank you. Hello, hello, hello. So the question is, do or don't? I want to talk about the difficult suspect of DNS privacy and discussion around that. So we talk about DNS privacy, what that is, why that is needed, the different new technologies like DOH, DOT, DOQ. I will cover that in details. And then the dilemma with these privacy-enhancing technologies and DNS enhancements and a summary at the end. So I'm a self-employed internet nerd doing DNS and DNS SICK and sometimes IPv6. If time permits, go to RIPE and ITF meetings. But I'm not at all employed with any of the big browser vendors. So I'm not from Mozilla, I'm not from Google. I just talk here about stuff that I have heard, either officially or unofficially in some talks there. But please, please, I'm just a messenger. Please shoot me. Please don't shoot me about what you're doing. So over the last few years, the ITF, which is the body of the people who design internet protocols, they expanded the DNS to enhance the privacy of the domain name system, the system that we use to or our computers use to get IP addresses from domain names and other important data they need. And even though there is more than just the transport protocols, in this talk, I will only talk about the transport protocols being DNS over TLS, DNS over HTPers, and DNS over Qwik. So why do we need more DNS privacy? A recent study presented at the ITF meeting in Montreal in July last month showed that on a total scale on the whole internet, 8.5% of networks intercept DNS traffic. So they capture the queries, and they don't let the packet go out to the real intended DNS server. Instead, they redirect the packet and answer that DNS question locally. And in China, it's more than 27% of all DNS traffic being intercepted. Now, careers, today, it's the fact that the most queries are just answered as if the query was not intercepted. So the users still get the correct answer. It's just coming from a different server. But that can change, of course. And maybe today, it's mostly surveillance, looking what people are querying in the internet. But that infrastructure can also be used to change data and change answers. And that is the reason why we need encryption in the DNS. So there are new abbreviations, new terminology for all the new technologies. We have DO53, which is the traditional DNS, which is DNS over port 53, UDP and TCP. That's the old stuff that has been around since 1983. Then we have DOT, which is DNS over TLS. I will cover that in a diesel in a moment. Then DOH, which is DNS over HTTPS, port 443. We have DOQ, which is DNS over Qwik, which is something that we will see in the future. And I cover that in a moment. And then we have DOC, which is DNS over cloud, which means DNS not resolving locally, but through some internet service, Cloudflare, Google, Quad9, or similar stuff. So first, DOT. It's DNS over TLS. It has an RFC. It's a few years old. And it encapsulates the normal DNS just over TCP and TLS, which is the same transport encryption that we use for the web, but on a different port. It's port 853. And it gives us encryption and authentication. And either we authenticate the other endpoint through a certificate, like we do that in the web. Or we can use Dain, which is a way to validate certificates over DNS and DNSSEC. Both is possible. But most people today use the internet PKI. This is how normal DNS works. Sorry, there's some German still in the slides. The client on the right side sends the query to some local resolver, which is either in your own network or in your ISPs network. That one looks in the cache. If the answer is not in the cache, it goes out and asks a couple of authoritative servers. They collect the answers and the answers being sent back to the client. And all that goes completely unencrypted and not authenticated, meaning the client will not get any information if that data is being intercepted or played with or just exchanged. The client just doesn't know. It gets an answer, and it takes that answer for the truth, which might not be the truth. So with DNS over TLS, this is the situation we have today. It could be that DNS over TLS would go to a local resolver, but I haven't seen that anywhere so far. So what we see is that the client is being reconfigured to do DNS over TLS to some service in the internet, which is not local to the network. That can either be Google or Cloudflare, these big vendors that have DOT services, or they can be privacy organizations like Digital Courage here in Germany, or others that operate DOT servers. It's also possible, but I seldom see that to do forwarding. So if you have a local DNS resolver in your network and the communication between your clients and that local DNS resolver does not need to be secured because it's your network and you have control over it, but you want to do forwarding, like not resolve yourself into the internet, then you can secure the forwarding path to the ISP resolver or to any other DOT service in the internet. DNS over TLS can be operated in two different modes. One is the opportunistic mode, meaning we check whether we can authenticate the endpoint on the other side. And if that works out, all good. But if it that not works out, we will still use it. So this is very similar to how TLS is being used in the mail world, where all the certificates on the other side are not really checked and verified. It's just used for encryption. Or you can configure your DOT client in a strict mode, and then authentication must happen. And if there's a failure in authentication, no data will be sent, meaning the internet is kaput if authentication doesn't work. There are a couple of operators, big and smaller ones. Here are a few that you can choose from. There are many, many, many more. Then we have the other, the big brother of DOT. It's DOH, it's DNS over HTTPS. And that is RC84-84 from November last year. And it encapsulates a DNS, as we know in the past, encapsulates that over TCP and HTTPS. It sends it over port 443. And the idea here is that an outsider looking at the data stream could not distinguish normal web traffic from DNS traffic that is DOH. And it gives us encryption and authentication, which is the same as with DOT. But it also gives us cloaking. And cloaking here means that we hide the DNS data in web traffic. And the idea here, it's much harder to send it to stop the DNS traffic if it is intermingled into the normal web traffic going over port 443. This is how it could look like. The client will send a query actually to a web server on port 443. That web server will detect that this is a DOH DNS query, will de-capsulate that into normal DNS, and will send that query to a DNS caching resolver. And that talks then to the authoritative servers. And that is then normal DNS. Just the pink transport line here is encrypted and authenticated. I'm now observing the ITF for more than 20 years. And the process of getting DOH into an RFC was one of the fastest I've ever seen. Normally, it takes five or six years from the first idea to having an internet RFC, because the ITF is built on rough consensus. So you need to first discuss a lot of stuff with the people until you have consensus and you have running code. With DOH, the first idea, the start of the working group, was in November 2017. In March 2018, the draft was ready. The RFC text was complete. And they started the working group last call. And working group last call is basically like in a church when there's a wedding, asking, is there anyone objecting against this? And if nobody calls out either in the meeting or in the mailing list, it becomes an RFC. And that happened in October 2018. That was under one year from first idea and inception of the working group to getting an RFC out. So that was remarkable. And that shows the forces that are behind this idea, behind DOH, mainly from the big browser vendors, because they want to have that happens. And so we were seeing why this is. There's an interesting quote in that RFC, saying that filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS, meaning that all the devices that look for security incidents in the network by looking at the DNS, but looking at unencrypted DNS will not work anymore. And that scares a lot of administrators in networks that have, of course, good intentions because they want to keep their network secure. But their devices, which were quite expensive when they bought it, they won't work anymore in this. And so some people fight DOH because of this, other fight DOH because of other means, but keep that in mind. So the DOH first appeared in Firefox as a browser in Firefox 61 that was in May of 2018. And initially there was just a manual switching about colon config, so you had to be a nerd to find this out. But in the newer Firefox Quantum, this is a screenshot from Firefox 68, which is the current one, I think. You just go into the proxy settings and you scroll all to the end, and then you can checkmark enable DNS over HTTPS, and then you can either select today Cloudflare as one provider being in there, or you can select your own value and put the server name in there. And this DOH default routes these just my server. So what happened here, or what are Mozilla's plans? Mozilla gave a talk at ITF 105 last month, and they plan to enable DOH in Firefox by default at some point of time in the future, but there's no date set. Reason for that is that they still figure out how they can enable that without breaking a lot of configurations in enterprise environments. Because the problem with enterprise environments is that they often have their local DNS base, DNS names that are not registered anywhere in the internet, which are just locally to the resolver there. And if the Firefox browser would switch to DOH and use any DOH service in the internet, of course, that would not know about the names used in that company environment. So the users will not be able to find the local Jira wiki or something like that. And that is bad, of course, a bad user experience, and Mozilla tries to avoid that. So they have to figure out a solution for that. But once they have figured that out, their plan is to switch DOH on for everyone. It will not be Cloudflare everywhere. So some people fear that Mozilla will just switch on DOH in Firefox and everything will go to Cloudflare. That is not the plan. Instead, Mozilla is working with local providers of DOH services, and they certify local provider, and they will provide a list of operators of DOH service in Firefox, and they will select for every region, one of them, to be the default. So it might be then that for Germany as a region or for the German speaking region, that there will be some provider, hopefully one that we mostly can trust, that will be then the default in Firefox, but in there. Mozilla has published the requirements of being certified and the link is in here, you can read that. Also, if you want to operate your own DOH server and you want to be listed in Mozilla or Firefox, you have to check these requirements and then you can request your service to be listed in there. Chrome. There is a DOH in Chrome currently, but it can only be enabled with a command line switch. And there's a link how to do that. The Google team has announced that they plan to have a GUI configuration part in Chrome 78, which is one or two versions in the future, but they don't have any plans to switch on DOH by default. So it will always be for Chrome an optional setting to do. Here's a list of DOH operators. And yeah. So what is the difference between DOT and DOH? DOT can be easily blocked because it's running on a dedicated port and especially in certain markets where DNS interception is very often done, like in Asian markets, like in Indonesia, the people there, the users, they only have actually two ports that they can use for DNS name resolution. It's port 53 UDP and only that and only to the local ISP. And that one is filtering and is maybe intercepting traffic and it's maybe even changing traffic. And it's port 443. Nothing else is open there. And of course, the operators will not change that. They will not open port 853 for privacy because they don't want privacy and also the governments might not want privacy there. DOH is made to look like normal HTTPS traffic. So the idea is that selective blocking of only DOH is very difficult. And blocking all port 443 or web traffic is impossible for an ISP. That's the idea behind DOH. So it's of course a mass, it's a protocol mass to have DNS over port 443 in HTTPS. It's true and it's a nightmare for every engineer. But it seems to be that if we want to have a privacy-enabled internet, we can't rely on a good structured internet hierarchy anymore. We have to look for loopholes where we can sneak the privacy in. Also DOH is very easy to implement because it's based on HTTPS and most programmers nowadays know how to do that. More of those than doing BSD socket programming. And DOH also enables developers to do name resolution on the application level. Of course, that scares a lot of people having DNS resolution on the application level because that would mean that every application can have its own DNS resolution pass and different applications can get different answers for the same question. And that is a nightmare to troubleshoot. But it's getting even better later on. So there's a dilemma with DOH. To reach the internet users that are really in need of privacy and this is not we in the Western world, it's not we in Europe, we have quite good privacy laws in Europe. But in the US, in Asia, there are a lot of networks where getting privacy access to the internet is very, very hard. And for these people, we need to have a solution. And how Mozilla looks like is they say, we have to find a default. We have to turn it on by default because if we make it an optional configuration somewhere, it's only the nerds that will switch it on. It's only the people here at camp that know how to switch it on. And these people don't need it because they know how to protect themselves. They know about privacy. We need to have a solution that works for 99% of the rest of the internet population. And for them, you can't explain the problem. You have to get some default in there. And Mozilla says this is very similar to the certificate authority selection in the browsers. So the people we trust with the certificates, they are also provided by the browser. So also, let's us put in a vetted list of DOH providers in the browser. That still might lead to some centralization of DNS queries. And that is, of course, bad because centralization creates a point where data can be collected and being analyzed. That's bad. So there's a dilemma. We can't have one without the other. So we can't have 100% good solution. We have to fight and we have to discuss a middle ground. And the discussion is not over and we can still participate in this discussion. So then I looked at DOH and whether that is only in the browser space because sometimes people who fight DOH tell me that, okay, this is something the browser vendors want to push on the internet people and nobody wants that really. It's just the browser people that wants it. So I looked at the landscape of software that is on GitLab and GitHub to see, is it only the browsers or are there other projects that use DOT or DOH? And I did that in May and July this year. And I looked only at genuine software products, not of composing products, not something that just wraps with a Docker container some existing software, but new software that implements either DOH or DOT. And you can find the list of implementation there, currently 55 implementations I list there. Interesting is the implementation languages of all the stuff that's being newly implemented, Go. The Go programming language has superseded C and C++ which is still second, but the most new stuff is done in Go. I would say most new projects are done in Go and the C projects are existing DNS software that had now DOH bolted on. Some is in JavaScript, some is in Python, Rust and Java, and then we have a longer tail of the usual suspects of other programming languages. There's much more DOH than DOT. We have 41 projects of 55 that implement DOH and we have 23 that implement DOT, some implement both. The project start, that's interesting. So in 2015 is the year when DOT was first announced and there were just a very few project there and it really spiked last year, the year when the DOH RC was published. We have 29 new projects last year and we have 13 projects this year and I think that we will reach a very similar 20-something number at the end of the year because every month I look for new stuff and five or six or seven new projects appear there. Then I looked at the freshness, whether these are just one-shot projects that are published on GitHub and left there to die or are there active projects? Are there issues in the bug tracker that being worked on? Is there a new commit on the code? And most projects of 45 or 55 are active and 11 are dormant on that and nothing happens there. Here's some applications that have DOH or DOT, it's Firefox and Chrome, a curl on the command line has a tender browser and bromide are two browsers in the mobile space and on Android that have that implemented. On the operating system side, SystemD ResolveD on Linux has it, but not on by default, you have to enable it on default for DOT. Unwind is a new system resolver for OpenBSD that shipped first time with OpenBSD 6.5 in April this year and that has DOT built in and there's a resolver module for Libc. That is a proof of concept state, but it could be expanded on and that would give DOT or DOH to all applications. Now, there's a lot of client proxies, I won't cover them all of them, but you find the links on the implementation page and server proxies as well. And there are DNS servers that no implement DOH and DOT directly like Unbound, Not and also the SDNS software. So what I found missing in the DOH DOT software is certificate authentication via Dane. They usually authenticate via the certificate store of the operating systems, but having authentication via Dane would be even stronger having that. A witness function would be nice, meaning that a query received from a client would be sent to multiple operators, multiple servers in the internet and then we wait for two or three answers coming back and then we compare the answers. And if they don't match up, we take a majority vote. So if just one operator plays foul and changes the DNS data, such a software will detect that and then we'll go with the answer the most DNS service provide. Of course, it will slow down DNS. So there should be a switch somewhere for the user to decide whether the user wants to have a secure and private or a fast internet. And of course, all the new software, there's almost, I haven't seen any security audits. So, and it's all new stuff there. There's probably a tons of security bugs in there still and there would be a need of doing some software security audit for these new softwares. So what's in the future? We have DNS of a Quik. Now Quik is a new protocol that has been developed inside Google and is now at the ITF for standardization. It is to be replacing TCP. It's based on UDP, but it has TCP functionality built in. It's already in Chrome and it's already on the Google server side. So if you have used Chrome with the Google search page or YouTube in the last three years, you have used Quik because if you have Chrome and you contact some of the Google services and especially YouTube, the browser will automatically detect that this website is Quik enabled and it will switch over and not use TCP. It will use Quik. The reason why Google developed Quik is because TCP is ossified, meaning it's impossible to change TCP because there are so many middle boxes, firewalls, intrusion detection systems that make certain assumptions how TCP works. And if you change TCP as a protocol, these middle boxes will break. And it's impossible to change all the middle boxes or just even get the vendors and the users aware of this problem. So we are in a state that TCP cannot be changed anymore. It cannot be made better even though there are ideas to make TCP better. So the route that Google goes is to create a new protocol that works on UDP because UDP is not a problem. You can make any changes to UDP or on top of UDP and it usually just goes transparent to the firewalls. And of course, with this new protocol, there's an idea to have also DNS over this new Quik protocol. Yeah, Quik has TLS 1.3 built in. It has zero runtime encryption, resumption and all this. All that we have in TLS 1.3 is also in Quik and there's currently discussion on the ITF how to standardize DNS over Quik. And it would look same as DOH or DOT just with the different transport protocol, but not sure if I have that here. Yeah, Quik is, the idea of Quik is that Quik is not built into operating systems like the TCP IP stack, but it's built in the applications like it is in Chrome today. So it is a new network stack that is in the applications. So if you are feared of having DOH and having all applications doing different DNS name resolution with Quik, all applications will have a different TCP IP stack basically and talk differently to the outside world. And that will be troubleshooting nightmare, but we'll see how that ends. So here's a comparison of DNS over TLS and Quik and traditional TCP by the person by Christian Hoitema who wrote the draft to the Quik implementation for DNS. And of course, Quik comes out the best on the right side. It has all the nice properties that one wants. So I'm always coming to the end of this talk. We see that the DNS is involving fast these days. There's many, many changes to the DNS protocol. Not only the new transport protocol, but much more like a DNS padding and QNAME minimization. And for some people it's too fast. Bert Hubbard from PowerDNS wrote this article, the DNS camel. And he basically says that the DNS is like a camel. And if we put too much stuff on it, it will break and not work anymore, which is true. So the internet and especially the DNS community are currently working on also deprecating some old behaviors of DNS to be able to rip out unused stuff out of the DNS software. But I'm very certain that the future of DNS communication will be encrypted. It will either be DOT, it will DOH or it will DOQ. If I had to make a guess, I would say it's DOH. And it will be DOH and there's nothing we can much do about it. We can only maybe shape the way how it is implemented, but we can't avoid that, we can't stop that anymore. I see that DOH or DOQ have both the potential of centralization or decentralization. It really depends on the software or and how much operators are there of these DOH and DOQ servers. If nobody but the big vendors are implementing this, of course there will be centralization. If a lot of ISPs, if a lot of privacy organizations, if a lot of private people implement DOH and DOC servers and make them public and operate them in a responsible way, we can have even a better internet and a decentralized internet by having that. The software is there, the protocols are there, the protocols are neutral. The protocols don't demand how it's implemented. Of course, if DOH is implemented and all data is being sent to one operator, that's bad. But if we have a lot of DOH servers out there and users can choose, and maybe the software is even intelligent to choose for the user, then it could have a decentralization effect and that would be good. What can we do? We can start operating a DOH and DOT server. It's not rocket science, quite easy. Software is there, software is mature. We can use that. We can hack on the DOH and DOT server. Maybe do security audits. Maybe implement a witness function that is currently not there. Maybe implement Dane authentication of certificates. We can work on, if we work on operating systems like Linux or the PSDs or Haiku or any alumnus or something like that, we can try to bring these new technologies into these operating systems. We can't avoid them. Don't try to say, oh, I want my old DNS and I won't do this new stuff. It's already decided, I guess. It's nothing we can do about it. But if we... If we implement that in the operating systems, we can give the users a choice and maybe a sane choice there. Please engage with the ITF. Don't just criticize the ITF of the RFCs they make. The ITF and the RFC process is open. Everyone can participate. There's no membership fee. If you can't travel to the meetings, there is remote participation. You just need your time. Listen to the talks and you can use Jabba Chat to ask questions or bring in your input there. That is much appreciated. The ITF needs more people from the base, from the ground to bring input there. Because if we don't do that, it's the big people from the big corporations that steer the internet protocols. And that is maybe not in the best interest of the people using the internet. And independent from this talk, deploy DNSSEC because DNSSEC makes DNS more secure. So I thank you for listening. And I hope we have a few... Thank you. We might have a few minutes for a question and answer. And if you want to have more discussion on the topic, the nice people at Digital Courage who operate a DOT server, they allow you to use the Internet. If you are interested in the topic of DOT and DNS privacy, you can meet me and other people over at Digital Courage around 6 o'clock, or a little bit later. 6 ish, yes. Okay, thank you, Karsten. Are there questions here in our audience, please? Yes, there. Thank you, Karsten. Thank you very much. Thank you. Thank you to our audience, please. Yes, there. Can someone with the mic go there? Oops, be careful. Phones and bottles. You mentioned the possibility between centralization or decentralization that this project could bring. So one question I had here is, are there any plans for making sure that authoritative DNS servers, name servers run one variation of those secured resolution protocols? Because if we want a real decentralized service, what we want is for me at home to be able to run my own recursive DNS over HTTP resolution scheme, even though I am behind an ISP that blocks the pirate ban, that sort of thing, which means to be able to do that locally, I need to be able to reach all the authoritative name servers over the HTTPS to make that work. Are there any plans for this that you know of? Yes, the DNS Privacy Working Group in the ITF is currently exactly working on that. They are looking into a protocol extension for DOT and DOH between the resolver and the authoritative servers. It's still work in progress. It's not there. There is no concept implementation in software already, but this is the second step. Securing the pass between client and resolver was the first step, and this is what we have today. That is mature. We have the RCS. And the second step, securing resolver to authoritative communication that is currently being worked on. Excellent. Thanks. I see a question here in the front. What is any of this new security worth and no protection from downgrade attacks? It always falls back and there's no way to know if there's supposed to be an encrypted channel to this DNS server. What has truly gained in the face of an active attacker? Most of these software have two modes. One is the operaticistic and one is the strict mode. The operaticistic mode has a downgrade possibility. It falls back. Either it falls back to unauthenticated TLS or even it falls back to classic DNS. But most software you can configure in strict mode and then it will not be downgradable. It will just fail if the encrypted and authenticated transport is not available. Okay, so more questions here. Sir? Yeah, thank you for the talk. Just a quick question about the DNS inside application. What are your thoughts on why corporations are doing this? Is it just because it's simpler because they own the software that implements it right now? Or do you think they have maybe nefarious thoughts or plans? I can't look into people's heads. I trust Mozilla in so far. I've talked with certain people from Mozilla who are frustrated with DOT and the process of DOT being implemented in the world. The DOT RFC is now three or four years old and it has not seen wide adoption. That was one of the reasons why Mozilla worked on DOH because then they have control over the client side and they don't have to wait for the operating system vendors to see what's going on in the world. So I think that DOT is usually something that you have in your operating system. Of course, others might have other plans. And I see, especially in the mobile space, which is the majority of Internet users today, I fear that we have different apps in the mobile space that all have their same, all have different DNS number solutions and their DNS resolver there because then they can analyze the traffic and get stuff out of that for whatever reason. And that is not what we want. Okay, see you soon. What about the initial hostname of the DOH or DOT server? How is that getting resolved to an IP address? And isn't that a point where censorship could already start to not letting people know where they can get DNS over HTTPS or TLS? Yes, so first, how is this resolved? How is the first step? The name of the DOT or DOH server is resolved. It depends on the software. Some have some hard-coded bootstrap server, other use just traditional DNS for that, about the way how to, if that would be an angle to intercept and subvert the whole scheme, no, because of course someone could intercept this first query and give a different IP address for the name, but then the certificate wouldn't match. So if you have a strict mode where you really check the certificate of the other endpoint, unless the attacker has the ability to fake a TLS certificate, it wouldn't work. Great. Of course, there's a problem. That's why I say we should have software that relies on Dain and not on the public infrastructure of the internet with the certification authorities because that is a completely different problem space and yes, it's not perfect. Okay, this gentleman. Hello, thanks for the talk. I'm wondering, as long as we don't have encrypted server name indication, a lot of the privacy benefits are lost again in the next, in the follow-up request after the DNS lookup. Yes, that's true, but encrypted is an eyes being worked on. Are you familiar with the plans of the browser vendors regarding encrypted server name indication? Not so deeply as other people. I'm more DNS person, but I've just talked to someone today who's more in that space and he told me that this is currently actively worked on. I can't give a date when that will be there, but posts of all the big vendors, Apple, Google, with Chrome and Mozilla are pushing that forward. I suggest to have one more, one last question here since we have to close. And are there already possible solutions for the split view DNS problem you mentioned? I understand the question is correct. Are there possible solutions for the split DNS problem? Yes. Probably yes, I haven't really looked into that, but what you can do is you can send certain queries to the system resolver that your operating system has to figure out whether there is some specific namespace, but I'm not in the details of that. And this is still an open question and still something to be researched. It's the reason why Mozilla hasn't turned on DOH by default because they haven't figured out a good way to do this. It's still researching on that. But this is a problem that needs to be solved. Great Carson, you... Well, I got the virus as well now. I think some other people here got the DNS virus. Thank you, Carson.