Okay, everyone, this is part of the system detox, so if you're not familiar with the system detox, I'm here for you. So, please, may I ask a long question for Mr. Ladd?

Hi, thank you very much for coming. I'm quite impressed by the amount of people who came after the beer event yesterday or early in the morning.

I'm here to talk about the system being where you want to take the energy in the space. My talk's mostly just a big grab bag of different topics that we're working on in the system and have worked on in the last year. It's without any particular order. The biggest chunk of the talk I'll talk about is something that's not strictly systemy, though,

which is DNSSEC, if you haven't heard of that, which is something we have been working on in the systemy project for the last months or something.

And because I find it quite interesting, I'm going to talk about that in a minute. So even if you're not really interested in the system being hard and energy-based, I hope there's something interesting in the talk for you. Assuming that you're hard. Even if I exclude my talks as interactive as possible, I'm not sure, though, if that's really a little hard for such a big group of people,

but let's try to do a Q&A and then at the end of the session. Okay, let's talk about system being 2016. So let's start first.

So in 2015, for those who are involved in the system in any way, we switched to GitHub. So we're one of those projects now who are maybe popular, like everybody else on GitHub. We moved away from the desktop-run infrastructure to GitHub simply because we realized that this is where most of the free software people are from,

and it's the easiest to get contributions to. Of course, it's a problem for many of us, but essentially, we were not really interested in maintaining our own infrastructure. We realized that infrastructure wasn't the best one today, and so we decided to go for GitHub.

And if you show, like, a payoff, we have more contributions than we ever had. And yeah, people generally are way more active. Although our demo works, though, there's so much nice analysis, we actually have a CI in this kind of thing now.

So we've done a lot more, but we do all the fancy stuff that all the web people do, and it's actually awesome. Also GitHub is pretty normal in many ways. Like, the workflow is weird, I think, but it's still so much better than everything we've done before, so we're kind of happy.

Of course, all the distributions have adopted system D as default. I think the only thing that's happened is that JetBlue wrote the spec format. But all the other distributions, like Fedora, RAL, SUSE, Ubuntu, all of them have developed a system D.

It's also in the commercial distributions now, and since quite some time, you can buy RAL 7 and system D for that. So the question is, are the names over where system D is coming from? Are we boring now? I don't know, maybe a bit. Like, we're in a moment in that phase where we had to push it through, where we went once to convince people.

We convinced them, apparently, but nowadays it's more like, it's more maintenance than actually being progressive and being revolutionary and radical and things like that. So this did change quite a bit.

I'm not sure how closely you know system D. I kind of hope you do. Many of you do, at least most of you, work with them today. Some of them have system D on more or less than others. Some of them, if you know system D, you know that we have one called system D Network D. Network D does what the name suggests, it manages the network.

It's kind of something like Network Manager, but it's not Network Manager. So it's much smaller and much more automatic and much nicer for the administrator. And it's now already adopted by Fedora and Ubuntu and the cloud, which is pretty amazing given the fact that Network D doesn't even have an interface.

So you can actually talk to it. You can give it dynamic commands like up this interface or shut down this interface. But there's automatic logic, right? Like when automatic does something, the interface popping up and going away was apparently convincing enough for the system uses to adopt it in the cloud, which I find pretty amazing.

We are working on actually adding this interactive interface as well. So that we can actually afford that. Another success we have is nspon.

I'm not sure if you know nspon. nspon is a component of system D. It's something like a minimum container manager. And it's not so, I mean it sounds a lot like it was something like Docker, but it's really not. Like Docker is focused on microservices. Like where basically each container has exactly one service.

Whereas nspon is really focused. It's really on running containers where every single container has its own operating system inside of it. Where every system inside of it is not the one you see but actually the one that actually deserves the main PLE one. For example, system D.

This is actually being used now that it has back-end for core-level objects. Which is kind of cool. Given nspon, we primarily created to actually test system D for ourselves. Because if you have system D and you want to test the boot-up, you can of course always do a hot boot-up.

