unwind(8)
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Obser, Florian
DNS is easy. You type bsdcan.org in your browser's address bar, hit enter and you will be greeted by your favorite BSD conference's start page. Actually... We will start by giving a short introduction into DNS from the perspective of a client. We will explore: where to send questions to: upstream resolvers learned from dhcp / router advertisements / static quad-x resolvers vs. doing recursion ourselves, what questions to ask: qname-minimization (yes or no), what to do with the answer: benefits and limitations of DNSSEC. We will then introduce unwind(8) - an always-running, validating DNS recursive nameserver, answering queries on localhost (127.0.0.1). We will explain its privilege-separated design and show that it is secure to run this daemon by default. We will then show how its novel approach of observing changes in network location and actively probing the quality of the local network improve the user experience in DNS resolution. The focus will be on laptops that move through many networks, some good, some bad, some outright hostile. We will compare unwind(8) to prior solutions and show how its design enables it to run without user intervention. While unwind(8) is developed on OpenBSD it is intended to be portable. We will give pointers on a few OpenBSD specific features.
 Okay, good money. So in OptimistD we got quite good and quite efficient in writing free functional and secure software. So we do have time to also produce release artwork and write funny songs. When we get out of our web page, we travel to all these beautiful places where we come together to hack and to hike. But when we travel there, we enter all these weird Wi-Fi networks. You go to an airport where you have free wallet for it. But you need to fill it with the DNS. Because everything is terrible, you go to the hotel and they present you with a captive portal where you need to click a thing and you fill it with the DNS again. It's really annoying. So imagine we have a piece of software that takes care of this, that does this automatically and no matter where you are, no matter how hard the current conditions are. So who am I and why am I standing here? I'm an OptimistD developer since 2012. I mostly wrote previous separated demons. I also poked at the kernel and then the network stack there. And for living I run DNS servers. So that's a good combination here. I work at the RAPentasy which is a European non-profit and we run one of the root name servers and we also run another cluster that we call off, DNS which basically serves all the reverse, the delegation for all the reverse on the internet. These are heavily anti-ghosted. So we have many instances. The root name servers that is where all the DNS starts. There are 13 servers worldwide. They're identified by a letter. They're all anti-ghosted. So that's not just 13 physical machines. They're all built about. I'm very proud of that we have this K over there in the root name. That's quite neat. And this is what it looks like to be a root name server. Basically you have to answer real fast, yeah that thing does not exist. That's about 100,000 answers per second that say that thing does not exist. And we have about 25,000 answers per second. Yeah, go over there. I'm done. I need to give you a quick introduction to DNS. However, according to a virtue of our DNS, the combined knowledge of DNS is written down in about 2,000 to 2,000 pages of RFCs. And it grows by two pages per week. Do you have some time? Yeah, I can't do that. So there will be an actress in here. There will be noise and there will be no missions. But this is more about to get a mental picture on how this stuff works, not about how can actually implement the DNS server. So think of it as a distributed hierarchical key value database. There's a key value here. So you have a GPU dotted up on that view of the org, that's the name, and at the time A stands for address, which maps to an IP address. You can also turn this around and put it to get from an IP address up to a name. These are not actually connected. You can put in there whatever you want. To write for that, you flip the IP address around and in that address, dot r power dot s, you get that. And things look like feet. It starts in the roots, you know, by the way, there you have what's called top level domains. Like Comet, org, Canadian top level domain for the countries in there, or R-Power for the infrastructure. And every one of these circles denotes an entity that's responsible for this. And that's also where you get the hierarchy. So there's an entity that's responsible for org. And that entity then does how to get to other entities. You have for what you can ask various servers, the first one you need is an authority name server. That is the source of truth for a particular part of the hierarchy, like the root zone, the org zone. And this server either knows the answer for the question. It knows that there is no answer. It knows there might be an answer, go over there, ask them. Or it knows, well, you asked me something that's really not my thing to say, and it refuses to answer. Another piece of server is the recursive name service. And these are the complicated parts. They know how to navigate this hierarchy, this tree. And then there's a last piece. You're on the laptop and you want something resolved in the NS. Then you have the C library, which the other ones there, you get after it and you get A and F. These things then know how to talk to a recursive name server. And that recursive name server which wants to talk to is configured in atseriesolve.com. So if you want to get IP address for a.badat on a.id or off, it looks like this. And since this is an example, it leaves out all the error I'm taking. Look at the opportunity, which explains how to do this properly. So that thing went off to a recursive resolver and then the recursive resolver needs to do some work. And that work starts with, hey, root though, dop, dop, dop, dop, have you heard of that? But hang on, what is it talking to you now? This is a chicken and egg problem. It needs to know where the root is. The solution for that is it's built in. Every recursive resolver has a list of root name servers and IP addresses built in. So yeah, it kind of knows who to talk to. So it does this, dop, dop, and let your root zone appear. No, not quite, but I have heard of orc, maybe of those people over there. They're at g0.org.appliance-nc.org. But they're also in.org. So here's also an IP address which gets signed along to let you know who to actually talk to. So we do that. Hey, orc, dop, dop, dop, have you heard of it? Yes, ask those people in the Netherlands. And I'm not going to tell you where they are because, well, they're in the Netherlands. I have nothing to do with that. So we go back to the root. Have you heard of them? Yeah, yeah, yeah, they're in the Netherlands. Go ask the people in the Netherlands. Hey, have you heard of them? Yeah, yeah, yeah, they're here. Go ask them. So we go and ask them, have you heard of them? Yeah, yeah, yeah, yeah, it's over there. And now you can read the open-sd.org. That was actually quite complicated. Have you heard of how we told everyone that we want to build a.doc.doc on that.org? That's a bit excessive. People figure this out, this is actually quite recently only, in terms of what, recently on the internet. This is actually not a good thing. The question is, the recursive resolver can guess which parts it needs to set, which works mostly okay, it has a few quirks, but yeah, it just works most of the time anyway. So we do this. We ask the root, so, hey, orc, where's that? Yeah, it's over there. Hey, orc, have you heard of the alert.doc? Which is a bit silly because they probably can't figure out that you want to talk to the web server, but if it's something like supersecure.interl.company.thingy, might be enough. But the other, certainly is the, me as a root server operator, I don't want to know that you go to, I'm going to do a better job than I care, it's just one. So, the DNF itself is completely unauthenticated, just getting out of it, you don't know what it means. The DNF itself is hopeless. You get origin authentication, which means the thing that I get, I'm sure that it comes from the person that's supposed to come from, integrity, means what arrived here, nobody on the path messed with it. The denial of existence is assigned as well, the out front here, said nobody can fake that a thing does not exist, which is also important. However, it doesn't give you confidentiality, so the part, the answer, I'm not encrypted the path to the server is more encrypted, so everybody can still see what you're doing. There are two things that one can do with DNSSEC, and I really like this one. DNSSEC follows the hierarchy of DNS, which means that not everybody on the internet with a used card dealership can sign everything like a TNF. It follows the hierarchy, so whoever is responsible for.org cannot sign things for.com. And there's a provision in DNS to bind a certificate to a name in DNS to make this more secure. However, for this to work, and nobody really tackles this without terrible hacks, is you need to do the validation on your local machine, otherwise you run into stupid problems. So if you're doing it on your laptop, you ask the recursive names, at least to the DNSSEC validation. Why do I trust that, and why do I trust the path to that? This is easily solved by just doing it on your laptop. However, that is problematic. The first thing that we notice is you need a secured clock, because DNSSEC signs an interval, so the signature is only valid for this period of time. So you're on your laptop and you move it around, you don't control the network, so someone might actually do active filtering, like everybody noticed that DNS is 453, it's 545 and you repeat. So middle boxes might try to filter other things that they don't know about. Or maybe you have a recursive nameserver configured by hand that just doesn't, for operational reasons, doesn't support it, then you also don't get the requirement records for DNSSEC to work. This was the old way of saying that we actually ran into it. So you can also, well, don't do that then, but the point is I want this to work automatically. I suppose it should work on more of this laptop, that kind of thing. Please run it. Oh, nice. So yes, I did not expect how DNSSEC actually works, but what it does, not to terrible I guess. There are two more things that we need to consider. The first one is where do we want to send DNS queries to? There are many options. We can do our own version, like the diagram that I showed at the animation, that's quite complicated, but we can do that. We can statically configure a nameserver, the public resolvers, that the quad access are quite popular for that, and some of them even support DNS over TLS, which gives you encryption on the transport. We might want to use the one that we learned over DHCP or Rata advertisements. My laptop might have the Wi-Fi and 4G connection at the same time. I need to juggle that. If I want Wi-Fi, I probably don't want to send my DNS queries out of the 4G that's sold. But all these solutions, there's only one single place where we configure this, so they're all fighting over at www.serialof.com. Another consideration here is that the privacy part, who can see what I'm asking for? If you talk to an upstream forwarder, if it's provided by DHCP or you configured it by hand, then the server operator can see this, what you're asking for, or a person in the middle can just let you traffic. If you put DNS over TLS in the mix, then at least your path to the operator is encrypted, so someone on the path can't see this. But again, the server operator can see this. And presumably, maybe, if you are not going to depend on how you do this, these queries can be correlated to you. So the TLS or TLS resolve needs to talk to the internet, and if I can see or observe that path, that might be correlated to me. For example, if I run my own, and I'm the only one talking to this, that is trivial, whatever that thing had asked for that came from me. Another alternative is, well, we do our own recursion, and we have to QNM minimization enabled. So someone who is close to my laptop can observe what I'm doing, but the authoritative name source probably may be not. The other thing is that you're on Intube, and you're traveling around with your laptop, is captive portals. This is the same. You're on the free Wi-Fi, and they want you to click on a thing, and I accept your terms of services, and I'm not evil, and this is all good. But for that to work, they're playing evil tricks with DNS, maybe with HTTP and a SAP machine. And for it to really work all the time, when you know that you're behind a captive portal, you need to talk to the DSP service. You might, the DSP provided name service, you might get around this, but usually what happens is you try to go to your site, and it intersects this, redirects you to something that is not resolvable on the open internet, and only on the name service that the DSP leads provide, so you can actually resolve this. We will come back to that later when that is important. So let's see what we can do about this. First, what did we do in the past? The simplest solution is, yeah, just let the DH line do the thing. It just owns a series of cons. You only have before names, ever in there. This will very likely get you past captive portals. If not, then the captive portal is just broken, so this is the best you can do there. You are however at the mercy of whoever is running the different present names that are provided, and this thing might not actually be good. This thing might not be fast. And you don't have any DNS support at all. Under the provision that you agree that you need to do the validation on your own laptop. What people then do together around the, oh, this recursive namesaver is what's happening to me is just terrible. I configure my own, like use one to quote X as public resolvers, because they're quite fast, that's the end of the pair. This will very likely not get you past captive portals, because if the redirect is not resolved on the public internet, you lost. So you start to fill around with things by hand. This will also not work in places where portals with 53 years is filtered. You just can't talk to your strategy configured namesaver, and again, no DNS. Then people thought, oh, well, this is, if you have, I'm not in base, let's just fire that one out. It's a recursive resolver. We tell these clients again, leave the Sresort control alone, we take it over. We can even get DNS over TLS now. We get DNS like validation. Again, it won't get you past captive portals, because you're not properly with them. And you run into problems where DNS is filtered. So again, you fill around with things. And then what the FreeBST is doing, they have a resolve code as a demon, which is actually called openresolve, which is a rework of a thing that Debbie did. From what I can work out from the Man Page, this is quite powerful. You can script it, and it can run scripts on events. It also has provisions on how to reconfigure a recursive namesaver and then run on your local box when things change. Like you get a new DHCP list, you can script it, then it fills those in as a port order. But from what I can tell, it definitely comes with barriers. So you need to do all this setup and all this disconfiguration, which is great if you want to do this everything work, but if you want it to just work, it's not a matter. This is where we end up with Unwanted, and we're going to go over all these things. So Unwanted is a recursive namesaver that's supposed to run on your laptop. And it should always run. Which means that it must be at least as good as just doing the DHCP provided to the namesaver so that people get a life. For, well, I set there 2 to 3,000 pages of RFC for DNS. So I could certainly not implement that since December last year. So we are using the Bundle for that, but it has DNS, I think, which gives us a DNS-seq. The recursion, it can talk to... You can configure static forwards to talk to the dose, and it gives us a DNS over TLS. It is in the tradition of OpenMaze, you provide separate a daemon, otherwise you probably would not even get a daemon. It makes heavy use of Platch to run in a restricted server for a T-Mode, so it's more like your PlatchCon, the thing just got killed. And it has a restricted view of the file system. It just doesn't see anything else. It's kind of like maybe a change through for the file in there, but it's more powerful. Also, go to boss talk about this. What does that need to do for it to always work? It needs to practically monitor the local network if things are changing there. There's a link going up and down, and I'll do a video for you later. It also needs to then figure out what is the actual quality. I know the link just went up, but what does that mean? I need to check. Can I actually talk DNS to the internet? So it does that. Let's have a look at the details. Live on-ron, this is developed by NL app labs. They give us on-ron and also NST. We have both of them in OpenBSC base. For technical reasons, I'm going to have a local copy of this part. But we don't do any changes to it. Updates to it are very easy. Every time we update, I'm not just going to copy the things over. Also, if we need to do tiny changes, upstream is very receptive to this, so we do not carry any local tips. It is, yes, the privilege separated. We just stand up for all the network units in OpenBSD. And if you want to write a new one, just copy an old one, rebuild the special parts out, and these days I can do it in one to two hours to have a new one. The other thing here is it gives you all the benefits, the security benefits, the whole set pattern. It gives you a copy part that you can do, copy, reload, have a logging framework, and there's a control process for this. Get all this for free every... For privilege separation, it runs four processes. The parent process, which starts off the front-end, the capital portal process, and the resolver. In the parent process, we do all the privilege, the operator, like open ports, open files, and we pass open file script to stand to the other processes. The front-end process hand talks to the network while in the port that gets handed in from the parent process. And... So it gets a query over the service port, passes this on to the resolver process over a pipe, the resolver process resolves this for us, and gives us the outcome back, which we then send out to the EDP. When it comes up, it doesn't actually have a new server port open. It starts to look around what's the current network quality, and once it decides, oh, I can actually talk DNS, then after the parent process, please open the port for me. This is the same happens when later on it finds out that it can no longer talk DNS at all, then after the parent process to close the port itself. Later on, more widely, that's the thing. I'm going to skip this. The resolver process does all the DNS query for us, but it also checks different resolving strategies for us, and it decides on which is the best one. It also initiates the captive portal checking it, and can find out that it knows when to ask to find other people behind one. The captive portal is quite simple. It gets an open socket from the parent process, and is just an isolated HTTP speaker. And it sends a GET request, and expects a response, which can be an HTTP state code or a boiler, and then tells the resolver to put it behind the captive portal or not. Managing uses a patch on an email. But with the patch, you tell the kernel, I'm only going to use following a set of SysCalls, like with the FATL, I'll patch that. I will only operate on already over-filed descriptors, which try something else that the process gets filled by the kernel. The un-app patch gives you the ability to talk to the internet to open more ports. And with un-vale, you get a restricted view of the file system, I think an example of this. So this is the patch that we have in the processes. The parent process is allowed to open a socket to the internet, or to open this socket, it needs to do this for a 453, for example. And it can also open files for real, and path them on to the other process. But there's no writing for that. The front-end process can only work on existing files, can receive them from the parent process, and it can accept connections on the control socket, that's what the un-app patch is doing there. The resolve process is somewhat alcohol, because it actually needs to talk to the internet, so it's allowed to do that. And it's also allowed to read files. But we don't want it to read all over the file system. So we only unveil the certificate bundle that we need for DNS over TLS benediction. So it can only see this one file. And the Caps portal is very limited, it can only talk to open file scripts and get them. So it would be quite difficult to get out of this with data that you don't trust. About the monitoring of the network quality. Someone can do the following resolving strategies. It can do its own recursion, it can talk to DHCP provided resolvers, it can talk to statically configured forwards, it can do DNS over TLS forced statically configured. And now it needs to figure out which one is actually good. And what it does is it sends a query for a thing that is known to exist. This is just a technicality, it knows that the root is on exist, that it knows that the thing is there. It's also known that the root is on the side, so it can depend on this. And if we get an answer and we can validate the answer, then we know this thing actually allows validation. Maybe you only get an answer, but all the DNS records are stripped. So this is not the validation fails, this validation is just not available, because the thing that you're talking to allows this. Then you know what, the portfolio is resolving. If you haven't checked yet, we end up with unknown, if you run it to a timeout, this is that. And this is then also both from the top to the bottom, the best strategy, so this is a quality. We always prefer one that's validating over one that's resolving. We also keep a histogram of response times. So everything that's below 10-second 30s, 1,000 answers, they probably came from the cache. And this looks like we are in around 40, 60, or a minute seconds, so the response time is at this particular location. The idea here is that it can use this to distinguish between, if we want to switch resolving strategies. If it's really terrible, like all your answers are up there, 1,000, 30 seconds response time, maybe you want to talk to something else. Also mentioned the captive portal detection. This works by, you need to configure a URL. And you have to set the get request to that, and it can expect a HP status code or a status code in the body or only in the body. And while we get an answer that is not expected, or maybe we get a timeout, we decide, okay, we have a captive portal, and that short circuits the decision process to what should we talk to, to always only choose the DHCP provided once, no matter how terrible they are, because that's the thing that we need to talk to to get past this. And in the background it continuously reprops to figure out, oh, someone actually clicked, yeah, I'm fine with the terms of service, and you're past the thing. It also comes with a concrete file, but here's the neat thing, it actually works without one. If you don't give the concrete file, it can do DHCP and its own recursion. If you want more, you need a concrete file. Unfortunately, we don't have a captive portal URL built into that, probably more of the things that where you want a concrete file. You can configure the preference, if you decide, and a static forwarder state can also enable DNS over DNS after a long time there, and you can give it an authentication name, so you configure your name servers with IP address, otherwise you end up with a chicken and egg problem, or how are you to then validate a cert that you're getting back, so you need to tell it, expect this, which is the authentication name. I'm actually glad that it needs to be at least as good as talking to DHCP, because we're back in the DH Client owns the ETC Resolve Conf. This has also to do with, we don't open the port immediately on 50th Street, so we arrange a Resolve Conf like this, where we first look at those, and then we list the names that were set to DHCP on Client. The after here is that the C Library resolver, it tries to talk to 127, but there's nothing it's listening there, it will immediately fall over to the next two. There's no time out there, it immediately gets port unreachable, and there's talk to another thing that's not there. What kind of failure mode is there where this is not going to be as good as DHCP, because it uses the DHCP provided IP addresses? It's a touch-rail-way system. They have a... So we're using the Bandung, which means that we cannot disable EDS0 option, which is technicality. It always sends an EDS0 option with the query, and what the middle box on the Dutch Rails does is it sees EDS0, and whatever you ask the Dutch thing, it responds with what you're asking for, it doesn't exist, like always. And we can't get around this. And what we're going to do is, we disable port 53, and we talk directly to the thing, the C Library does not send an EDS0, and we get prompted. Yes, it's an X-Table. Okay, EDS0 is coming from the Bundabow, which is imported from the third party. Yes, it is. I've tried running reverse-reversal resolvers locally on my laptop, but I think I was in bags of hacks before, and this is the trick that actually makes it work, because there's always some place it just does not fucking work, because they have locked it. I might run into something else where it decides, oh, this is weird, we are not talking to you. So this is the... You don't even know this one, this goes away. This is the libc resolver. Or it's a bug in the libc resolver. Yeah, yeah, yeah. It needs to fix this. I'm sure quite fast here. If you want to port a thing, these are mostly the things that kind of make it not portable. It uses it to figure out that the interface changes and it needs to reread the release file to get the name service there. It reads this from the route bucket. I'm not entirely sure if the other PSDs, they do have routes on this, but I'm not entirely sure if you get that information there. Also, I'm not entirely sure where the release file might actually end up. So, is it just work, or maybe it can be hacked around in unwanted control just at the feature there, like, yeah, use those names or that kind of thing. If you don't, well, you probably won't have a touch-perfection on Unreal. The only way to get around that is just on the point at zero and arrange for a change route where you have access to the service PSD. Or you can treat ledger non-vehler annotations to figure out how your own sandboxing facility can approach this. We have a question about the captive portal. Oh. Specifically, what part of the loop? I can't hear who it says. What's the point? What does it do with the knowledge that it's got in the captive portal? Oh, it talks to the DMC people who added the names over. Can you answer that question? Oh, sorry. The question is, why is there a captive portal detection? So, if you point yourself behind a captive portal and you decide, I do my own recursion, then you might end up in a situation where you don't get the, yes, I accept your terms of services page. So, for as long as you're behind a captive portal, you treat it as DNS is completely failing locally? Yes. That's what I'm trying to figure out. That's not doing any of the main pages. Sorry. So, then does it switch the entire system resolver over and then keep checking the, do I have access to the internet page using the other resolvers? Or, when does it switch back after it notices the captive portal was passed? If that's one part of the re-auditly. Yes. The re-auditly re-checks, it does get requests and when it gets the response that it wants, then it switches to whatever you have configured. So, if switching to the DHCP name servers makes the internet work, then does it start realizing the page works and then switch off halfway through the terms and services page? No, no, no, no. Because when you get the terms of services page, the internet is just, it's not working yet. So, if you, in the background, it does get requests through the configured checker and when you have not clicked the thing yet, it will get back, no, no, no, you're not talking to the internet. There's no race to lose. Oh. Yeah. I think that was done with this one. Huh. It's a good idea to do it well. Subtutor work. We had this, this good idea that we want to have this broadcast mechanism where all the sources that tell us, here's the name server that you can ask, can convert. So, we currently parse DHCP release for that structure. What are we doing with router advertisements that give us every six name servers? What are we doing with the 4G model that gives us a completely horrible way of the name servers? The idea is to just put this on the router, so I can do this on this, and we get the information out of there. If we have that, then it kind of gives us the name server from the router, the password server for free. Some people point out that you need per network configuration. So, you're wandering around, you're at home, you're traveling, everything is nice, you're the only curtain, then you come to the office where they do the same called spitorizing DNS. It's kind of like the Catholic portal where if you want to resolve certain things, you can talk to the DHCP provider names, it was like you entered the office, you want to print. The printer is only resolvable by talking to these things. So, it should be possible to detect this situation. There are multiple ideas on how we can do this. The first one that I'm going to implement, and I'm halfway there, is it sees to which SID you're connected, and it just uses a different config. Another idea was, and this gets more and more crazy, look on what layer 3 address your gateway is. Look on which layer 2 address your gateway is. After 40 modems GPS where you are. No, we're not implementing that one. Actually, there's a different approach. I'm going to do a quick work, I'm going to be speaking off the top here. What I'm thinking of my emphasis is very functionally speaking, is it builds the same niche as Linux's system view resolv- Sorry? System view resolv- Nope, the older one from the new option at NUK, totally bring it back here. The little mini resolver that is actually brain dead, the only purpose in life is to go out and talk to other names or other subjects. We've all used it in one way or another. The master key thing. What's that? Yeah, that's my answer. Yeah, that's my answer. Thank you. Yeah, that's my answer. One thing that might solve this summary problem is that it has a lot of algorithms. It asks every resolver he knows about the same question all at once. Right, yes. I know. Which, as a network operator, I have problems with this, but other hoods like the Japanese pre-damp small, and if it's set up per network config to learn which, because you have to keep track of what run domain connection was coming in on, you have to keep track of the shitloads of parameters, so you can easily ask everyone, and your config file says, if you see this nameserver, trust it first. Yes. Yeah, we can, oh yes, we can also, we can also do it all fine on the nameservice, which is like the three address gateway, the three address of the nameserver, we can do that. Okay, I actually considered this, but this is just a privacy nightmare. But since we now have a config file, why not? Like, if the operator really puts this in and they want this, code lines this is not difficult to do. But, yeah. Well, the other advantage is I've been in many, many, many hotels where the primary nameserver in the HTTP gives you is, you know, upwards of two seconds per station time, and the secondary results in under 100 milliseconds. Oh, this is solved. Maybe I should repeat one of these. So the comment was you get two PHP nameservice, the first one is terrible and the second one is actually okay. Lip and non does the right thing there. Lip and non does the parallel queries. So we are good there. We're worried. Yes. I must admit I find I do home detection at home right now, but I just need a background loop resolving in the internal address. So it's, that would effectively be the same thing. Yep. Many ways to do this. So yeah, this certainly, I suppose ideas will come up. So first I will implement the SFID idea and then we'll see. Yeah, first to the SFID idea then people are like, oh yeah, I can totally detect my network this way, or I can detect the pathway. I got to take the whole thing so that we can implement. But kind of in this vein is, oh I'm connected to a VPN and I don't need to talk, but I want all my queries over there to the VPN. It's kind of the same thing. Another issue that we need to, that we want to do, so it keeps the histogram on how well this performs around foot-wise. It would be nice if we could switch. I have not quite figured out the math on how to actually do this. When should we switch? It's actually terrible. I mentioned that we need a confi file for the capital portal and I suspect that a lot of people want that, so it would be needed to have a built-in URL. But this really is the bike-shot from hell. Like, people can't agree on this. Off-server. No, no, no. And the other thing is, on one of the slides I hope this is saying a dust-optimistic DNS-like validation. The idea here is that it detects that DNS-like actually works and then uses it. The problem is, it is too optimistic in this. When it starts to fail and the detector fails, well, it stops doing it, which is a trivial downgrade. So the idea that we want to implement is, if you're in a network and the background detects DNS-like works, it pins it to DNS-like must-work here. You cannot downgrade it. Only when you move networks, it needs to detect that you move to a different network, then it does a reprope again. Or maybe you really, really know that DNS-like must-work. We can also provide a config option to never allow a downgrade in that sense. But then you're again on your own, so you kind of lose some clarity there. Because once you move to a network where it doesn't work, then you need to fiddle again with it. It's a trade-off, I guess. More questions? Yes, please. Are you aware of an on-line lab DNS-like trigger and or are you more prepared for it? What are the problems? The question was, am I aware of an on-line lab DNS-like trigger? Was it a coding DNS-like trigger? Yes. The implementation is unbound for the bit of magic that detects an HTTP, whether there is a captive portal and a loss to an enabled validation over a DOT, for example. I was not aware of this, though. It exists as a practices for Windows for Mac for Linux. Okay, thank you. Yes. How do you decide, or do you decide whether to do genome minimization or not, or do you leave that out to do it or not? The question was, when do we decide to do genome minimization? And the answer is, we leave it out to the band-monger. It seems to do this correctly. Another question, right away? Yes. Are you going to, or are you going to talk about some form of indication to the user, I don't know, that DNS-like validation has been disabled to a downgraded? Yes. The question was, is there any indication to the user that DNS-like validation has been downgraded? So, on a protocol level, it does the right thing. It does not have to have a claim in the flags that this was actually a validated answer, which is not a terribly good user, in any case, because you can't see this. You can also see it in the control process, with the control tool. You can ask, live on, sorry, you can ask online, what are you currently doing, what are the states? So, it shows you this. It can actually talk to the internet. And you get a validating answer, nothing that's appearing, it also gives us USB network that are also validating, and apparently everything, what do you want doing that? I was told that everything about 1024 is evil in this room. So, this is trying to talk to 843, which is apparently also evil, so that gets blocked. Does that have a, is there a machine-partial version of this? Sorry, you go ahead. Is there a machine-partial version of that output? No, but if you want to, so it speaks a specific binary protocol, and this can be implemented, or we can implement it here that it's a machine-partial. Because for people that use things like i3 bar, it would be interesting to have a condensed version of that in your status card. Yes. You can just talk on the online CTLs, I'll go through this. Yeah, yeah, yeah. So the question was, is there a machine-partial output for this, and 4.4, like your window manager, because, yeah. Why would you run the control program on my hand, that's you'd really need to have this more in your face that something happens. Sorry, we're there. I was going to point out that is anything except 8, 4.4, 3, and 22, and it's quite less than, not lackluster, especially as the region I have. Well, soon as we all work on the wife, we'll be here with them, we'll not be by the day. There's one point where you talked about the counter-portal reduction, you said this is the buddy-shed from hell. Yes. Can you adopt a solution like, for example, the system. Which simply calls the shell script. Do whatever the hell you want in the shell script. Return me some. No, no, no, no, no, no, no, no, no, no, no, no, no, sure we could do that, but that does not solve the problem. What we want is to have this work automatically without a contract file. Oh. Build in the URL, check this URL. You can't choose to which evil court you want to talk to. They all have one, but we cannot agree on to which one we talk. Everybody has one opinion. No, no, no, no, no, no, no, no, no, no, no, the other one. No, no, no, no, no, no. We need to talk to the end. What happened? I don't know. I don't understand what you said. Ah, okay, okay. Anything else? Where is the log? Log? Yes, just look. Do you mean query loggy? No, just go to the spark. Yeah, yeah. Is there a problem with the query log? Is there a problem with the query log? It also goes to the search log. The question was, is there a where does query log go? And yes, it goes to the search log. You need to correct the invibosity to higher. So this broke something I use at home when I turned it on and I like it elsewhere. At home, I redirect all my resolvers in Google to my local recursive resolver running unbound on my gateway, which then has a giant list of logon filters on it, murders all of Google AdWords, Alversites, etc. This affects the group around that for being at home. No, it's not at home. I like it because I don't block DNS out. Short of blocking the external resolver, which I could do on my guest network, that's actually probably the best solution for me is to actually just dump all 53 of my guest network and then it would probably, then it would just fall back to using my local resolver which is just fast and I'd be happy. I guess I should just outright block 53. That's one option or the feature where it detects where you are. Yeah, and I can change. So if you would fill it with a preference there, you would just pull out the QCP one. Also, there was a hacker fund going on before here and I implemented a block list and unwinded it as well. So I could suck up my same block list. Which is a bit silly for you to use, I guess, but then you also have it on the road. Yeah, on the road. How far away is this from being usable for not just my own personal use on a laptop, but being a useful, defaulting name server for, say, 9,400,000 users? It will never be, no. That's not the point. So if you have 4,000-1,000 users, run unbound or about whatever you want. Do you control the network? So unbound has the... Well, you kind of maybe should. So what unbound is trying to do, and there's also optimization going on in this direction, it assumes a certain quality of the network, which you, it runs on the data, it runs on the server. If you then try to show this on your laptop, that's where you run into problems, because it assumes everything is shiny. There's a sysadvent who constantly does things to it. When that fails, you're in trouble and you start fiddle with it. This is the niche that unwind wants to solve. So it will never try to replace that. I think we're going to kick it over here. So... Thank you. Thank you.
 Okay, good money.  So in OptimistD we got quite good and quite efficient in writing free functional and secure  software.  So we do have time to also produce release artwork and write funny songs.  When we get out of our web page, we travel to all these beautiful places where we come  together to hack and to hike.  But when we travel there, we enter all these weird Wi-Fi networks.  You go to an airport where you have free wallet for it.  But you need to fill it with the DNS.  Because everything is terrible, you go to the hotel and they present you with a captive  portal where you need to click a thing and you fill it with the DNS again.  It's really annoying.  So imagine we have a piece of software that takes care of this, that does this automatically  and no matter where you are, no matter how hard the current conditions are.  So who am I and why am I standing here?  I'm an OptimistD developer since 2012.  I mostly wrote previous separated demons.  I also poked at the kernel and then the network stack there.  And for living I run DNS servers.  So that's a good combination here.  I work at the RAPentasy which is a European non-profit and we run one of the root name  servers and we also run another cluster that we call off, DNS which basically serves all  the reverse, the delegation for all the reverse on the internet.  These are heavily anti-ghosted.  So we have many instances.  The root name servers that is where all the DNS starts.  There are 13 servers worldwide.  They're identified by a letter.  They're all anti-ghosted.  So that's not just 13 physical machines.  They're all built about.  I'm very proud of that we have this K over there in the root name.  That's quite neat.  And this is what it looks like to be a root name server.  Basically you have to answer real fast, yeah that thing does not exist.  That's about 100,000 answers per second that say that thing does not exist.  And we have about 25,000 answers per second.  Yeah, go over there.  I'm done.  I need to give you a quick introduction to DNS.  However, according to a virtue of our DNS, the combined knowledge of DNS is written down  in about 2,000 to 2,000 pages of RFCs.  And it grows by two pages per week.  Do you have some time?  Yeah, I can't do that.  So there will be an actress in here.  There will be noise and there will be no missions.  But this is more about to get a mental picture on how this stuff works, not about how can  actually implement the DNS server.  So think of it as a distributed hierarchical key value database.  There's a key value here.  So you have a GPU dotted up on that view of the org, that's the name, and at the time  A stands for address, which maps to an IP address.  You can also turn this around and put it to get from an IP address up to a name.  These are not actually connected.  You can put in there whatever you want.  To write for that, you flip the IP address around and in that address,  dot r power dot s, you get that.  And things look like feet.  It starts in the roots, you know, by the way, there you have what's called top level domains.  Like Comet, org, Canadian top level domain for the countries in there,  or R-Power for the infrastructure.  And every one of these circles denotes an entity that's responsible for this.  And that's also where you get the hierarchy.  So there's an entity that's responsible for org.  And that entity then does how to get to other entities.  You have for what you can ask various servers, the first one you need is an authority name server.  That is the source of truth for a particular part of the hierarchy, like the root zone, the org zone.  And this server either knows the answer for the question.  It knows that there is no answer.  It knows there might be an answer, go over there, ask them.  Or it knows, well, you asked me something that's really not my thing to say, and it refuses to answer.  Another piece of server is the recursive name service.  And these are the complicated parts. They know how to navigate this hierarchy, this tree.  And then there's a last piece. You're on the laptop and you want something resolved in the NS.  Then you have the C library, which the other ones there, you get after it and you get A and F.  These things then know how to talk to a recursive name server.  And that recursive name server which wants to talk to is configured in atseriesolve.com.  So if you want to get IP address for a.badat on a.id or off, it looks like this.  And since this is an example, it leaves out all the error I'm taking.  Look at the opportunity, which explains how to do this properly.  So that thing went off to a recursive resolver and then the recursive resolver needs to do some work.  And that work starts with, hey, root though, dop, dop, dop, dop, have you heard of that?  But hang on, what is it talking to you now? This is a chicken and egg problem.  It needs to know where the root is. The solution for that is it's built in.  Every recursive resolver has a list of root name servers and IP addresses built in.  So yeah, it kind of knows who to talk to.  So it does this, dop, dop, and let your root zone appear.  No, not quite, but I have heard of orc, maybe of those people over there.  They're at g0.org.appliance-nc.org.  But they're also in.org.  So here's also an IP address which gets signed along to let you know who to actually talk to.  So we do that. Hey, orc, dop, dop, dop, have you heard of it?  Yes, ask those people in the Netherlands.  And I'm not going to tell you where they are because, well, they're in the Netherlands.  I have nothing to do with that.  So we go back to the root. Have you heard of them?  Yeah, yeah, yeah, they're in the Netherlands. Go ask the people in the Netherlands.  Hey, have you heard of them? Yeah, yeah, yeah, they're here. Go ask them.  So we go and ask them, have you heard of them? Yeah, yeah, yeah, yeah, it's over there.  And now you can read the open-sd.org.  That was actually quite complicated.  Have you heard of how we told everyone that we want to build a.doc.doc on that.org?  That's a bit excessive.  People figure this out, this is actually quite recently only, in terms of what, recently on the internet.  This is actually not a good thing.  The question is, the recursive resolver can guess which parts it needs to set,  which works mostly okay, it has a few quirks, but yeah, it just works most of the time anyway.  So we do this. We ask the root, so, hey, orc, where's that?  Yeah, it's over there. Hey, orc, have you heard of the alert.doc?  Which is a bit silly because they probably can't figure out that you want to talk to the web server,  but if it's something like supersecure.interl.company.thingy, might be enough.  But the other, certainly is the, me as a root server operator, I don't want to know that you go to,  I'm going to do a better job than I care, it's just one.  So, the DNF itself is completely unauthenticated, just getting out of it, you don't know what it means.  The DNF itself is hopeless.  You get origin authentication, which means the thing that I get,  I'm sure that it comes from the person that's supposed to come from, integrity,  means what arrived here, nobody on the path messed with it.  The denial of existence is assigned as well, the out front here,  said nobody can fake that a thing does not exist, which is also important.  However, it doesn't give you confidentiality, so the part, the answer,  I'm not encrypted the path to the server is more encrypted, so everybody can still see what you're doing.  There are two things that one can do with DNSSEC, and I really like this one.  DNSSEC follows the hierarchy of DNS, which means that not everybody on the internet  with a used card dealership can sign everything like a TNF.  It follows the hierarchy, so whoever is responsible for.org cannot sign things for.com.  And there's a provision in DNS to bind a certificate to a name in DNS to make this more secure.  However, for this to work, and nobody really tackles this without terrible hacks,  is you need to do the validation on your local machine, otherwise you run into stupid problems.  So if you're doing it on your laptop, you ask the recursive names,  at least to the DNSSEC validation. Why do I trust that, and why do I trust the path to that?  This is easily solved by just doing it on your laptop.  However, that is problematic.  The first thing that we notice is you need a secured clock, because DNSSEC signs an interval,  so the signature is only valid for this period of time.  So you're on your laptop and you move it around, you don't control the network,  so someone might actually do active filtering, like everybody noticed that DNS is 453,  it's 545 and you repeat.  So middle boxes might try to filter other things that they don't know about.  Or maybe you have a recursive nameserver configured by hand that just doesn't,  for operational reasons, doesn't support it, then you also don't get the requirement  records for DNSSEC to work.  This was the old way of saying that we actually ran into it.  So you can also, well, don't do that then, but the point is I want this to work automatically.  I suppose it should work on more of this laptop, that kind of thing.  Please run it.  Oh, nice.  So yes, I did not expect how DNSSEC actually works, but what it does,  not to terrible I guess.  There are two more things that we need to consider.  The first one is where do we want to send DNS queries to?  There are many options.  We can do our own version, like the diagram that I showed at the animation,  that's quite complicated, but we can do that.  We can statically configure a nameserver, the public resolvers,  that the quad access are quite popular for that, and some of them even support DNS over TLS,  which gives you encryption on the transport.  We might want to use the one that we learned over DHCP or Rata advertisements.  My laptop might have the Wi-Fi and 4G connection at the same time.  I need to juggle that.  If I want Wi-Fi, I probably don't want to send my DNS queries out of the 4G that's sold.  But all these solutions, there's only one single place where we configure this,  so they're all fighting over at www.serialof.com.  Another consideration here is that the privacy part,  who can see what I'm asking for?  If you talk to an upstream forwarder, if it's provided by DHCP or you configured it by hand,  then the server operator can see this, what you're asking for,  or a person in the middle can just let you traffic.  If you put DNS over TLS in the mix, then at least your path to the operator is encrypted,  so someone on the path can't see this.  But again, the server operator can see this.  And presumably, maybe, if you are not going to depend on how you do this,  these queries can be correlated to you.  So the TLS or TLS resolve needs to talk to the internet,  and if I can see or observe that path, that might be correlated to me.  For example, if I run my own, and I'm the only one talking to this, that is trivial,  whatever that thing had asked for that came from me.  Another alternative is, well, we do our own recursion,  and we have to QNM minimization enabled.  So someone who is close to my laptop can observe what I'm doing,  but the authoritative name source probably may be not.  The other thing is that you're on Intube,  and you're traveling around with your laptop, is captive portals.  This is the same. You're on the free Wi-Fi,  and they want you to click on a thing, and I accept your terms of services,  and I'm not evil, and this is all good.  But for that to work, they're playing evil tricks with DNS,  maybe with HTTP and a SAP machine.  And for it to really work all the time,  when you know that you're behind a captive portal,  you need to talk to the DSP service.  You might, the DSP provided name service, you might get around this,  but usually what happens is you try to go to your site,  and it intersects this, redirects you to something that is not resolvable  on the open internet, and only on the name service that the DSP leads provide,  so you can actually resolve this.  We will come back to that later when that is important.  So let's see what we can do about this.  First, what did we do in the past?  The simplest solution is, yeah, just let the DH line do the thing.  It just owns a series of cons.  You only have before names, ever in there.  This will very likely get you past captive portals.  If not, then the captive portal is just broken,  so this is the best you can do there.  You are however at the mercy of whoever is running the different present names  that are provided, and this thing might not actually be good.  This thing might not be fast.  And you don't have any DNS support at all.  Under the provision that you agree that you need to do the validation on your own laptop.  What people then do together around the, oh, this recursive namesaver is what's  happening to me is just terrible.  I configure my own, like use one to quote X as public resolvers,  because they're quite fast, that's the end of the pair.  This will very likely not get you past captive portals,  because if the redirect is not resolved on the public internet, you lost.  So you start to fill around with things by hand.  This will also not work in places where portals with 53 years is filtered.  You just can't talk to your strategy configured namesaver,  and again, no DNS.  Then people thought, oh, well, this is, if you have, I'm not in base,  let's just fire that one out. It's a recursive resolver.  We tell these clients again, leave the Sresort control alone,  we take it over.  We can even get DNS over TLS now.  We get DNS like validation.  Again, it won't get you past captive portals,  because you're not properly with them.  And you run into problems where DNS is filtered.  So again, you fill around with things.  And then what the FreeBST is doing,  they have a resolve code as a demon,  which is actually called openresolve,  which is a rework of a thing that Debbie did.  From what I can work out from the Man Page,  this is quite powerful.  You can script it, and it can run scripts on events.  It also has provisions on how to reconfigure a recursive namesaver  and then run on your local box when things change.  Like you get a new DHCP list, you can script it,  then it fills those in as a port order.  But from what I can tell,  it definitely comes with barriers.  So you need to do all this setup and all this disconfiguration,  which is great if you want to do this everything work,  but if you want it to just work, it's not a matter.  This is where we end up with Unwanted,  and we're going to go over all these things.  So Unwanted is a recursive namesaver  that's supposed to run on your laptop.  And it should always run.  Which means that it must be at least as good  as just doing the DHCP provided to the namesaver  so that people get a life.  For, well, I set there 2 to 3,000 pages of RFC for DNS.  So I could certainly not implement that since December last year.  So we are using the Bundle for that,  but it has DNS, I think, which gives us a DNS-seq.  The recursion, it can talk to...  You can configure static forwards to talk to the dose,  and it gives us a DNS over TLS.  It is in the tradition of OpenMaze,  you provide separate a daemon,  otherwise you probably would not even get a daemon.  It makes heavy use of Platch to run in a restricted server  for a T-Mode, so it's more like your PlatchCon,  the thing just got killed.  And it has a restricted view of the file system.  It just doesn't see anything else.  It's kind of like maybe a change through for the file in there,  but it's more powerful.  Also, go to boss talk about this.  What does that need to do for it to always work?  It needs to practically monitor the local network  if things are changing there.  There's a link going up and down,  and I'll do a video for you later.  It also needs to then figure out what is the actual quality.  I know the link just went up, but what does that mean?  I need to check.  Can I actually talk DNS to the internet?  So it does that.  Let's have a look at the details.  Live on-ron, this is developed by NL app labs.  They give us on-ron and also NST.  We have both of them in OpenBSC base.  For technical reasons, I'm going to have a local copy of this part.  But we don't do any changes to it.  Updates to it are very easy.  Every time we update, I'm not just going to copy the things over.  Also, if we need to do tiny changes,  upstream is very receptive to this,  so we do not carry any local tips.  It is, yes, the privilege separated.  We just stand up for all the network units in OpenBSD.  And if you want to write a new one, just copy an old one,  rebuild the special parts out,  and these days I can do it in one to two hours to have a new one.  The other thing here is it gives you all the benefits,  the security benefits, the whole set pattern.  It gives you a copy part that you can do,  copy, reload, have a logging framework,  and there's a control process for this.  Get all this for free every...  For privilege separation, it runs four processes.  The parent process, which starts off the front-end,  the capital portal process, and the resolver.  In the parent process, we do all the privilege,  the operator, like open ports, open files,  and we pass open file script to stand to the other processes.  The front-end process hand talks to the network  while in the port that gets handed in from the parent process.  And...  So it gets a query over the service port,  passes this on to the resolver process over a pipe,  the resolver process resolves this for us,  and gives us the outcome back, which we then send out to the EDP.  When it comes up, it doesn't actually have a new server port open.  It starts to look around what's the current network quality,  and once it decides, oh, I can actually talk DNS,  then after the parent process, please open the port for me.  This is the same happens when later on it finds out  that it can no longer talk DNS at all,  then after the parent process to close the port itself.  Later on, more widely, that's the thing.  I'm going to skip this.  The resolver process does all the DNS query for us,  but it also checks different resolving strategies for us,  and it decides on which is the best one.  It also initiates the captive portal checking it,  and can find out that it knows when to ask to find other people behind one.  The captive portal is quite simple.  It gets an open socket from the parent process,  and is just an isolated HTTP speaker.  And it sends a GET request, and expects a response,  which can be an HTTP state code or a boiler,  and then tells the resolver to put it behind the captive portal or not.  Managing uses a patch on an email.  But with the patch, you tell the kernel,  I'm only going to use following a set of SysCalls,  like with the FATL, I'll patch that.  I will only operate on already over-filed descriptors,  which try something else that the process gets filled by the kernel.  The un-app patch gives you the ability to talk to the internet to open more ports.  And with un-vale, you get a restricted view of the file system,  I think an example of this.  So this is the patch that we have in the processes.  The parent process is allowed to open a socket to the internet,  or to open this socket, it needs to do this for a 453, for example.  And it can also open files for real,  and path them on to the other process.  But there's no writing for that.  The front-end process can only work on existing files,  can receive them from the parent process,  and it can accept connections on the control socket,  that's what the un-app patch is doing there.  The resolve process is somewhat alcohol,  because it actually needs to talk to the internet,  so it's allowed to do that.  And it's also allowed to read files.  But we don't want it to read all over the file system.  So we only unveil the certificate bundle  that we need for DNS over TLS benediction.  So it can only see this one file.  And the Caps portal is very limited,  it can only talk to open file scripts and get them.  So it would be quite difficult to get out of this  with data that you don't trust.  About the monitoring of the network quality.  Someone can do the following resolving strategies.  It can do its own recursion,  it can talk to DHCP provided resolvers,  it can talk to statically configured forwards,  it can do DNS over TLS forced statically configured.  And now it needs to figure out which one is actually good.  And what it does is it sends a query for a thing that is known to exist.  This is just a technicality, it knows that the root is on exist,  that it knows that the thing is there.  It's also known that the root is on the side,  so it can depend on this.  And if we get an answer and we can validate the answer,  then we know this thing actually allows validation.  Maybe you only get an answer,  but all the DNS records are stripped.  So this is not the validation fails,  this validation is just not available,  because the thing that you're talking to allows this.  Then you know what, the portfolio is resolving.  If you haven't checked yet, we end up with unknown,  if you run it to a timeout, this is that.  And this is then also both from the top to the bottom,  the best strategy, so this is a quality.  We always prefer one that's validating over one that's resolving.  We also keep a histogram of response times.  So everything that's below 10-second 30s,  1,000 answers, they probably came from the cache.  And this looks like we are in around 40, 60,  or a minute seconds, so the response time is at this particular location.  The idea here is that it can use this to distinguish between,  if we want to switch resolving strategies.  If it's really terrible, like all your answers are up there,  1,000, 30 seconds response time,  maybe you want to talk to something else.  Also mentioned the captive portal detection.  This works by, you need to configure a URL.  And you have to set the get request to that,  and it can expect a HP status code or a status code in the body or only in the body.  And while we get an answer that is not expected,  or maybe we get a timeout, we decide,  okay, we have a captive portal, and that short circuits the decision process  to what should we talk to, to always only choose the DHCP provided once,  no matter how terrible they are,  because that's the thing that we need to talk to to get past this.  And in the background it continuously reprops to figure out,  oh, someone actually clicked, yeah, I'm fine with the terms of service,  and you're past the thing.  It also comes with a concrete file, but here's the neat thing,  it actually works without one.  If you don't give the concrete file, it can do DHCP and its own recursion.  If you want more, you need a concrete file.  Unfortunately, we don't have a captive portal URL built into that,  probably more of the things that where you want a concrete file.  You can configure the preference, if you decide,  and a static forwarder state can also enable DNS over DNS after a long time there,  and you can give it an authentication name,  so you configure your name servers with IP address,  otherwise you end up with a chicken and egg problem,  or how are you to then validate a cert that you're getting back,  so you need to tell it, expect this, which is the authentication name.  I'm actually glad that it needs to be at least as good as talking to DHCP,  because we're back in the DH Client owns the ETC Resolve Conf.  This has also to do with, we don't open the port immediately on 50th Street,  so we arrange a Resolve Conf like this, where we first look at those,  and then we list the names that were set to DHCP on Client.  The after here is that the C Library resolver,  it tries to talk to 127, but there's nothing it's listening there,  it will immediately fall over to the next two.  There's no time out there, it immediately gets port unreachable,  and there's talk to another thing that's not there.  What kind of failure mode is there where this is not going to be as good as DHCP,  because it uses the DHCP provided IP addresses?  It's a touch-rail-way system.  They have a...  So we're using the Bandung, which means that we cannot disable  EDS0 option, which is technicality.  It always sends an EDS0 option with the query,  and what the middle box on the Dutch Rails does is it sees EDS0,  and whatever you ask the Dutch thing, it responds with what you're asking for,  it doesn't exist, like always.  And we can't get around this.  And what we're going to do is, we disable port 53,  and we talk directly to the thing, the C Library does not send an EDS0,  and we get prompted.  Yes, it's an X-Table.  Okay, EDS0 is coming from the Bundabow,  which is imported from the third party.  Yes, it is.  I've tried running reverse-reversal resolvers locally on my laptop,  but I think I was in bags of hacks before,  and this is the trick that actually makes it work,  because there's always some place it just does not fucking work,  because they have locked it.  I might run into something else where it decides,  oh, this is weird, we are not talking to you.  So this is the...  You don't even know this one, this goes away.  This is the libc resolver.  Or it's a bug in the libc resolver.  Yeah, yeah, yeah.  It needs to fix this.  I'm sure quite fast here.  If you want to port a thing,  these are mostly the things that kind of make it not portable.  It uses it to figure out that the interface changes  and it needs to reread the release file to get the name service there.  It reads this from the route bucket.  I'm not entirely sure if the other PSDs, they do have routes on this,  but I'm not entirely sure if you get that information there.  Also, I'm not entirely sure where the release file might actually end up.  So, is it just work, or maybe it can be hacked around in unwanted control  just at the feature there, like, yeah, use those names or that kind of thing.  If you don't, well, you probably won't have a touch-perfection on Unreal.  The only way to get around that is just on the point at zero  and arrange for a change route where you have access to the service PSD.  Or you can treat ledger non-vehler annotations  to figure out how your own sandboxing facility can approach this.  We have a question about the captive portal.  Oh.  Specifically, what part of the loop?  I can't hear who it says.  What's the point?  What does it do with the knowledge that it's got in the captive portal?  Oh, it talks to the DMC people who added the names over.  Can you answer that question?  Oh, sorry.  The question is, why is there a captive portal detection?  So, if you point yourself behind a captive portal and you decide,  I do my own recursion, then you might end up in a situation where you don't get the,  yes, I accept your terms of services page.  So, for as long as you're behind a captive portal, you treat it as DNS is completely failing locally?  Yes.  That's what I'm trying to figure out.  That's not doing any of the main pages.  Sorry.  So, then does it switch the entire system resolver over  and then keep checking the, do I have access to the internet page using the other resolvers?  Or, when does it switch back after it notices the captive portal was passed?  If that's one part of the re-auditly.  Yes.  The re-auditly re-checks, it does get requests and when it gets the response that it wants,  then it switches to whatever you have configured.  So, if switching to the DHCP name servers makes the internet work,  then does it start realizing the page works and then switch off halfway through the terms and services page?  No, no, no, no.  Because when you get the terms of services page, the internet is just, it's not working yet.  So, if you, in the background, it does get requests through the configured checker  and when you have not clicked the thing yet, it will get back,  no, no, no, you're not talking to the internet.  There's no race to lose.  Oh.  Yeah.  I think that was done with this one.  Huh.  It's a good idea to do it well.  Subtutor work.  We had this, this good idea that we want to have this broadcast mechanism where all the  sources that tell us, here's the name server that you can ask,  can convert.  So, we currently parse DHCP release for that structure.  What are we doing with router advertisements that give us every six name servers?  What are we doing with the 4G model that gives us a completely horrible way of the name servers?  The idea is to just put this on the router, so I can do this on this,  and we get the information out of there.  If we have that, then it kind of gives us the name server from the router,  the password server for free.  Some people point out that you need per network configuration.  So, you're wandering around, you're at home, you're traveling,  everything is nice, you're the only curtain, then you come to the office  where they do the same called spitorizing DNS.  It's kind of like the Catholic portal where if you want to resolve certain things,  you can talk to the DHCP provider names, it was like you entered the office,  you want to print. The printer is only resolvable by talking to these things.  So, it should be possible to detect this situation.  There are multiple ideas on how we can do this.  The first one that I'm going to implement, and I'm halfway there,  is it sees to which SID you're connected, and it just uses a different config.  Another idea was, and this gets more and more crazy,  look on what layer 3 address your gateway is.  Look on which layer 2 address your gateway is.  After 40 modems GPS where you are.  No, we're not implementing that one.  Actually, there's a different approach.  I'm going to do a quick work, I'm going to be speaking off the top here.  What I'm thinking of my emphasis is very functionally speaking,  is it builds the same niche as Linux's system view resolv-  Sorry?  System view resolv-  Nope, the older one from the new option at NUK,  totally bring it back here.  The little mini resolver that is actually brain dead,  the only purpose in life is to go out and talk to other names or other subjects.  We've all used it in one way or another.  The master key thing.  What's that?  Yeah, that's my answer.  Yeah, that's my answer.  Thank you.  Yeah, that's my answer.  One thing that might solve this summary problem is that it has a lot of algorithms.  It asks every resolver he knows about the same question all at once.  Right, yes.  I know.  Which, as a network operator, I have problems with this,  but other hoods like the Japanese pre-damp small,  and if it's set up per network config to learn which,  because you have to keep track of what run domain connection was coming in on,  you have to keep track of the shitloads of parameters,  so you can easily ask everyone,  and your config file says,  if you see this nameserver, trust it first.  Yes.  Yeah, we can, oh yes, we can also,  we can also do it all fine on the nameservice,  which is like the three address gateway,  the three address of the nameserver,  we can do that.  Okay, I actually considered this,  but this is just a privacy nightmare.  But since we now have a config file, why not?  Like, if the operator really puts this in and they want this,  code lines this is not difficult to do.  But, yeah.  Well, the other advantage is I've been in many, many, many hotels  where the primary nameserver in the HTTP gives you is, you know,  upwards of two seconds per station time,  and the secondary results in under 100 milliseconds.  Oh, this is solved.  Maybe I should repeat one of these.  So the comment was you get two PHP nameservice,  the first one is terrible and the second one is actually okay.  Lip and non does the right thing there.  Lip and non does the parallel queries.  So we are good there.  We're worried.  Yes.  I must admit I find I do home detection at home right now,  but I just need a background loop  resolving in the internal address.  So it's, that would effectively be the same thing.  Yep.  Many ways to do this.  So yeah, this certainly, I suppose ideas will come up.  So first I will implement the SFID idea and then we'll see.  Yeah, first to the SFID idea then people are like,  oh yeah, I can totally detect my network this way,  or I can detect the pathway.  I got to take the whole thing so that we can implement.  But kind of in this vein is,  oh I'm connected to a VPN and I don't need to talk,  but I want all my queries over there to the VPN.  It's kind of the same thing.  Another issue that we need to, that we want to do,  so it keeps the histogram on how well this performs  around foot-wise.  It would be nice if we could switch.  I have not quite figured out the math on how to actually do this.  When should we switch?  It's actually terrible.  I mentioned that we need a confi file for the capital portal  and I suspect that a lot of people want that,  so it would be needed to have a built-in URL.  But this really is the bike-shot from hell.  Like, people can't agree on this.  Off-server.  No, no, no.  And the other thing is, on one of the slides  I hope this is saying a dust-optimistic DNS-like validation.  The idea here is that it detects that DNS-like actually works  and then uses it.  The problem is, it is too optimistic in this.  When it starts to fail and the detector fails,  well, it stops doing it, which is a trivial downgrade.  So the idea that we want to implement is,  if you're in a network and the background detects DNS-like works,  it pins it to DNS-like must-work here.  You cannot downgrade it.  Only when you move networks, it needs to detect that you move to a different network,  then it does a reprope again.  Or maybe you really, really know that DNS-like must-work.  We can also provide a config option to never allow a downgrade in that sense.  But then you're again on your own, so you kind of lose some clarity there.  Because once you move to a network where it doesn't work,  then you need to fiddle again with it.  It's a trade-off, I guess.  More questions?  Yes, please.  Are you aware of an on-line lab DNS-like trigger  and or are you more prepared for it?  What are the problems?  The question was, am I aware of an on-line lab DNS-like trigger?  Was it a coding DNS-like trigger?  Yes.  The implementation is unbound for the bit of magic that detects  an HTTP, whether there is a captive portal and a loss to  an enabled validation over a DOT, for example.  I was not aware of this, though.  It exists as a practices for Windows for Mac for Linux.  Okay, thank you.  Yes.  How do you decide, or do you decide whether to do  genome minimization or not, or do you leave that out to do it or not?  The question was, when do we decide to do genome minimization?  And the answer is, we leave it out to the band-monger.  It seems to do this correctly.  Another question, right away?  Yes.  Are you going to, or are you going to talk about some form of indication  to the user, I don't know, that DNS-like validation  has been disabled to a downgraded?  Yes.  The question was, is there any indication to the user that DNS-like  validation has been downgraded?  So, on a protocol level, it does the right thing.  It does not have to have a claim in the flags that this was  actually a validated answer, which is not a terribly good  user, in any case, because you can't see this.  You can also see it in the control process, with the control  tool.  You can ask, live on, sorry, you can ask online, what are you  currently doing, what are the states?  So, it shows you this.  It can actually talk to the internet.  And you get a validating answer, nothing that's  appearing, it also gives us USB network that are also  validating, and apparently everything, what do you want  doing that?  I was told that everything about 1024 is evil in this room.  So, this is trying to talk to 843, which is apparently also  evil, so that gets blocked.  Does that have a, is there a machine-partial version of this?  Sorry, you go ahead.  Is there a machine-partial version of that output?  No, but if you want to, so it speaks a specific binary  protocol, and this can be implemented, or we can  implement it here that it's a machine-partial.  Because for people that use things like i3 bar, it would be  interesting to have a condensed version of that in your  status card.  Yes.  You can just talk on the online CTLs, I'll go through this.  Yeah, yeah, yeah.  So the question was, is there a machine-partial output for  this, and 4.4, like your window manager, because, yeah.  Why would you run the control program on my hand, that's  you'd really need to have this more in your face that  something happens.  Sorry, we're there.  I was going to point out that is anything except  8, 4.4, 3, and 22, and it's quite less than, not lackluster,  especially as the region I have.  Well, soon as we all work on the wife, we'll be here with  them, we'll not be by the day.  There's one point where you talked about the  counter-portal reduction, you said this is the  buddy-shed from hell.  Yes.  Can you adopt a solution like, for example, the  system.  Which simply calls the shell script.  Do whatever the hell you want in the shell script.  Return me some.  No, no, no, no, no, no, no, no, no, no, no, no, no,  sure we could do that, but that does not solve the  problem.  What we want is to have this work automatically without  a contract file.  Oh.  Build in the URL, check this URL.  You can't choose to which evil court you want to talk to.  They all have one, but we cannot agree on to which  one we talk.  Everybody has one opinion.  No, no, no, no, no, no, no, no, no, no, no, the other  one.  No, no, no, no, no, no.  We need to talk to the end.  What happened?  I don't know.  I don't understand what you said.  Ah, okay, okay.  Anything else?  Where is the log?  Log?  Yes, just look.  Do you mean query loggy?  No, just go to the spark.  Yeah, yeah.  Is there a problem with the query log?  Is there a problem with the query log?  It also goes to the search log.  The question was, is there a where does query log go?  And yes, it goes to the search log.  You need to correct the invibosity to higher.  So this broke something I use at home when I turned it on  and I like it elsewhere.  At home, I redirect all my resolvers in Google to my local  recursive resolver running unbound on my gateway,  which then has a giant list of logon filters on it,  murders all of Google AdWords, Alversites, etc.  This affects the group around that for being at home.  No, it's not at home. I like it because I don't block DNS out.  Short of blocking the external resolver,  which I could do on my guest network,  that's actually probably the best solution for me  is to actually just dump all 53 of my guest network  and then it would probably, then it would just fall back  to using my local resolver which is just fast  and I'd be happy.  I guess I should just outright block 53.  That's one option or the feature where it detects where you are.  Yeah, and I can change.  So if you would fill it with a preference there,  you would just pull out the QCP one.  Also, there was a hacker fund going on before here  and I implemented a block list and unwinded it as well.  So I could suck up my same block list.  Which is a bit silly for you to use, I guess,  but then you also have it on the road.  Yeah, on the road.  How far away is this from being usable  for not just my own personal use on a laptop,  but being a useful, defaulting name server  for, say, 9,400,000 users?  It will never be, no.  That's not the point.  So if you have 4,000-1,000 users, run unbound  or about whatever you want.  Do you control the network?  So unbound has the...  Well, you kind of maybe should.  So what unbound is trying to do,  and there's also optimization going on in this direction,  it assumes a certain quality of the network,  which you, it runs on the data, it runs on the server.  If you then try to show this on your laptop,  that's where you run into problems,  because it assumes everything is shiny.  There's a sysadvent who constantly does things to it.  When that fails, you're in trouble and you start fiddle with it.  This is the niche that unwind wants to solve.  So it will never try to replace that.  I think we're going to kick it over here.  So...  Thank you.  Thank you.
unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_0_107.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_108_203.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_204_311.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_312_1007.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_1008_1139.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_1140_1571.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_1572_2111.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_2112_3347.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_3348_4031.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_4032_4607.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_4608_7643.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_7644_8567.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_8568_8711.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_8712_8963.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_8964_9671.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_9672_10031.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_10032_11459.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_11460_11771.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_11772_11987.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_11988_12047.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_12048_12515.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_12516_13043.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_13044_13091.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_13092_13163.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_13164_13319.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_13320_13427.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_13428_13511.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_13512_13727.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_13728_13787.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_13788_15047.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_15048_16391.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_16392_18923.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_18924_19043.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_19044_20483.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_20484_22643.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_22644_24035.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_24036_24371.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_24372_26459.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_26460_27227.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_27228_28559.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_28560_28739.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_28740_29423.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_29424_30191.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_30192_31055.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_31056_31127.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_31128_31259.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_31260_31523.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_31524_31643.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_31644_31811.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_31812_31919.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_31920_33779.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_33780_36155.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_36156_36275.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_36276_36611.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_36612_36851.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_36852_36995.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_36996_37655.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_37656_38615.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_38616_40775.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_40776_41531.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_41532_44315.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_44316_45767.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_45768_47291.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_47292_48635.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_48636_48719.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_48720_51419.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_51420_56615.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_56616_64115.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_64116_64163.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_64164_64247.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_64248_67595.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_67596_70823.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_70824_73763.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_73764_79799.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_79800_80279.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_80280_80327.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_80328_80375.png unwind_8__A_privilege-separated__validating_DNS_recursive_nameserver_for_every_laptop_88SoI49nO4o_80376_80381.png