 Okay, now, for the first talk in the night shift, basically, it's encrypted DNS, the good, bad and ugly of DNS over HTTPS and Sebastian is going to talk about that and all aspects of it. Please give him a warm welcome. Könnte das Licht noch runter drehen? Okay. Hi, I'm Sebastian. Just a small heads up. The subtitle is actually borrowed by Daniel Stanberg. Daniel is the author of Curl. Thanks, Daniel, for your title. I work for German speaking online IT news magazine. Name doesn't matter. Part of my work was going to the IATF meeting. So for those people who don't know, the IATF is the Internet Engineering Task Force. Those are the people who actually work on the protocols that make up the Internet. So, whenever there is an ITF standard, that is what the Internet actually is. At the IATF 99 in Prague, there was a so-called dispatch, so some developer comes up with a new idea and asks the ITF if they want to work on their idea or not. They wanted to work on it. That protocol was called DNS over HTTPS, and it was dispatched in its own working group. So there were people that worked just on that protocol. And I'm going to tell you why they worked on DNS over HTTPS. So I have to actually read this for you, because it's maybe a bit too small for a slide. So in the middle you can see Eric Raskara, he's the CTO of Firefox for Mozilla. So he's doing all the technical bits for Firefox. And he was explaining DOH to some people in the audience, just like I do now. On Twitter somebody then said, the right answer is that everyone should be running a feature-complete caching and forwarding resolver on localhost. All the rest of these discussions are noise from companies that want eyeballs. So for those of you who may not know actually any of those words, you're the actual target audience of DOH. For all the others, well, you may learn something about DNS as well. That's what I'm here for. So in the beginning there was no DNS. As we all know, computers talk to each other via IP. The thing is, how do you map an IP address to an actual machine? Well, it's kind of hard. You all may know that there's an ETC slash host file on your device. Basically any operating system out there has this file. With DNS, that file is actually not necessary, but we still use it. And first host file is like 40 years old. And this was used before the internet actually existed in the ARPANET. So we have a few problems with that. At each node of the ARPANET, they had to manually maintain the host's file. And in order to sync them, they had to phone them. They had to actually send letters to each other in order to sync the names for other IP addresses and computers. That didn't work out quite well. So they ended up with a lot of different names for the same computers, which is basically a clusterfuck and you don't really want this. So 15 years and with the growing ARPANET, they came up with an idea, which we now know as DNS. The basic idea is to automate the mapping of an IP to domain names, or vice versa. So a client asks for an IP of a domain some server answers and gives you the IP address. That's still how DNS resolution now works. So nothing changed in this idea for the last 30 years. So before they actually started on the technical bits, they started working on the idea of how should our system work. Basic idea is you've got a worldwide global hierarchy, where you put all your domain names into it. In order to decentralize servers, thousands of servers that take care of that hierarchy. In order to do this, you need standards. So any single server in that system needs to speak the same language in order for this system to work. It took them like five or six years to actually standardize that kind of system. This was in November 1987 and we still use this system today. This is one of the oldest protocols you still use daily, heavily daily. This is what the hierarchy in your original standard looks like. So you may see there's a top node on it and then you've got a tree. That tree goes into different top level domains, like more than 30 years ago there were not that many TLDs. And then it gets split down. And each branching node may be what you now know as a name server. Or it may not be, but that's the important thing. We've got still this tree hierarchy in DNS today. So how does this work? So let's take a look at events.cc.de for this event. If you want to know the IP address of that domain, you ask root servers, that top node in the tree hierarchy. Okay, which server is responsible for the .de TLD? Then you get an answer. With this, you go a step a little further. In case of the .de TLD, the people responsible for this is the Denig. You may know them. And you ask their servers, okay, who in your zone .de is responsible for ccc.de? You get an answer. And then you do this as well with the name servers from the computer club and you get an answer. Just to give you a picture of how this works, that top node in the hierarchy, the root servers, there are more than 1,000 physical servers out there to work with the daily DNS. Without those servers, nothing at all would work. So as I explained, you traverse the tree top down. But that's not actually how it works. You make it recursive. And at each point in the tree where it's branching, the cache previously seen IP addresses. This is what we call a cached resolving process. If you remember the slide with the treat in the beginning, this may be important for the actual DOH deployment. Then there are stop resolvers. So these asking several different servers and traversing this tree doesn't actually happen on your device. What's happening on your device is called a stop resolver because it actually is not doing anything for real. It still works that way that you ask your stop resolver for an IP address and you get that. But the stop resolver just forwards your request to an actual recursive resolver. The stop resolver gets the actual answer for the IP address. And this is what ends up in your operating system. And what the clients on your OS actually use. So how do they talk to each other? All those thousands of servers will write. Well, as I said, they first came up with the idea of the DNS and then they worked on the technical bits. So RFC 1034 is the idea, the description of how the DNS works. RFC 1035 is the technical bits. How do you work on the wire with that system so they all know and understand what you're actually talking about. One of the most important things is that only a specific name service or authoritative name service for specific parts of the domain like the root service for all the top level domains. And you can split this out. And remember the tree from the hierarchy? You can actually draw circles for each name server in those branches. And this is a DNS zone that's going to be important in the next slides. Each of those zones has so called resource records. They are more or less a database with a lot of info on the actual DNS in them. So domain names, IP addresses, a lot of other different things on how the DNS actually works. Some of them are really, really important like which mail server belongs to a specific domain. Of course you can just run a mail server on ccc.de for example. But this would be a different server than the web server on ccc.de. And you can actually differentiate them on the level of DNS. And you make this with the resource records. Those resource records have an encoding representation. So they are not text files. So whenever you ask your stop resolver or any other resolver as any other DNS server, they are not sending text like an HTTP. They are sending an binary encoded, not an octet encoded message. Each resource record has specifics on how you encode those resource records into an octet. It's all in 1035. So if you ever want to have a week-long project if you're on holidays, you can actually implement this. There are a lot of tutorials to do this. It's not that hard. The C code for CURL to implement RFC 1034 is like 700 lines or so. So it's not that hard. It's doable. And the most important thing for the rest of my talk is all those bits and pieces that are going around in the Internet are done on port 53 and complete in plaintext via UDP. That's why it's now called DO 53, because it's on port 53. Just a few years ago, that was DNS. But DNS has changed. So we had to find a new name for the old-school DNS and the new-school DNS. As I said, it's completely unencrypted. Everything is in plaintext. There is no authentication at all. They never thought, when they made DNS, they never thought that you would have billions of people in the Internet. So whenever you ask a name server, there is no way for you to be sure that you're actually talking to the server you wanted to talk to. So, no authentication at all. So, with this, DNS over port 53 can be tracked. So any man in the middle knows or can know what domains you're asking the IP address for. It can be blocked. Just block port 53 and none of your DNS will ever work. You can manipulate anything that runs over this. So you can just, if you're a man in the middle and there's no authentication, you can just send bogus answers and you can actually redirect requests on DNS over port 53. So I asked the name server of the CCC, but the man in the middle points me to a rogue name server and gives me a different IP address, which works quite easily because there is no authentication at all. It gets uglier. So these kind of non-features are actually used now by people as features. So for the last 30 years a lot of admins got used to be able to do this. So they are now using the unauthenticated bullshit of DNS over port 53 to make what most people call supervision. So they filter out your requests on a block level. High-checking is actually what I find really funny is high-checking, like redirecting you to a different page is used as a feature worldwide in a captive portal. Whenever you enter a public Wi-Fi, you have to accept some terms and conditions. You may have recognized that those kind of portal pages don't come up if you use an HTTPS connection, because if you use HTTPS, the server you want to talk to is actually authenticated, but if the provider of the access point with the name server that you want to talk to tries to redirect you on the captive portal page, there's a mismatch, so you can't access the login page for the public Wi-Fi. That's because they fuck up DNS. Side note, there's actually an ITF Working Group that works on fixing this. So they're working on a protocol to make this work. Google kind of slipped around this. They have just probing URL in Android. Whenever you access a public Wi-Fi, Android probes this public URL and then you get redirected. You can also do this with neverssl.com. Highly recommend. So, as I said, DNS is kind of strange and is used in, well, not that good of ways. In the end of the 1990s, a lot of people saw that the unauthenticated part of DNS is going to be a problem. They came up with what we now know as DNSSEC. DNSSEC stands for Domain Name Systems Security Extensions. The name extensions is because they just add new resource records to the old ones. So it should be compatible to the old standard. The idea is that you sign zones with a key. So each root server zone is signed with a key. And with this, you can traverse the tree in the hierarchy and add signatures to those new zones for any single name server zone. With this, you can actually authenticate the name server you're talking to. So the answer you get from those name server you can trust is temper-proof. Problem is, it's still unencrypted. So whenever you use DNSSEC, people on the wire can still see what you are requesting. They are not able to manipulate your root. They are not able to manipulate the answer. You still get the correct IP address. But do you really want your employer to know that you're serving Pornhub in your free time? Hmm, maybe not. There are other problems with DNSSEC. So it's really, really hard to deploy, it turns out. It's hard to tell how many servers actually use DNSSEC. But current estimate is just between 15 and 20% of all the name servers out there actually use DNSSEC. And they had 20 years of time. So that may not be a viable solution to actually make DNSSEC temper-proof. And as I said, you've got stop resolvers that don't actually use any resolving. But they just refer you to another name server on your operating system. And they would need to validate the signatures. But there are not any actually deployed stop resolvers that do this. So the Microsoft stop resolver in Windows is able to understand that they get DNSSEC signed resource records. But it's just not validated if the signature is actually valid. And this is the case with Linux and BSCs as well. If you're running those operating systems, you can of course validate your DNSSEC signature. But in Germany would then have the problem that, for example, the Fritz Boxes by R4M, Typical Home Router in Germany, use the domain fritz.box. If you use DNSSEC in your home environment on the client devices, you wouldn't be able to resolve fritz.box. Because it's just a bogus domain name. It's out of the actual hierarchy. So there is no signature for it. If you validate signatures, you won't get an answer and you can't access your router anymore. So DNSSEC has problems. Dann, 10 Jahre später, people actually thought, okay, what about encrypting the actual DNS? Like make it all secure and encrypt what we put on the wire. This grew out of the OpenBSC folks. But you may know folks from OpenBSC or have heard how they work. They're not really standard sky. They just implement stuff and see if you think it's secure. Yeah, well we've got a solution. Use our solution. That worked with OpenSSH, but this only worked because some people at IETF actually thought, okay, well we use your implementation for our standard because it's the best. With DNSSEC, it never got any track record. So DNSSEC, DNSCrypt is no IETF standard. Nobody uses this out there. You can go to the DNSCrypt website and download the client, make it work and encrypt the DNS. But if you use this, you can only talk to a really, really few name servers because the name server has to support this as well. So if you're running OpenBSC on your own server somewhere in the network, you can then run DNSCrypt-capable name server. Yeah, that's not going to work on your laptop or think about your grandma. Is she going to do this? So, the IETF got a wake-up call by the Snowden revelations in 2013 and they actually made a standard that says that pervasive monitoring by state actors should be taken like an attack. So anybody working on IETF protocols should implement upcoming protocols in a way that you can't do that kind of pervasive monitoring that the Snowden revelations revealed. And one of the first things the IETF thought about was DNS because DNS was one of the last protocols that at that time was still completely unencrypted. So they really quickly started a working group to solve that. So, DNS Private Exchange, deep drive. Deep drive came up with DNS over TLS. So, we've got this really, really nice encryption protocol, TLS. We've got a lot of really good or really weird implementation for TLS, but any operating system out there supports this. So, why not just encapsulate the DNS traffic in TLS and put it on the wire. So, dann war was verwechselt und nobody can complain. And this kind of works, if you're using DOT it is actually encrypted. Nobody in the middle can see what you are asking in a name server. But the thing is, the traffic can still be monitored because the actual standard says that you must use port 853 just like you must use port 80 for HTTP du kannst noch die Trafik sehen, und mit diesem, wenn du die Trafik sehen, kannst du es analysieren oder blockieren. Das easieste Weg zu blockieren ist, dass du die Porte blockierst und niemand den DNS-Ansatz fragst. Dann war es DNS over HTTPS, DOH. Das war gearbeitet nach DOT. Das war die Idee, dass DOT blockiert werden kann. Die Idee war, wie wir um die Blocking-Feature des DOT arbeiten können. Die basice Idee ist, dass du die DNS-Ansatz-Ansatz-Traffik mit anderen HTTPS mixst. Wenn du HTTPS-Traffik blockierst, würde niemand der Klienten mehr arbeiten. In einem Arbeits-Ansatz-Ansatz kann niemand arbeiten. Wenn du diesen Protokoll benutzt, kannst du nicht den DNS-Ansatz blockieren. Du kannst es nicht tracken, weil es inkrüpt ist. Du kannst es nicht modifizieren, weil du nichts sehen kannst. Du siehst nur HTTPS-Traffik, aber du weißt nicht, was es ist. Als ich an ITF 99 war, war es eine Revelation für mich. Es war eine sehr, sehr tolle und einfache Idee, um den DNS-Ansatz zu krüpten. Ich lieb diese Idee von Anfang an. Es wurde wie ein Jahr ago energisiert. Wie funktioniert das? Wir haben diese Ressource-Rechorte, die in Octodes gepostet sind, die auf UDP und PORT 53 machen. Wir benutzen diese Encoding, wie ein HTTPS-Payload. Du kannst die Request-Ansatz-Ansatz-Traffik benutzen. Wenn du viele Librar-Ansatz-Ansatz-Traffik importest, du musst die DNS-Ansatz-Traffik importen. Dann importest du die HTTPS-Librärie. Dann sagst du dem Klang, dass du eine Request-Ansatz-Traffik machen. Dann kriegst du die Ansatz-Traffik. Es ist 10 oder 15 Autos von Python. Es ist sehr, sehr gut. Es ist sehr, sehr gut. Wenn du ein paar Stunden Zeit hast, dann versuchst du es. Dann kann man die Stimme von Firefox und Chrome, wie jetzt, beinhalten. Sie haben die Implementierung von zwei Stimmen, wie vor einigen Monaten und Jahren. Auf top of that, da sind standalone Clients, wenn du nur mit DOH-Ansatz-Traffik spielen willst. Köln supportet, wie bei 101,5 Jahren. Du kannst DOH und Köln benutzen. Dann ist der HTTPS-Payload, der DOH-Ansatz-Traffik, unterstützt. Wenn du ein Klang bittest, das die DNS-Ansatz-Traffik für die Librärie braucht, dann schaust du die Librärie an. Das ist von der Sendung, RFC 8484. Wir haben einen URL-Templat, wie dnsgravy.example.com. Wir machen eine Request-Ansatz-Traffik mit dem Server. Das ist ein bunch of encoded stuff. In the center, they use base64.url-Encoding, without padding, to make the resource records smaller. You could use all of the actual octets, but that would be just too long and too much. So we use base64. We call this a DNS-Message on HTTPS. Really easy to understand, if you know anything about HTTPS. Just look into the RFC. How does this work on the server side? The code project by Dennis Sandberg provides a list of public DOH servers. If you want to use Firefox or Chrome and try DNS over HTTPS, you can use several different servers. A lot of big commercial DNS providers support DNS over HTTPS. Google, Cloudflare, Quad9 from IBM. Digitaler Gesellschaft Schweiz runs their own DNS server. The DNS server from them supports DOT and DOH. The FreeFunk München runs their DOH server on a specific domain. So if you want to play around with DOH after this talk, take a look in the Wiki. They have a lot of explanation on how to use their FreeFunk DOH server at Congress. And finally, British Telecom is the ISP in the world that is now testing the deployment of DNS over HTTPS. You can use DOH on your own servers, of course. As I showed you, you just need a URL template and pass whatever request you get for this. There is a tutorial for EngineX on how you do this. It's really straightforward. The idea is that you use EngineX as a Resolver. So you take the request, forward this to the Resolver, the Resolver gives you back the resource and then EngineX pushes this back to the client. So if you're running a website, you can put this website into an DOH server. So if you really care about your security, please do this. How does this look on the server side? As I said, we've got this DNS message in 84, 84. And this is, as I said, the actual DNS format on the wire. That's what's standing in the standard. So the server answers with an okay message. You get the content lengths, you get the maximum age of that request. So you can actually cache that request. And you can also use the Hexencoding of the actual DNS answer, which your server actually can use, pass and give you the IP address or whatever you're asking for. Problem is, on the deployment side, outside of the web HTTP sphere, you can't really use DOH with currently available methods. So in my point of view, there is no implementation, no readme, nothing on what they want to do, on how they want to work. They just announced they're going to support the protocol. But so, from my point of view, it's really good. Of course, no other OS level Resolver has this on their agenda. None. System defaults implemented DOT, so you can use the TLS certificate. So you can just ... Yeah, it just doesn't work. Why use TLS if you don't validate the certificate? So there, in a point of the operating system, you basically can't use DOH, as of now. If you're running a kind of commercial nameserver yourself, you may know DNSdust. supports DOH, this actually supports DOH without TLS, so you can play around with all the encryption without validating a certificate if you just want to look at what is actually happening. And then there's BIND, BIND is the most widely used DNS server in the world, BIND was co-developed with the actual DNS standard, they pride themselves for actually supporting anything that is happening within DNS, but they just waited and waited and waited and waited and didn't do anything on DOH, because none of their clients would pay for the development. Finally just a few months ago the ISC announced that Mozilla is going to pay for the DOH support in BIND, so after that even your ISP that runs BIND may be able to support DOH without any trouble, they just need to upgrade their BIND. So current state of the available client situation on DOH. With Chrome and the maybe upcoming Windows 10 implementation, you can use DOH and it's used automatically if your predefined DNS server also uses DOH. So let's say you've got Google 8888 as your DNS server, if you do this they kind of guess that you want to use DOH if you're using Chrome and then they just transparently upgrade you to DOH and you're going to use this. This works with a bunch of other servers, like eight or nine different providers in Chrome. We don't know what Microsoft is going to do with Windows 10, but they said they want to do this as well. Firefox defaults to using DNS over HTTPS in the US. Unfortunately this got a lot of heated discussion because they use a predefined server in Firefox, so whenever you're going to install a new Firefox with the US English location, you're going to use Cloudflare as your DOH server provider. And as of a few weeks ago Firefox also supports a next DNS, which is also a new upcoming commercial DNS provider in the US. As I said, this only happens if you're running the US international location of Firefox. So just a short recap, why should we use DOH? As I said, it's encrypted and standard compliant encrypted, not like DNS script. Typically DOH servers are faster than normal Nameservers. That's because we use HTTP. For the last 25 years, HTTP was optimized in pushing content fast. That never happened with DNS because, well, just wait for an UDP packet, and if it not arrives, just send a new one. HTTP never worked that way, and thousands of engineers worked on making HTTP faster. That's why DOH is most of the time faster than DNS. You can reuse load balancers, you can reuse caching infrastructure, you can reuse a CDN. On top of that, we typically use HTTP2 for DOH, and then you get multiplexing and a server push. So you actually get your answers faster by design. The bad thing is, there are not that many DNS servers out there, so there may be a centralization, which runs against the actual goal of making DNS decentralized, which may be a problem. The standard actually says that you can use HTTPS for a lot of different monitoring, and as Snowden revelations showed us, this is also used. So you can infer a lot of specifics on the HTTPS traffic, even if it's encrypted, which is stuff that you may not want to do. Then there are deployment problems. You may have internal and external networks. If you deploy a DNS in your company, you may have specific domains that are just known inside your company, and are just resolved inside your company. Typically you would just announce your own name server via DHCP, and this own name server would resolve your own made-up domain. With DOH, it won't work, because it's encrypted on a different channel, on a different Port, and the clients of your users will never get this name server, which is a deployment problem, especially in enterprises. And then there's a problem on how do I actually get to a DOH server, because I need a domain for my DNS server in order to resolve domains. Isn't that a bit weird? The ACTI parts of DOH, so OpenBSC, a community that prides themselves with working for security and invented DNS-Crypt, they deactivated DOH in their Firefox Implementation, because they just don't like Mozilla, or I don't know, they maybe don't like security features. I don't know, they just didn't want DOH, which is kind of stupid in my opinion. The ISPs in the UK called Mozilla an Internet-Villain, because they are deploying DOH. Who is going to fuck up the Internet? Of course it's going to be Mozilla. Are you kidding me? The same kind of same FUD happened in the US. A lot of ISPs and their lobbying companies actually wrote letters to Congress that the deployment of DOH is going to be an anti-competitive behavior. But how is your ISP in competition with your browser? Okay, so this works in that way, that they think that if Google in Chrome ever uses their Google DNS-Service, the ISPs will never be able to send you advertisements over DNS or hijack your DNS in order to send you advertisements. So they are then now competing with Google on ad space, and that would be anti-competitive. I've asked, as my day job as journalist asked ISPs in Germany, how they're going to solve this. I really didn't get any answer. They just don't care, they just wait, because, well, we're in Germany and digitalization just needs time. Well, the most liked answer for me was from Deutsche Telekom. They said DOH is bad for data ownership, but if I encrypt my DNS and I choose my own name server, how is that bad for data ownership? Ah, it may be bad for the data ownership of Deutsche Telekom that sells those data. They said also that browser makers flip over the production model of the Internet. According to that, the production model is selling user data. It's your ISP, that's the most used ISP in Germany. You're not paying them to actually get Internet, you're paying them to sell your data. That's kind of weird. And they also said, if you use DOH in a browser, then the browser makers will see, well, the traffic of the browser. Isn't that the kind of thing a browser does? Sending traffic back and forth? I really didn't get what they want to tell me. And then there is a lot of stuff on DOH that is just plain out nonsense out there. A famous German blocker that has said that DOH uses JSON and he published this without any, well, knowledge on the protocol. And as I said, it was standardized. You just have to look into the standard and it says we're using HTTP in the specific context that I explained. There is no JSON, you don't need JSON parsers, your DNS request will not fail just because you have a space more or less. Then there was a case where a malware resolved their domain name for the command and control server via an HTTPS connection. They didn't use the standard for this, but a lot of media said that malware uses DOH and that's why DOH is bad. But how many malware examples out there using AES encryption? Is AES bad because malware uses this? It's a nonsense argument. Then there was a talk this year by Paul Wixey who wrote a lot of stuff in mind and who really, really knows DNS. And he compared Google to the East India Company because they're using DOH. I don't know if you know the East India Company, but for like 250 years there was state actor inside the British government taking part in slave trade, opium wars, like horrible, horrible stuff and war crimes, and they're comparing Google to this. I don't know if that's actually a good argument. And then there's one by Bert Hubert, who actually is working for PowerDNS, who produce DNS-DIST. And he says that DOH violates net neutrality. So if you as a user choose your own name server with a specific protocol that violates net neutrality. I still don't understand the argument. He says that the name server in the old school DNS is with the request able to get you faster routes on their back end. So if the old school name server of the ISP runs in the Akamai CDN and you're now using Cloudflare as your resolver, Akamai can't give you a faster route anymore and that's why it's against net neutrality. I think that guy has not really a good understanding of what net neutrality actually is and how that should work. And then there's a lot of shaming of Mozilla. I mean, as I said before, of course Mozilla is going to fuck up the internet because we all know that company has no track record at all. Sorry, that was sarcastic. The same goes for Cloudflare. Of course Cloudflare is not an honest or good company. But Mozilla thought about this. I'm going to come to this. And there are a lot of arguments that if you centralise DNS on Cloudflare, intelligence agency will be getting all your data. According to the Snowden revelations, they went, the intelligence agency went to the internet exchanges and deployed man in the middle attacks, the pervasive monitoring because it was easier than coming up with code orders for each single individual company that runs a specific internet service. So even if they come up with a code order and go to your ISP and want to get your data, it's still way, way harder than the pervasive monitoring at the internet exchange because there is no man in the middle attack possible with DOH. And then there's arguments that opt out as bad because why would you ever trust a company with choices you don't know about. The target audience for DOH is not you in the audience. If you made it here, you know how DNS works. Target audience for DOH is your grandma that doesn't know anything about domain names. And then again, there was this quote by a famous German blogger. Mozilla is waging a war against the users because you can't trust a company like Mozilla. What fucking stupidity. So just remember the goal of DOH. We want encrypted DNS. We want this for all and not just for a few people who are able to actually encrypt their data and make specific configurations on their operating system. We want to make pervasive monitoring harder on a protocol level so that any user out there that is using the internet can rely on encrypted data because we all want better privacy. So how is DOH doing this? You can make an informed choice at the client level. So you as a user can choose to choose the path of encrypted DNS and privacy. It's really, really easy to configure. And as I said, there is no man in the middle attacks possible anymore. So from my point of view, the only way to actually deploy this in the wild to the billions of users is to make that opt out the only way. So if you don't like DNS over HTTPS, you can just disable it. But browser vendors, operating system vendors, anybody out there that's working on clients that use DNS, need, in my opinion, need to deploy DOHS default. Otherwise, we will never get encrypted DNS out there. Because as we've seen with DNS script, nobody cares at all if they have to do it themselves. So companies have to do this for their users. Mozilla, as I said, gets a lot of bad shit, crazy arguments that they are cooperating with CloudFair. They thought about this. There's a public policy on the contract with CloudFair. What is CloudFair allowed to do with the DNS data? They're not allowed to personalize any of this data. They're not allowed to sell this data. They're not allowed to make a shitload of stuff. And they have to delete those log files after 24 hours. So even if a state actor, like an intelligence agency, runs into CloudFair name servers, their cannery will die. We will all know about this. And then you can just switch to a different name server. And they will end up with nothing. So from my point of view, Mozilla is making a really good example on how a company that's working on a client is able to deploy encrypted traffic for their users. They call this trusted recursive resolver program because it's a recursive resolver built into the client that Mozilla trusts. They started doing this for the US, as I said. They're going to deploy this worldwide. That's what they said they want to do. From what I've got, they are not that many ISPs that want to cooperate with Mozilla on that. And there's a lot of, well, ISPs that say they specifically don't want DOH. From my point of view, whenever an ISP says that they don't want DOH, it's because they use DNS hijacking as a feature. So they're working against you as a user. So please ask your ISP if they want to deploy DOH and if they want to take part in the trusted recursive resolver program of Firefox. Apart from that, there are ISPs that will use DOH, at least test or deploy DOH now, as British Telecom. So this is going to be way more in the distant future. We're going to have Chrome and Windows on DOH as default, I guess. And finally, your OS will be able to resolve a name via DOH. And then we end up with encrypted DNS for all. Yay! For all the technical problems, they're working groups now at IATF. So we're going to solve the split-horizont problem. We're going to solve the discovery problem. There are drafts to make an announcement of a DOH server via DHCP. So the engineers are working on it. And then there's still Quik and HTTP coming up. So even if you don't want to use HTTP or HTTPS for DNS, the thing that the IATF is standardizing after HTTP 3, which runs over Quik, is going to be DNS over Quik. Quik is a new transport protocol. It's completely encrypted and, well, kind of, is used as a mixture in between TCP and UDP, but better, faster and encrypted. Yeah, I wanted to think about an outcome for next year. Somebody beat me on Twitter to it, so next year will be the year of DOH. Now it's time for questions, if you have any. Well, actually, we'd have to make that singular, except you're fast. You're very fast out on the microphone over there. There's another microphone there. So go ahead. Yeah, thank you. You said encrypt all DNS over HTTPS encrypt only traffic from Resolver to the Stopper Resolver, because from Cloudflare to the DNS server, everything is unencrypted like before. Well, yeah, so that's what we care about in the IATF pervasive monitoring. So we know the client traffic is actually monitored at the basics, for example, and we want to stop this, and we want to stop man in the middle attacks. If you're running your own name server and you want to run Resolver on your own name server, just use DOT, they're not going to block this. This is going to be, DOH can't be blocked in a client kind of sense. The name server communication in between name servers is not part of the idea of DOH. Okay. Well, unfortunately, that's it. We are out of time, even though the Internet and the Signal Angels still have questions and there are a lot more questions in the room. I'm going to be around if you still have questions. Maybe you can take your discussion someplace. Thank you and applause.