Because your physical hardware can waste a lot of time because you always watch the screen while the files run through and these kind of things. So we started while developing systems and doing this stuff with virtualization, KVM and things like that. It's much better, but it's still very hard to debug because you can actually not touch a debugger that needs to be in the process of the virtual machine.

Unless the debugger also runs on the virtual machine. So we created nspon for that purpose, which is like a minimum container manager that allows us to... It's like a distributed steroids, right? A distributed steroids where it's actually capable of running a full operating system inside.

So yeah, nspon is totally not my buffer. And it's part of the basic operating system and how we test our stuff, how we build our stuff. And it's kind of built into our core-ready core, but I don't know if that's what I thought. What's also interesting is that some of the more resilient systems in system D, like _____, we decided that, well, we didn't want to just glue something

together on existing components that match, that doesn't match, somewhere close together. We saw that we did it properly. And so for network D we created this little _____, which is DHCP. DHCP, of course, is actually very difficult to cross.

Especially if you have five messages where you say, I want an IP address. And somebody says, I can copy this IP address. And somebody says, I want this IP address. And then you have the IP address now. And then there's one, too, to give it up here. So it's one of the most driven particles of the days.

And we decided, OK, we don't want to screw everything together for DHCP. And we created this library called sdbhcp. It's not really public, but it's supposed to be public one day. And it's what network is based on. So after we did that, then the network manager people saw, OK, it's kind of cool. They're just trying to be a TCP driver that just does the TCP without actually counting.

And they actually decided to integrate that, too. Which I found to be pretty amazing because of the fact that it's not actually public or public yet. We don't commit to a stable IP address yet. We don't even support it yet. If you want to use it, you have to, I think, take the source and incorporate it into your program. So it's kind of cool that there are a lot of things you can do before or even sort of public,

if you're making anybody interested in it. OK, something we haven't been working on in the last year, which is going to come up with best distributions, I'd like to say a little bit different topic now, is the unifying control group how I view them.

I'm not sure if we've, like, I presume that not everybody in this room even knows what control groups are supposed to mean. A little bit of background on that. There's very technical stuff. It's basically, on Linux, you want to be able to manage resources of the group processes in a specific way.

Like, for example, if I'm patching MySQL, it's called one machine. You want to make sure that I'm patching this much memory at most and it runs on two CPUs and it gets this much CPU at most, and then you want to set IOs and things like that. And that's what you want to do for a patching, and then you want to do something different for MySQL, right?

Like, the control group stuff is something that system is very much based on. Basically, everything that system manages is contained in one of these control groups. Control groups are a kernel concept. It's expensive to use the space in a file system. I'm not too weird in that. Control groups are horrible.

Like, they used to be. One of the things we've had to build on consistently, because they not only do this resource management for us, but they also do the grouping, the general management of service processes and service runtimes. But they were horrible because they were pretty chaotic. People working on the various parts of resource management in it didn't always say what they should have been,

so they have very different semantics. Now, in the past few years, in the last few years or something, did you feel like that guy had been working on fixing all that in the kernel? And for that to create something which is called the unified control group around you.

The difference towards the OAuth, meaning that instead of having separate organizational trees, how these resources are managed, depending on the type of resources, right? So that you would have one tree for CPU management, one for CPU time management,

one for IO management, one for CPU binding management, and so on. He decided, okay, we'll just have one. Because after all, the operating system kind of wants to manage one variety, not many, and these varieties aren't going to be independent, they're not going to be affordable anyway.

So, the result of the unified control group hierarchy, it's a very low-level thing, you will get to contact it if you are an administrator, and then look at the details a little bit further, because it is actually exposed to various classes of the operating system. Yeah, we love the toxicity, like the old ones, the new ones since last year,

it's going to be turned on in the distribution very soon. It will break things, because the unified control group variety, you can choose if you want the old one or the new one, but you have to choose. And if you pick the new one, then the old software will not work. One of the old software that might not work,

