Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!

Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles.
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!

========================================================================




OK, now for the first talk in the nightshift, basically it's encrypted DMs, the 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. Consider at least not one that's. OK. Hi, I'm Sebastian. Um, just a small heads up the subtitles actually borrowed by Daniel Steinberg. Daniel, so I thought, cool. Um, thanks, Daniel, for your title. Um, I work for Benjamin speaking online at news magazine. Name doesn't matter. Um, part of my work was going to the IETF meeting. So for those people who don't know, the IETF is the Internet Engineering Task Force. Those are the people who actually work on the protocols that make up the internet. So whenever there's an IETF standard, um, that is what the internet actually is at the ATF. Ninety nine and Prague, um, there was a so-called dispatch, so some developer comes up with a new idea and asked the IETF if they want to work on their idea or not. Um, they wanted to work on it. And that protocol was called DNS over. Yes, and it was dispatched and its own working group. So there were people that worked just on that protocol, and I'm gonna tell you why they worked on DNS over. Yes. Um, so I have to actually read this for you because it's maybe a bit too small for slides. So in the middle, you can see Eric Restera. He's the CTO of Firefox for Mozilla. So he's doing all the technical bits for Firefox. And he was explaining, uh, Deveau h to some people in an audience, just like I do now, I'm 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 and noise from companies that want eyeballs. Um yeah. So for those of you who may not know actually any of those words, you're the actual target audience of the O-H for all the others. While you may learn something about DNS as well, um, that's what I'm here for. Um, so in the beginning there w
as no DNS. Um, as we all know, computers talk to each other by IP. The thing is, um, how do you map an IP address to an excellent machine? Well, it's kind of hard. You all may know that there's an ETSI slash hosts file on your device. Um, basically any operating system out there has this file with DNS. That file is actually not necessary, but we still use it. And first file, uh, full source file. It's like 40 years old. And this was used before the internet actually existed in the app on it. They had a few problems with that at each node of the ARPANET. They had to manually maintain the hosts 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 these same computers, which is basically a clusterfuck and you don't really want this. So after 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 if an client asks for an IP of a domain, some server answers and gives you the IP address. That's still how DNS resolution resolution now works. Nothing changed in this idea for the last 30 years. So they before they actually started on the technical bits, they started working on the idea of how should our system work? The basic idea is you've got a worldwide global hierarchy where you put all your domain names into it. Then you've got decentralized service, thousands of service 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. Like this is one of the oldest protocols you still use daily, heavily 
daily. This is what the hierarchy in the 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. Am I held on the edge of the wrapper? Like more than 30 years ago? There were not that many trees. And then it gets split down, and each branching nodes 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 like tree hierarchy in Danas today. So how does this work? So let's take a look at events that succeed at the E for this event. If you want to know the IP address of that domain, you asked the root servers that top nodes in the tree hierarchy. OK. Rich Server is responsible for the DEA. Then you get an answer with this, you go a step a little further in the case of the dope, the E tilde, the people responsible for this. The Dinnick, you may know them and you ask their servers, OK, who in your zone data is responsible for CCC duty? You get an answer and then you do this as well with the name servers from the classical computer club and you get an answer. Just to give you a picture of how this works. That top note in the hierarchy, the root servers, there are more than 4000 physical servers out there to work with the daily DNS without those servers. Nothing at all would work. So as I explained, you go to traverse the tree top down. But that's not actually how it works and make it recursive. And at each point in the tree where it's promising, you can actually catch previously seen IP addresses. This is what we call a case solving process, if you remember the slide with the tweet in the beginning. This may be important for the actual DOJ employment deployment. Then there are stuff resolved. So these asking several different servers and traversing the three 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. Um, it still works t
hat way that you ask yourself resolver for an IP address and you get that. But the sub resolver just forwards your request to an actual recursive resolver. From that, the sub resolver gets the actual answer for the IP address. And this is what ends up in your operating system. And what declines on the chart is actually use. Um, so how do they talk to each other, all those thousands of server world, right? Well, as I said, they first came up with the idea of the day A. And then they worked on the technical bits. These are actually two different standards. So rc, ten thirty four is the idea the description of how the DNS works? I see. Ten thirty five is the technical bits. How do we work on the wire with that system so they all know and understand what they're actually talking about? Um, one of the most important things is that only a specific um, name servers are. Well, operative name servers for specific parts of the domain, like the root servers for all the top level domains, and you can split this out. And remember the tree from the hierarchy. And 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 resorts 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 made server belongs to a specific domain because you can just random bits of our on CCC dot dot, for example. But this would be a different server than the web server on CCTV, and you can actually differentiate them on the level of DNS and you make this with the resource records. Those which are resource records have an encoding representation, so they are not text files. So whenever you ask your stuff resolver or any other resolver, I'll send you a DNS server. They are not sending text like an HDP. They're s
ending an hex and binary encoded, not an octet and coded message. Each resource records has specifics on how you encode those resource records into an octet that's all in ten thirty five. So if you ever want to have an, well, 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 kernel code like the C code for code to implement IPC 10:34, it's 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, um, all those bits and pieces that are going thrown around in the internet are done. Um? On Port 53 and complete in plain text via UDP. That's why it's now called the or 53 because it's on Port 53 before just a few years ago. That was DNS, but DNS has changed, so we had to find, well, a new name for the old school DNS and the well, new school DNS. As I said, it's completely unencrypted. Everything is in plain text and there is no authentication at all. They never thought when they when they made DNS, they never thought that you would have billions of people in the internet. So whenever you ask and names of you are not, there's no way for you to be sure that you're actually talking to the server you wanted to talk to. There's no authentication at all. So what? This DNS over 4:53 can be tricked, so any men in the middle knows or can know what domains you're asking the IP address for. It can be blocked to block Port 53, and none of your business will ever work. You can manipulate anything that runs over this, so you can just if young men in the middle and there's no authentication, you can just send bogus answers. Um, and you can actually redirect um requests on DNS over Port fifty three. So I asked the names of of the CCC, but the men in the middle, the points me to a rogue name server and gets me a different IP address, which works quite easily because there is no authentication at all. It gets ugly. So these kind of well known fe
atures 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 of bullshit of DNS over 53 to make what most people call supervision. So they filter out your requests on a block level. Hijacking is actually what I find really funny is hijacking like redirecting you to a different page is used as a feature worldwide and a captive portal whenever you enter a public Wi-Fi. You have to accept some some terms and conditions. You may have recognized that those kind of portal pages don't come up if you use an H2 TPS connection, because if you use HD IPS display 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 log in page for the public Wi-Fi. That's because they fuck up DNS. Side note there's actually an IETF working group that works on fixing this. So they're working on a protocol to make this work. Um, Google kind of slipped around this. They have just probing your role in Android whenever you, um, access a public Wi-Fi Android probes. This public, you are out and then you get redirected. You can also do this with SSL dot com. Highly recommend. Um, so as I said, DNS is kind of strange, and it's used, um, in, well, not that good of ways. So in the end of the 1990s, a lot of people, um, saw that the unauthenticated part of DNS is going to be a problem. So they came up with what we now know as DNS like DNS stands for domain name system security extensions and the name extensions is because they just add new resource records to the old ones. So it should be, um, compatible to the old standard. Um, the idea is that using zones were the key. So each root server zone um assigned with the key, and then you can this. You can traverse the tree in the hierarchy and add signatures to those new zones for an
y single name server. So and with this, you can actually authenticate the name server you're talking to. So the answer you get from those names so that you can trust is tamper proof. Problem is, it's still unencrypted. So whenever you use DNS like, um, people on the way, I can still see what you are requesting. They are not able to manipulate the route. 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 porn up in your free time? Hmm. Maybe not. Um, there are other problems with the NSA, so it's really, really hard to deploy, it turns out. Um, it's hard to tell how many servers actually use the NSA, but current estimates between 15 and 20 percent of all the names of us out there actually use the NSA, and they had 20 years of time. So that may not be a viable solution to actually make DNS tamper proof, DNS tamper proof. And as I said, you've got stuff results that don't actually use any resolving. Um, 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 some results to do this. So the Microsoft Surface area in the North is able to understand that they get the NSX signed results records, but it's just not validated if the signature is actually valid. And this is the case with Linux and bases as well. If you're running those operating systems, you can of course validate your DNS signature. But in Germany, you would then have the problem that, for example, the Foote's boxes by M typical home router in Germany, you see the main goods box. If you use the NSA in your home environment on the client devices, you wouldn't be able to resolve Fitzsimons box because it's just a bogus domain name. It's out of the actual hierarchy. So there is no second option. If you validate signatures, you won't get an answer and you can't access your router anymore. So the Nasdaq has problems.
 Then 10 years later, people actually thought, OK, what about encrypting the actual DNS? Like, make it all secure and encrypt what we put on the wire? This grew out of the open b c, folks, but you may know folks from OPEC or have heard how they work. They're not really sent out, so they just implement stuff and see you think it's secure and say, Yeah, well, we've got a solution. Use our solution that worked with open associates. But this only worked because some people at ATF actually thought, OK, well, we use the implementation for our son, not because it's the best with the NSA. It never got any track record. So DNS sec DNS script is no IETF standard. Nobody uses this out there. You can go to the DNS crypt website and download the client. Um, make it work and have encrypted 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 open AC on your own server somewhere in the network, you can then run a DNS script capable name. So yeah, that's that's not going to work on your laptop or think about your grandma. Is she going to do this? No. So the IATF 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, uh, should be, uh, uh, um, 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. Um, and one of the first things the ATF thought about was DNS because DNS was one of the last protocols that at that time was still completely unencrypted. So they really, uh, quickly started and working group to solve that. That was the DNS private exchange deprive deprive came up with DNS over. Uh, tell us. So we've got this really, really nice encryption protocol. Tell us we've got a lot of really good or really remote implementation for to tell us. But any operat