there's a pretty popular little program called Pucker, because they tend to directly access these varieties. Anyway, I'll start short. It's all going to be different, all going to be much, much better with the unified control group variety, but it's going to break out by the system,

and these are the products which actually interface with this. The net result of that is, for the first time, we get really clean applications when service actually runs, and we get fully integrated resource management on every level, right? We provide them already to some level of the system,

so that you can add run time, readjust the resource management, and so as you run, both are going to be much more complete and nicer. I talked, oh yeah, one thing like the unified control group variety, this is already in place, actually, support for the P&E's computer, this is really basic, it actually allows you to put

a number of processes that a specific service can run, right? So you can basically say that Apache shall be able to run 200 processes, and MySQL shall be able to run 20 processes, trying to force them more into an error. Sounds absolutely basic, I think that is, and it's kind of weird that it comes down to 15,

so you get the sense of code. Yeah, another thing is that the single step is going to be safe for the first time for allegations. What does that mean? It basically means that even if you use these more complex things like result control, that they can delegate cards as a variety to other software,

like Docker, for example, which is, yeah, kind of nice. Again, this is going to be an API fact, if you ever looked at a Linux system on the CPU variety, you might have seen something like this before, or something like this before, you have flashes that have a CPU with a controller name, and then you have an IP that refers basically to the directory

where you have all the processes in it, and with the new stuff, it's going to look like this, it's going to be much simpler, the controller part is being removed, the controller part is usually something like CPU status, CPU status memory, and it's kind of basically similar, but it's different and kind of great stuff. Anyway, I think I've really talked way too much about the filters,

I find it much more interesting, probably not much to keep up with. Yeah, that's something to be said. This is the result. This is the result, it's actually probably going to be the main part of the talk now. Or this is the result because

DNS resolution. DNS resolution is pretty far across from what Michael referred to. Which is, of course, I mean, everybody knows what DNS is, right? It's a service on the internet that translates those names into IP addresses. Traditionally, in labs, the way how DNS is implemented

is that it's a binary call into GDC that calls to get algorithm for, and a couple of alternatives for that stuff are essentially all the same, where you pass those names and it will directly go to the network, talk to your local DNS server, resolve the IP addresses and all that. This is pretty much like that, and pretty limited.

And this is the result D, we try to do the very same thing, but centralize it in a system service. The outliers, if they want to do the name, do that directly and go to the network and query that, but then instead, they talk to your system and resolve D. There are a couple of reasons why that is to do that. First of all, it's the caching DNS result, right?

Meaning, not every look that you do actually goes to the network, if you've already lost this transaction before, right? That's going to be a minor factor, but it's a bad thing. Also, that's what I could call LLMNR, LLMNR, something like DNS, like Microsoft came up with that, basically about doing automatic name revolution

in the local network. The more interesting thing to note is that it does data set, that's what I'm hoping to talk about. Data set is something where people want to set it down,

the name serves as the internet. It's a relatively old standard, like I've seen people start experimenting with that 10 years ago. In 2010, six years ago, the DNS root zone, we actually got signed to the DNS side for the first time.

The general goal of DNS side is to make sure that if you access www.microsoft.com, then you actually end up at the Microsoft.com IP address or something else, right? Of course, in the case of Microsoft.com,

it's not a particularly interesting case, but it's way more interesting if you're thinking about your bank transfer, and you really want to be able to talk to your bank and not do something else, but it tends to be a bad idea for you to get there. So DNS set is something to check it out. It's authentic in DNS,

it does integrity checks, and it does not do confidentiality, meaning that if you use DNS set, hopefully it will do that, or it will verify that the data you get back, like the mapping from the host IP address, is actually what it expects to be and it's going to be geographically verified,

but it will not protect things regarding confidentiality, meaning that people will still be able to see that you did that in front, right? So people will not be able to fake the IP address of the bank if you want to access the bank, but they will be able to see

that you did that access the bank. So, there's a change of trust. Basically, the root zone contains cryptographic between the APTs that are authenticated from the TLD zones. The TLDs, like top-level events and others, like .com, .land, .de, and .be,

for various reasons, yeah, you know all those. The TLD zones carry keys, which sign the commands we all have, right? So that if you go to fasten.org, fasten.org is basically protected by the keys that are stored in the org zone, and then the keys in the org zone

are protected by the ones in the root zone. And this goes recursively down, right? So if anything you have on the internet, you have a client with keys in there, about that, the signatures about that, and all that stuff on there. So, I don't really want to go into too much detail on this, I mean, I talked about that, and I'm talking to the networks guy who

really wants to talk about detail. I want to talk about the implementation of this, and then I'm specific. So, one of the use cases of DNS in particular is not just to do a host name resolution, but also to carry a lot of additional information in DNS.

The guys in the DNS deck are mostly in mind, I'm writing this HTLS and P2P footprint, and other cryptographic basic data in the DNS. The idea of being basic, that if you do an open UI rather than an active bank, that the DNS will not only tell you

what that idea is to get the data from the bank, but it will also tell you, and by the way, there's a certificate, like the TLS certificate we used for the HTTPS connection that you're going to do, as this fingerprint. And then, you don't need to authenticate the TLS

certificate in any other way, because you already know, because you have this authenticated DNS scheme, where basically you can guarantee, yeah, put the graph again, I know, I made it proof, that this is actually the fingerprint of that service. So, in a way, it's a scheme how the variety of certificate authorities

on the internet, right, we all know those, I figured out how they're embedded in the browser, is actually unified with the variety of the DNS code on the internet. And, yeah, that's the idea. Again, DNS is actually deployed around the world. It's deployed in the root zone,

it's deployed in most of the TLS, like .com, .net, .de, they all have it. I was signed in 2016. It's also deployed by most US government websites. But, other than that, too many people, too many services are actually using it. There's a meter, like, you can go to that website

and it will actually tell you the current statistics how, on the world's most popular websites, how many actually use DNS. And interestingly, that's 2%, I don't have that, right? Facebook, Google, all these websites, they have actually secured the stuff with DNS. Which is interesting, and which makes

everyone wonder what happened in all those 60 years since they signed the root code. What's interesting to know, Google runs this DNS server, a progressive DNS server called 8888. I think it's, I mean, it kind of became popular, I think, even in the normal presence,

because I know when Turkey blocked the internet for some websites, they didn't provide DNS information, and then they had it for three years on the mobile site, so that's a Google DNS server. What's actually interesting about that Google DNS server is that they actually build back that DNS site, right? So if you ask, you send your query to that DNS server

instead of the one that your ISP usually provides you, then it will do the full DNS evaluation. You have some chance that it has not been manipulated, which was the good thing about what Turkey was doing. Of course, it's also pretty useless, given that the communication between you and the UNESCO

is not necessary in any way. Anyway, so regarding the deployment, the website that I'm very good at that, the root zones and all these things are. On the client side, right? On my platform that I used to practice the internet, the asset validation is pretty much non-existent.

No OS implemented, right? Not Android, not generic Linux, not Windows, not Mac OS, nothing does. And that's interesting, right? How can that technology that has been adopted by all the internet bodies and by the US government and by all these things have not been adopted at all?

Yeah. So why is it so awesome to have the clients that are supported generally as a message? And that's really great because we have to request cryptography and stuff, and it requires proving things, and honestly, I think it's really complex.

That's what all the vendors don't like, right? If you move for it, they will find you quite some harsh words, but I'm going to let it out for itself in about a few minutes, I'm ready to do this. I'm going to make it slow, because when you do a resolution of an host engine and I hear this, it's no longer sufficient to just send one preview to me in a server

with the host engine and I hear this, that you actually have to request the keys to authenticate the system as well. So you actually do a set of requests, and they are expensive. So whenever you go to a website, it will actually take a ton of time, usually, until it cuts to that step where it actually makes it easy to keep an actual message.