ing system out there supports us. So why not just encapsulate the DNS traffic in us and put it on the wire? Then it's encrypted and nobody can complain. And this kind of works. So if you're using yacht, it is actually encrypted. Nobody in the middle can see what you are asking a name server. But the thing is, the traffic can still be monitored because the actual Senate says that you must use Port 853, just like you must use Port 80 for HP. There's no way around it. You can still see traffic on there. And with this, whenever you see traffic, you may be able to analyze or block it. So the easiest way to block Dot you would be just to block the port, and nobody would be able to, well, ask for encrypted DNS answers, which is kind of lame. So then there was DNS over ITPS Drage. This was worked on after Dot, and this was basically based on the idea that D.O.T. can be blocked. And the idea was how are we able to work around the well blocking feature of the yacht? The basic idea is that you just mix DNS within any other traffic. Um, if you would block traffic. None of your clients would work anymore for anything. So even in the work environment, nobody would be able to work. So the idea is if you use that protocol, you can't block DNS requests and answers. You can't track it because it's encrypted and you can't really modify any of it because you can't see anything and you just see eight steps traffic, but you don't know what it is. And when I was at IETF 99, this was kind of like a revelation for me because it was really, really nice and easy idea to just encrypt and make DNS. Well, I really, really like that idea from the beginning. It got then resized like a year ago. So how this this works? Um, so as I said, we've got this resource records that are pushed into octet that are make up their packages on UDP on Port 53. We use this kind of encoding just as an issue. The payload you can use, get and post requests get an answer for it if you import a lot of libraries that do 
all this. This is just, uh, just a few lines of Python. And so you have two important DNS slip that makes your DNS request and then you have to import the H2 Tips Library. And then you basically tell your client to please make a request and then you get the answer. Literally, it's like ten or fifteen lines of Python. It's really, really nice. Really easy. A really usable, uh, if you've got a few hours of time, try it out. It's really, really good. You can use it in Firefox and Chrome as of now. Um, they publish that. Both of them published implementation like months and years ago. And on top of that, there are standalone clients out there if you just want to play around with DOHC. Uh, cool supported like for 100 like one and a half years, you can use the agent code and then OK. HTP, one of the most used Java libraries, supports debate. So if you build a client that really needs encrypted DNS, uh, look at those libraries. Um, this is taken from the Senate after 84 84. So how the system works, we've got the URL template like the, uh uh, DNS gravy on example dot com. Um, we make a get request on TPS to that server. As you can see, the DNS query, it's just a bunch of encoded stuff in the sand that they use base64, you and coding without putting to make the resource records just smaller. You could use all of the actual octet, but that would be, um, well, it would be just too long and too much. So we use base64 and we call this a DNS message on HDD. Really, really easy to understand if you know anything about it. Just look into the RC how this this works on the server side. So the coal project by Daniel Sandberg actually provides a list of public service. So if you just want to use Firefox or Chrome or any other client and try DNS over, yes, you can use several different services. A lot of big commercial DNS providers supports DNS over the cheapest Google Cloudflare quote nine from IBM and digitalization of trials runs their own DNS server. Um, the DNS server from them su
pports Dottie and Stuart. Please don't spend their DNS server. Um, the hyphen mentioned, uh, runs their DOHC server on the Congress on a specific domain. So if you want to play around with the O-H after this talk, um, take a look at the key. Um, they have a lot of, uh, explanation of how to use their five d h server at Congress. And finally, British Telecom is the first big commercial ISP in the world that is now testing the deployment of DNS over its chips. Um, you can use, uh, do you age on your own servers? Of course. So you just need a URL template and. Pass whatever requests you get for this, there is UN tutorial for engineers on how you do this. It's really straightforward. The idea is that you use Engine X just as a proxy for an actual result. So you take the request form of this resolve resolver the resolve it gives you back the resource and then Engine X pushes this back to the client. So if you're running a website, you can put this website into an the server. So if you really care about your security, please do this. How does this look? Look on the server side. As I said, we've got this thing message with, uh, which is unsanitized and 8.4mm. And this is, as I said, the actual DNS format on the wire. That's what that's what's, uh, sending in the Senate. So the server answers with an OK message. Um, you get the content lengths, you get the maximum age off that request, so you can actually catch that request. And then you've got a hex encoding of the actual DNS answer, which resolver actually can use powers and gives you the IP address of whatever you're asking for. Um, problem is on the deployment side outside of the web HD sphere you can't really use um, do you edge with currently available methods and Microsoft announced that they're going to support you H and Windows 10 just a few months ago. There is no implementation, no really 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, u
h, from my point of view, it's really good because no other OS level resolver has this on their agenda. None, uh, system defaults implemented D.O.T., but they don't validate the TALF certificate. So you can just, yeah, that just doesn't work. Why you still us if you don't validate the certificates. Um? So they're in the point of the operating system, you basically can't use the as of now. Um, if you're running a kind of commercial name server yourself, you may know the nastiest. Um, this actually supports, uh, du h. Um, this actually supports SEO H without TLC, so you can play around with all the encryption without validating certificate if you just want to look at what is actually happening. And then there's Bind Bind US, the most widely used DNS server in the world, um, by and was co-developed with the actual DNS standard. Um, 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 DOHC because none of their clients would pay for the development. Finally, just a few months ago, the IOC announced that Mozilla is going to pay for the DOHC support in mind. So after that, even your ISP that runs Bines may be able to support DOHC without any trouble. They just need to upgrade their minds. Um, so current state of the available client situation on DOHC. Um, with Chrome and the maybe upcoming Windows 10 implementation, um, you can use the H and it's used automatically if your predefined DNS server also uses the UAH. So let's say you've got Google eight eight eight eight as your DNS server. Um, if you do this, um, they kind of guess that you want to use. Do you h- have you using Chrome and then they just transparently upgrade you to do H and you're gonna use this? Um, this works with a bunch of other servers like eight or nine, uh, different providers. Um, in Chrome, we don't know what Microsoft is going to do with Windows 10, but they said they've wanted to do this
 as well. Um, Firefox defaults to using DNS over its peers in the US. Um, unfortunately, this got a lot of heated discussion because they use a predefined server in Firefox rather than opt out. So whenever you're going to install a new Firefox with the UC English, uh, location. You're going to use Cloudflare as your DOGE server provider. And as of a few weeks ago, Firefox also supports a next audience, which is also new upcoming commercial DNS provider in the US. But as I said, this only happens if you're running the US international location of Firefox. OK, so just a short recap. I should be used to you. As I said, it's encrypted and standard compliant, encrypted, not like DNS script. Typically, DOHC servers are faster than normal name servers. That's because we use HTP. For the last 25 years, HTTP was optimized and pushing content fast. That never happened with the NAS because, well, just wait for the UDP packet. And if it's not the rights to a new one, HDD never worked that way, and thousands of engineers worked on making HP faster. That's why a deal is most of the time faster than DNS. You can reuse load balancers, you can reuse caching infrastructure, you can reuse a CD. And on top of that, we typically use HP to it for the UAH and then you get multiplexing and the server push. So you actually get your answers faster by design. The bad thing is they 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 Senate actually says that you can use HPC for a lot of different monitoring, and the Snowden revelations showed us. This is also used so you can infer a lot of well specifics on the HPC traffic, even if it's encrypted, which is stuff that you may not want to do. Then their deployment problems. You may have internal and external networks, like if you deploy a DNS in your company, you may have specific domains that are just known inside your company and a