So, yeah. On the server side, it's pretty nice to set up. The way the protocol is designed is it's not automatic. It requires you to, if you run it in SO, you have to constantly keep it updated to resize things with cryptographic keys. Regarding the documentation, the specifications are quite straightforward.

I spend a lot of time with managers, and the specs basically leaf out all the really interesting parts when it comes to the cryptographic groups and what they're doing. So, yeah. And then I ask the Philadelphia question, is it actually a good idea to replace this,

like, pluralistic? So, in fact, it's a certification system that we currently have, but you can't get this TLSA certificate from quite a few parties. But really, they've got to decentralize it in one place, which is ENS, which is run by the IANA, which is like this international institution,

which is effectively the U.S. government. This actually is just a really good idea to replace one by the other. But the most important part is actually knowing what it really means, right? It doesn't enable anyone to do anything who wasn't able to perform, right? Coming back to this example with banging that I gave earlier,

it's completely, you know, it's great if we can authenticate that first part of the, where the hostname is translated to the idea, but ultimately, that doesn't buy anybody anything because the actual authentication happens after that, right? And the HTTPS is readily secure.

I mean, it's its own stuff, but it's ultimately the TLS stuff will authenticate the fact that you're talking to the right server anyway. So, if you do your banking transfer to an HTTPS server, and do it via a DNS stack-enabled transaction or without, it doesn't give you anything, right?

It will work the same way. So, yeah. So, I'll tell you, basically, how not so awesome it is. I will still tell you that I'm recommended for you, so if you're not seeing everybody, you may as well. But, I mean, it's not competitive as IPv6, right?

IPv6 says 16 years or something or longer is like the next big thing that everybody will adopt. Still today, except for maybe the Wi-Fi here at FOSTA, pretty much nobody uses IPv6 on a normal computer, right? It hasn't been deployed on internal networks, like telecom networks, and these kinds of things,

but on the Wi-Fi internet, it's pretty much on the system, right? Very recently, for example, not even Google, it reached under its normal URL on an IPv6 address. So, now IPv6 is actually really good reasons to have it, right? Because there are no more IPv4 addresses available, so one would assume that there is quite some pressure

for people to adopt it. The NSF doesn't have anything like that. Again, I'm pretty sure not too many people like NSF, because it doesn't fix anything. It's just, I mean, close the gap, right? You can authenticate everybody, everything else on the internet, but you kind of put in the NSF and NSF would be good too,

and I'll authenticate that too. But also in the end, it doesn't buy anybody anything. a question, of course, one I was asking to myself, is should we actually support it via Wi-Fi? It's a non-scalable, non-scalable operating system. Why should, this is the Linux guy, why should this be a check?

What's the price for that? Well, I would say, because the data is sad, and because it actually is deployed in various zones. you know, security is not something where you deploy one technology and then you move on. It's really something where you try to secure as much

as you can when you try to secure the whole path, and then if one is out of the chain a week, then you still have all the other elements that will help you. So yeah, why don't we actually implement that and actually make something that's happening on the client, because

the focus that we really have with that is having some kind of connection that everybody really employs, right? I mean, this is really the case with system B. When we want to do a system B, it's really about generic, right? We're not caring about a use case where you write something and run some research on the internet, and maybe 100 servers on the internet. We really want something that can run

on any internet solution, pretty much anything by default but on system. And to make the deployable by default, we have to make a problem. One is private DNS servers, right? So, I know, like, many of you probably maintain their own DNS servers, and if they do that, they probably have their own private DNS servers.

Like many, many big companies run their own private DNS servers. The private DNS servers basically came up with their own naming scheme that is completely different from the internet. They established it without a district in the internet, as long as you access this internal network that's there so you can

resolve all that stuff and see that though if you use it all the way to C, right? If you use DNS set, then all of that will break because suddenly everything that you do is going to be authenticated from the top down, right? And meaning that if you have your own private domain, call it FUBAR

or something, and it doesn't exist in the real internet, then the real internet will tell you, I can prove to you that FUBAR does not exist, and then you cannot access the local level. So, if we want to make DNS set employable for mobile people, then we kind of really have to deal with that problem. And that is a big problem because, like, common Wi-Fi routers actually do

accept their own private DNS servers. Like in Germany, you have the FristBox, which is a very very popular commercial where you can buy everybody who has a Wi-Fi router and you get a good chance to run this FristBox machine. All of them maintain their own private DNS and their private DNS is called FristBoxBox right? And

it looks like FristBoxBox, of course it looks like a domain, but it's not available in internet right now. The irony actually about this one is that the top-level domain does not box, so at least it is sold to some consortium in Hong Kong. It's really fun, because as soon as they offer domains in that field, people

can buy the domain or can make everybody's router configuration not success. We'll see how that works out. It's kind of funny, but it's also I don't know, it probably doesn't matter too much, but the key is, these private DNS don't exist. And they probably exist in most ways

how people access the internet, right? And they make many companies and they invest in pretty much every home in Germany. So, just ignoring the fact that they exist, and saying hey, can you kind of configure your router anymore? You can't access the router or the website anymore. It's really an option, because the person said yeah, we're breaking the internet for everybody because we don't care, because we think DNS

is more interesting. So, this is when we decided we wanted to be an asset and we actually wanted to make it something that can be plugged in. All we have to do is a problem. We cannot take away the private DNS. We came up with a couple

strategies to deal with this. One of them is if you see the box top-level domain, and we make the proof that it doesn't exist, we commit it anyway. We'll only do that for the top-level domains, only for the box-based domain. We're not doing that for the domains below that.

So, basically means that as long as the router invents a TLD that doesn't exist on the real internet, then it seems fine. But what the browser cannot do is invent a domain below some other domain that already exists that is not a TLD. For example, it's not supposed to define a zone called fubar.ratcat.com

because that would not be cool if you wanted to do a local extension of the public ratcat. So, yeah, we also have a couple of other strategies to deal with this kind of stuff, but it's really a big issue. If you want to prove that everything exists or not exists, then people have to know what's done that doesn't exist on the real internet.

Another really nice problem is the fact that DNS on the internet and the routers are awful. They don't support DNS set properly. The Google ones like the 8888 that I mentioned does all these kind of things. It verifies DNS set internally and if you want to talk DNS set to it

you will do that. But routers don't even do it. The first box is actually a pretty good one. It actually allows you to talk DNS set, which is really weird in a way, because they also violate DNS set by providing their own domain so they basically say, yes, I give you all the possibilities to authenticate all the domains that you asked for me, but

no, I will also thank the domain for you that you cannot prove to exist. So, it's a bit weird. Most of the DNS servers in other routers works. Like, one of the favorite test cases I have is a WiFi router that exists in my vicinity from a manufacturer at Belkin.

It's you ask me a question and it says it takes like two seconds and then it tells you yeah, you can do DNS set and that sends you back to your own question and you say, yeah, thank you very much this is what I wanted.

But, yeah, and the routers are crap, but also the ISP is crap, right? In Germany, if you use Kongstar, which is the same thing as budgeteer Kong, you get a DNS server that doesn't give you an essay, right? So, if you customer to Kongstar,

then you can't give me an essay. Which is kind of sad. And then there's a problem about captive portals. You know, captive portals seems like if you use the WiFi at a hotel or an app or something and go through URL and redirects you to some weird private sign where you're just sending data and you can pay or something like that.

Those are captive portals. And the way many of them work, not all, is by faking DNS, right? So you type it into your web browser www.fosston.org and it will actually give you back that result and pretend that it actually points somewhere else and it really does so that you go to that website and you get this