re just resolved inside your company. Typically, you would just announce your own name. So I had the TCP IP and this own name server would resolve your own made up domain with the O-H. It won't work because it's encrypted on a different channel, on a different port and the clients of your. While users will never get this name server, which is a department problem, especially in enterprises. And then there's a problem on how do I actually get to an age server? Because I mean, I need a domain for my DNS server in order to resolve domains. Isn't that a bit weird? Um, yeah. Uh, yeah. The actually parts of the so it can be a C community that prides themselves with working for security and invented DNS script. They deactivated the H in their Firefox implementation because they just don't like Mozilla. Although I don't know, they maybe don't, uh, like security features. I don't know. They just didn't want you. Which is kind of stupid, in my opinion. The ISPs in the UK actually called Mozilla and and some internet villain because they're deploying the O-H. Like, who is going to fuck up the internet? Of course, that's going to mean Mozilla. Like, are you kidding me? The same kind of same fight happened in the US. A lot of ISPs and their lobbying companies actually wrote letters to Congress that the deployment of, OTOH, it's going to be an anti-competitive behavior. But how is your ISP in competition with your browser? OK, so this works in that way that they think that if Google and Chrome ever uses their Google DNS servers, yeah, the ISPs will never be able to send you advertisements over DNS or, hey, check your DNS in order to said you total Iceman's. So they then now are competing with Google on that space, and that would be anti-competitive. Um, I've asked, uh, that's my day job! As journalists asked ISPs in Germany how 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 are in Germany and digitalization 
just needs time. Uh, the well, most liked answer from you was from the US, a telecom, they said, due respect for data ownership. But if I encrypt my DNS, I and I choose my own name server. How is that bad for data ownership? It may be bad for the data ownership of Deutsche Telekom that outsource data. They said also, the browser makers flipped over the production model of the internet, according to that, the production model is selling user data. That'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 the O-H in a browser, then the browser makers will see, well, the traffic of the browser. Isn't that the kind of thing the browser does sending traffic back and forth? I really didn't get what they want to tell me. Um, then there's a lot of that is just plain old nonsense out there. A famous German blogger that has had a has said that few users, Jason and he published this without any, uh, well, knowledge on the protocol. And as I said, it was standardized. You just have to look into the Senate and it says if you're using HP in the specific context that I explained, there is no chasen you don't need. Jason passes. 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 while an its connection. They didn't use the Senate for this, but a lot of media called said that this malware uses Stewart, and that's why the H is bad. But how many military examples out there using ace encryption? This is bad because Mary uses this. It's completely nonsense argument. Then there was a talk this year by Paul whichthey, who actually wrote a lot of stuff in mind and who really, really knows science. And he compared Google to the East India company because they're using their age. I don't know if you know the East India company, but for l
ike 20 or 50 years, there is 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. Hmm. I don't know if that's actually a good argument. And then there's one by a vet who are actually working for Pardon, who produce the nastiest. And he says that the O-H 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 but the request able to get you faster routes on their back end. So if you're. If the old school name sort of obviously runs in the coming clean and you're now using Cloudflare as your resolver, I come I can't give you a faster route anymore and that's why it's against net neutrality. I think, uh, 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. I'm sorry, that was sarcastic. And the same goes for cloud fact. Of course, Cloudflare is not an honest or good company, but Mozilla thought about this. Um, I'm going to come to this, and there are a lot of arguments that it's if you centralized DNS on Cloudflare Intelligence Agency will be getting all your data, according to the Snowden revelations. They went, uh, the intelligence agency went to the internet exchanges and deployed men in the middle attacks, the pervasive monitoring because it was easier than coming up with court orders for each single individual company that runs a specific internet service. So even if they come up with a court order and go to the ISP and want to get your data, um, it's still way, way hotter, hotter than the pervasive monitoring at the internet exchange because there is no ma
n in the middle attack possible with the. And then there's arguments that opt out of that because why would you ever trust a company of choices you don't know about and the target audience for the O-H? It's not you and the audience. If you made it here, you know how DNS works together. Target audience for the O-H, it's 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, yeah, you can't trust a company like Mozilla. What fucking stupidity. So it's just remember the goal of the O-H. We want encrypted DNS. We want this for all, and not just for a few people who are able to actually encrypt that 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, uh, you 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. Um. The only way so if you don't like DNS over us, you can just disable it. But browser vendors, operating system vendors, anybody out there that's working on clients that use, um, DNS needs, in my opinion, need to deploy a DOHC default. Otherwise, we will never get encrypted DNS out there because as we 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 batshit crazy arguments that they are cooperating with Cloudflare. They thought about this. There's a public policy on the contract with Cloudflare. What is Cloudf
lare allowed to do with the audience data? They're not allowed to, um, personalize any of their side of this data. They're not allowed to sell this data. They're not allowed to make a shitload of stuff. Um, and they have to delete those log files after 24 hours. So even if a state actor like an intelligence agency runs into Cloudflare name servers, their canary 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, um 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, and 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. Um, and from what I've got, they are not that many ISP's that want to cooperate with Mozilla on that. And there's a lot of, well, ISPs that say they specifically don't want you. From my point of view, whenever an ISP says that they don't want you just because they use DNS hijacking as a feature. So they were working against you as a user. So please ask your IP if they want to deploy the O-H and if they want to take part in the trusted root cause of resolver program of Firefox. Apart from that, there are ISPs that, well, use the UHI at least test or deployed you h now, um, as British Telecom. So this is going to be way more in the distant future. We're going to have chrome and windows on the edge as default, I guess. And finally, s will be able to resolve a name by Duo H and then we end up of encrypted DNS for. Yeah. Um, for all the technical problems they have working groups now at IETF, so we are going to solve this. But split horizon problem, you're going to solve the discovery problem downdrafts to make an announcement of Windows Server by DHCP. So the engineers
 are working on it. And then. There's still a and HP coming up. So even if you don't want to use HTP or HP, as for the is the thing that the IETF is standardizing after HP three, which runs of a crick is going to be DNS over quick. Quick is a new transport protocol. It's completely encrypted and well, it 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 the O-H. Now it's time for questions. Um, if you have any. Well, actually, we'd have to make that singular, except you're fast, you're very fast on the microphone over there. There's another microphone there. So go ahead. Yeah, thank you. You set encrypt all DNS part DNS over edge tidbits encrypts only traffic from resolver to to stop resolver because from Cloudflare to the DNS server, everything is unencrypted like before. Well, yeah, so that's what we care about in the IETF careers of monitoring. So we know the client traffic is actually monitored at the Day6, for example, and we want to stop this. We want to stop men in the middle attacks. If you're running your own name server and you want to run a resolver on your own name server, just use D.O.T.. They're not going to block this. This is going to be the you can't be blocked in a client. Uh, kind of sense the the name server communication, inbetween name servers. It's not part of the idea. OK. Well, unfortunately, that's it. We are out of time, even though with 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. Uh, have you still have questions? Maybe you can take your discussion someplace. Thank you. And, um, applause.