captive portal page instead. Now in a DNS set world that's never going to work because DNS set can get in about proving or sense the city of data and as these captive portals fake the data then there's nothing because I think everyone will always say, yeah, the data should not. So it's a big problem. The way I see it is, like what we have in mind

is essentially real who there is. Well Network Manager and Android on all these operating systems generally have code in them now that really tries to accept captive portals. And what they do is mainly when they've got an IP address they try to connect to some well-known

website and check if something comes back that they expect to come back or if something else comes back they know that the traffic has been tended with this human problem. This is deployed, like in Fedora for example, with Network Manager it will always, like whenever you set up

a network connection it will usually be connected to the Fedora service to see if it actually is connected to the real end-to-end or some kind of portal code. In our strategy we've got a captive portal in DNSSEC. Well, as long as we have this detection phase for DNSSEC for captive portals we have to disable DNSSEC completely and implement it. Which

is not as bad as it sounds I would say, because the information in this captive portal in texture mode or if you connect it to the real end-to-end it's actually visible to the user in the macro guide again, and you know the top right at first, okay this is weird, but this thing usually shows you that links are very popular

so this thing in the top right usually shows you whether you're connected to the Internet or not and if you are in a captive portal it shows you a different idea. Anyway, so we have to deal with that kind of crap. So yeah, it doesn't mean we're trying to resolve that because again we wanted to create something

that actually is deployable in everybody's machine and if we do that we have to make a couple of compromises one of them is we have to downgrade from DNSSEC operation to non-DNSSEC operation aggressively right? If we figure out for some reason we cannot do DNSSEC we have to move it up which is weird

because it opens everything up to downhill vulnerability if an attacker wants to make you go to your banking side and pretend that you are a real banking side but actually are a fake one then you can do that by first making your client contract to non-DNSSEC rather than faking any

of the possibilities that you like because you're not going to be faking it anymore that's quite a problem but then again when we don't do this you can't access the Internet at all anymore and we have one of those DNS servers that is the core of DNSSEC and you can't bypass

these DNS servers and go always to APA, APA, APA, APA because of those private zones again because of private zones if I connect to an internal network for example or some other internal network or for example my home network then I really want to be able to resolve the local zones that are there so if I would bypass the DNS servers I would always go to the Internet

and then I would see the Internet and then I would see my other network so and we felt that by default when we turned this on we will downgrade from DNSSEC mode to non-DNSSEC mode automatically isn't that bad? it's kind of bad you can configure it also if not downgrade

but I think it's not everything lost, like first of all it's very lack of checksum still, right? because if something had actually changed that's not too useful though but what I find more interesting is that the information whether things were authenticated or not is still propagated to the application, right?

and if you come back to that use case that I mentioned earlier where people want to AMBA as its HTTP fingerprints in DNS and things are still good because the fact that something was authenticated or not is still passed to the application hence

if you use SSA for example to connect to some server to the Git server of GitHub or something like that and you try to authenticate the fingerprint of that DNS server that actually matches what's stored in the DNS and you see that this DNS server could not be authenticated maybe because you are loading DNS server

then you will have to figure out different ways to authenticate, right? which is the traditional way for example by showing a screen on the screen asking you, hey, can you verify that this actually matches what GitHub claims to be so I think that's still useful, right? it's the only way

I think how DNS can ever be made something that is deployable end to end on the internet, right? because if we would do it that way we would always insist on doing DNS set and basically means that at my home network for example, I could not authenticate my browser anymore

at my parents' home network I could not access the internet at all anymore because nothing would resolve because of that I couldn't use the internet at my girlfriend's home anymore because of that DNS as well also correctly doesn't do it and so on I'd rather access insecure internet

than on my own anyway, so I talked a lot about the fact about DNSSEC here I know a lot of people actually love it and I got some more slides than at random, but I think I talked about lots of stuff that I want to talk about which is DNSSEC

hopefully, all that DNSSEC stuff will hit the distribution very soon very soon and after some testing, probably for the cycles hopefully, I will let them this is a new system to be the first one to actually do in a while

on my side well, we'll see about that anyway, I think I got eight minutes left or something before I cut the other slides I think I brought a Q&A here because I'm pretty sure that some people have other questions about DNS encryption can we keep that

in the microphone? yeah, if you have any questions or anything thank you I think this is great I'm a DNS fan

so I appreciate this I guess you've probably been working on DNS privacy I'm wondering if you have plans for TLS encryption in the resolver? TLS encryption, no like, I don't know I

the way I see it is with DNS and it's not really about privacy it's really about security could the ones who need be as quiet as possible we still want to do a Q&A here please try to keep up with me no, I don't have any plans to do a TLS okay I mean, certainly that's the traditional

DNS view is that DNS is public certainly in recent years with pervasive internet monitoring I think that common wisdom has been changed there's a really good you've probably read an RFC about the dangers of DNS and efforts to make it look right I know you've taken on a big

chunk of work here and probably are looking for more things to do, but if you've got a lucky list of things for the future I would encourage you to at least consider a good point of DNS privacy honestly it would actually be super easy to add because we do support TCP transport with these DNS queries and if you do TCP you can also do TLS

it's not that big of a difference we're also already buying support devices anyway because we have to do authentication and it would actually be easy this thing is like at least none of my servers support TLS I'm mostly interested in the generic case it's kind of the motto of the entire

system, we think that we always care about the generic case, we always care about making sense of what can be done and I have my doubts that TLS-based DNS look up is something that is very commonly important okay some time ago you wrote about

that you want to change the way the base system, the limits and the packages are put together using containers authorized by System B is that still a thing are you working towards that? is there a time frame? well basically the component that we worked on

kind of did that already the problem is that the solutions have not adopted that yet and we thought that's because I didn't find the time to actually push that but quite a few so I mean, just a little bit of background this is like in the context we worked on making systems

a stateless way you basically can boot up the system by simply having to match user so that the first time you boot it it will automatically populate that system so that you have a complete system to work with now

basically if you as long as you run a pretty basic system and the rest of the system being whimsy and a couple of other pretty basic stuff all of that really works I can boot up my system easily with my future event but what you get is all the missing things instead of graphics, the file and stuff that is all good

but that's absolutely mis-efficient in real life people don't run operating systems that basically put something on top of an operating system like Apache or SQL or whatever else they want to run on it and don't generally support that because there are rooms that people wouldn't have to buy

the services shell bootable without any events that you can't see now, first of all we all know that secondly, it always means that the philosophy about allowing systems would be something that

the various services often actually have to buy into so it's not just a technical question or something of work it's also about convincing people that this is how they go and so far we have so much trouble with that but I would absolutely welcome it and I know that some distributions we have

is the one project that at least takes parts of it like, for example, the rest of the project uses some parts and it becomes integrated there I don't think that this would be on the big scale but to me, once it was left now to do everything in reality

there's not so much something that we can do it's something that the distribution has to figure out so where does the crypto in systemd come from

sorry, where does the crypto come from within systemd in crypto, we use the computer okay, perfect and are you oscillating g.lyc then? I mean what? I'm oscillating g.lyc I'm looking towards getting rid of g.lyc as you're making the decision no, we are not a standard library

we just do VNS stuff and it's like I don't know if you can talk in a way that the question is why is UMC evident is around VNS right now the system we use, ellipse APIs are crazy we don't, some of us are teachers with conscious APIs

some of us are actively using VNC extensions and a little bit of some of them have been published the purpose anyway

also using a well known website like how Network Manager does or no, it won't so the question was how do you see what the tech cabinet calls and the answer is that it will not

we assume that Network Manager or Network D or whatever you use to configure the network actually does that and tells us about it by turning off VNS and turning it off what guarantees Network Manager that this well known website does not take whatever my assumption is that we can convince

you never mind the people that as long as they do not have to follow all the instructions before that they talk to us and say please don't do VNS take it to VNS and that's what we want