WEBVTT 00:00.000 --> 00:13.920 So about, so two years ago, exactly my colleague Martin presented here about Domain, and 00:13.920 --> 00:17.920 if I now look at what I've been in the slides, then it's like, wow, it's the only two years 00:17.920 --> 00:19.920 ago. 00:19.920 --> 00:27.000 So I mean, it was a very nice introduction of how Domain came to be, so if you didn't 00:27.000 --> 00:34.920 see it, then he used a link to that session, very short summary. 00:34.920 --> 00:41.480 He started Domain as a side project experiment with last, to an experiment with DNS. 00:41.480 --> 00:47.680 And basically two years ago, there was a basic messaging, DNS messages and all kinds of 00:47.680 --> 00:57.040 types was all available in Domain create, and a bit before that time, it only 00:57.040 --> 01:03.200 we said, well, what if if we do the new DNS application, we're doing it in Rust, what 01:03.200 --> 01:04.800 would it need? 01:04.800 --> 01:09.840 So also, well, we keep NSD, everything not go to the right, that keep on balance, not 01:09.840 --> 01:15.040 go to the right, that maybe we will have new applications to that in Rust. 01:15.040 --> 01:20.480 So we made some plan, and it was like, well, we need to do that next to our existing works, 01:20.480 --> 01:26.160 and it was more like a 5 year plan, what is the stuff that we would like to have to start 01:26.160 --> 01:27.160 writing applications. 01:27.160 --> 01:32.480 We didn't have a clear idea of what, so we just make it into generically stuff, this 01:32.480 --> 01:36.560 you would probably need. 01:36.560 --> 01:42.080 So this is just my personal opinion, what Domain should be, I mean, I don't think we 01:42.160 --> 01:49.680 ever set an official vision for Domain, but to put some dot on the horizon, just say that 01:49.680 --> 01:55.520 it needs to be the most complete DNS libraries, so whatever there isn't DNS, eventually, 01:55.520 --> 01:58.800 it should be available in Domain. 01:58.800 --> 02:04.400 We want to have high performance, we want to be able to build high performance applications, 02:04.400 --> 02:11.040 so we want to have a low level of primitives that really allow us to optimize for performance, 02:11.040 --> 02:16.880 but at the same time, if you want to quickly write an application that needs some DNS, 02:16.880 --> 02:21.040 then you shouldn't be sort of bogged down by all kinds of details, there should be nice high 02:21.040 --> 02:28.640 level primitives, so it's a bit of a tension, like how do you maintain that in a single library. 02:28.640 --> 02:34.160 And a third one is it should be the foundation for our Rust-based DNS applications, 02:35.040 --> 02:42.720 because in C, we have the curious situation that we have C library for DNS, called LGNS, 02:42.720 --> 02:47.920 and then we have NSDN unbound and they both don't use that library, so unbound has sort of 02:47.920 --> 02:53.760 it own copy of the library, but they're completely different API, so we don't want that for us. 02:53.760 --> 03:06.880 So then what happened was that STF grants became available, and we said, well, 03:06.880 --> 03:12.640 let's take all of this five-year work and separate the proposal for a lot of money for one year, 03:12.640 --> 03:19.200 and then see what happens, and then we got accepted, so suddenly we had to do a lot of work in one 03:19.200 --> 03:27.920 year, and that was 2024, and then it turned out in 2025 that what we really need to have 03:27.920 --> 03:33.600 is a new DNS sign that will replace open DNS access, so we started working on cascade, 03:33.600 --> 03:39.440 and that is good because cascade is then a real-world application that forces domain to work, 03:39.440 --> 03:55.600 because it doesn't work, you don't have a sign, so this is just schematic of the sort of work 03:55.600 --> 04:00.400 that we envisioned, it's like, okay, you need to be able to send requests, so you have client transport, 04:00.400 --> 04:06.480 you need to be able to receive requests and handle them, so server transport, we need to do something 04:06.480 --> 04:14.560 with a DNS sign, we wanted to have a sort of a DNS, very application that we called DNS, I 04:16.560 --> 04:24.480 had a big vision for that, and we also wanted to get rid of L DNS, I get later in what sense, 04:24.480 --> 04:32.160 and so we said, well, we need to have DNS T, so we put that all in the grant proposal, 04:33.120 --> 04:39.440 and then for a client transport, it's like, oh, well, you sent a UDP packet and you get a reply, 04:39.440 --> 04:47.760 oh my, what do you expect, and it turns out it's a surprisingly rich, so the first data 04:47.760 --> 04:55.440 grant is indeed doing UDP, but it's like, maybe you don't always want UDP, we have a 04:56.400 --> 05:02.480 testing framework called Stairline, and that just short circuit's it, but it hooks into the 05:03.280 --> 05:09.280 all of the DNS stuff you have for data grant, but you can also say that maybe I want to have a specific 05:09.840 --> 05:16.240 UDP thing, like maybe I'm on the wrapper that collects the testics, or I want to bind to specific interface, 05:17.040 --> 05:21.520 so you can define your own object that does UDP and then you hook it in and then it works, 05:22.080 --> 05:28.800 and then we do the same thing for String, because from a DNS point of view, TCP and TLS, 05:28.800 --> 05:33.840 basically look the same, so you can be generic over that, and it also does eggs of fun and 05:33.840 --> 05:41.120 eggs of fun, over that, and then when you have such a TCP connection, then it is annoying, 05:41.120 --> 05:46.480 because if the TCP connection is open for a wild and idle, and the client is supposed to close it, 05:46.480 --> 05:52.320 but the server may also close it, you don't have to bother an application with that, so we have 05:52.320 --> 05:58.480 a multistream that basically says, well, virtually just a single TCP connection, but under the 05:58.480 --> 06:05.360 hood, you will get a new one when you need it, and if you then combine the multistream with the 06:05.360 --> 06:12.960 data grant one, then you get what we traditionally think as DNS over point 53, because you send 06:13.040 --> 06:19.920 a request over UDP, then make it a Tring clear, it is a bit set, and then you have to continue 06:19.920 --> 06:29.120 of a TCP. Then it is nice to have something like a cache, and it is nice if the cache looks 06:29.120 --> 06:35.680 like a transport, because then you can just have your existing code that generates requests and 06:35.680 --> 06:42.240 looks at replies, but there is a cache in the middle, in case you send similar queries more often. 06:43.680 --> 06:51.920 Then you find that resoul for my IPv4 and IPv6 address, or you may have not a port resoul for 06:51.920 --> 06:56.960 them, but to talk to that. So, they don't, basically says, well, you've got a bunch of addresses, 06:57.840 --> 07:04.640 it keeps the test takes in it, try to talk to the fastest one, but you can also go the other way 07:04.640 --> 07:08.960 around to say, well, I have a bunch of things that all do exactly the same thing, and I want to 07:08.960 --> 07:13.120 make sure that the loads get sort of even lead to stability over everything that works, 07:13.120 --> 07:21.040 if the load balancer. Finally, we have T-sake, because well, if you want to do a zonesense for 07:21.040 --> 07:29.840 or an update, or notifies people like to have this stuff signed. So, a nice collection of client 07:29.920 --> 07:37.360 transports for all of the TNS queries. Then you get sort of the opposite for surface, 07:38.640 --> 07:47.680 with a bit of a different structure, you get the TCP and TLS transports that are all sort of 07:47.680 --> 07:55.920 a bit simpler than the client path, but you want to have some generic code that handles a cookies, 07:56.240 --> 08:05.680 we have some notify middle-werving that can talk to a zone maintainer, and then tell the zone 08:05.680 --> 08:11.680 maintainer. Oh, you've got a notify, maybe you want to refresh this zone. Of course, you want T-sake again, 08:11.680 --> 08:20.880 and you also need to do special things with AXFAR and AXFAR. And then sort of, as a part of 08:20.880 --> 08:28.000 where we would like to go, but we have no real idea yet, is that if you get a request, 08:28.000 --> 08:33.520 then maybe some things are local zones, some things should go, we'll do this upstream or that upstream. 08:33.520 --> 08:41.600 So, we have a simple query router, just based on QNN, but in the real world, people root queries 08:41.600 --> 08:48.400 on lots of other stuff, and we have to figure out how to really make that available to applications. 08:48.480 --> 09:02.000 Okay, then DNS-sake, a DNS-sake, validator for messages, basically you give it a reply, 09:02.000 --> 09:08.960 and it says, well, this reply was secure in secure in determinant or bogus, and then you can do this 09:08.960 --> 09:18.880 a validator also, again, as a client transport, where it turns bogus into surfail unless CD is set, 09:18.880 --> 09:25.600 and it sets AD when it's secure, and then you just connect this validator into whatever other 09:25.600 --> 09:32.480 client transport configuration or that you had, and suddenly all your replies are DNS-sake validated. 09:33.440 --> 09:39.360 So, this validation, the signing, you need to build and sack and sack free chains, 09:39.360 --> 09:46.240 and you need to sign the zone, then we've figured out that if you want to do some signing, 09:46.240 --> 09:52.560 you need to have some sort of key management, and we wanted to move part of the key management, 09:52.560 --> 09:58.560 especially the key roles into the library, while at the same time, not lockering us into 09:59.520 --> 10:06.000 what say, whether the DNS-sign-i key is stored on disk or in the HSM, or something like that, 10:06.000 --> 10:12.400 and it's a pretty generic thing that doesn't, that only has sort of a concept of keys, 10:12.400 --> 10:18.640 and then tells the application, like, now you need to cross-stract a DNS key RR set with the following keys, 10:18.640 --> 10:25.760 or you need to sign something with those keys, or the NS record, and then the library should figure out 10:25.760 --> 10:33.600 how to actually do that with the right bits. And we have two crypto-beckens at a moment, 10:33.600 --> 10:40.640 there is a rust thing called ring, that can do a lot of stuff, and the nice thing is it's written 10:40.640 --> 10:49.200 in rust, but it's not complete, and then we have open SSL, which is also complete, but on some 10:49.200 --> 10:56.560 platforms it's a pain to build, and you can also get problems that the rust open SSL bindings 10:56.560 --> 11:03.200 bind to basically everything, so when you compile the application and that, for example, an open 11:03.200 --> 11:10.720 BSD, that our code doesn't work, because we assume that open SSL has a ADR for 8, I think it is, 11:11.280 --> 11:16.160 and then the library, SSL doesn't have that, and then the people complain and stuff like that. 11:17.120 --> 11:23.440 In any case, and then the upcoming rust thing called Graviola, that when that's ready, 11:23.440 --> 11:28.960 then you probably add this a beckon, but we could add other beckons as well. 11:32.880 --> 11:38.560 So DNSI, we had big vision for that, and that is, we want to have a command like tool, 11:38.640 --> 11:47.440 that can really tell you about DNS stuff from your command line and sort of be smart about it, 11:48.720 --> 11:53.920 and then what we shouldn't, didn't have the time, so we started doing a deck like thing, 11:53.920 --> 11:59.760 and now it's still a deck like thing. We try to make the output more user-friendly, so maybe that 11:59.760 --> 12:05.200 helps, but still efficient for the future is we want to do smarter things like, 12:05.280 --> 12:08.960 I don't know, maybe it can tell you why your DNS sec is broken, or something like that. 12:11.360 --> 12:18.560 So for L DNS, it's a library, and we want to get rid of that library, because it doesn't have 12:18.560 --> 12:26.240 a particular nice API. If you use it from C, it's very easy to make all kinds of annoying mistakes 12:26.240 --> 12:33.520 and stuff like that, and it's not that much user-friendly, but it's not like the whole world 12:33.600 --> 12:42.160 is running on L DNS. One problem is that L DNS, the library, comes with example programs, 12:43.280 --> 12:48.800 and people with understood example programs and they use them in production, and I'm also guilty 12:48.800 --> 12:55.200 of that. I mean at home, I'm running a home, crown DNSic signer that is written around L DNS sign, 12:55.200 --> 13:00.720 so, so we realize that if we don't want to make a lot of people very miserable, 13:01.680 --> 13:06.240 then if we say, L DNS is going away, then we need to have replacement for the L DNS utilities. 13:07.600 --> 13:16.000 So that is basically what DNS T started out. It has some of them, I'm plan to do more of them, 13:16.720 --> 13:21.760 and then when you call them with the L DNS name, then they have the same options, and we try to 13:21.760 --> 13:27.760 make it as competitive as possible. It's not 100% the same, but roughly it's the same. 13:28.240 --> 13:36.320 And then if you call it with the DNS T name, then you get the sort of utility, but you get 13:37.120 --> 13:42.320 more than a command line flags and other clean up and other options and stuff like that. 13:44.320 --> 13:55.360 And now we add it one new utility to that DNS T thing that is not in L DNS, and that is 13:56.240 --> 14:06.160 a DNSac key manager, and that is basically taking this code in domain for key management, 14:06.160 --> 14:14.160 and then makes it into a concrete application that can do key roles and all that kind of stuff, 14:14.160 --> 14:19.360 so that if you build a DNSic signer, then the key manager is already taken care of. 14:19.680 --> 14:35.440 Okay, so there was 2024. 2025 started working on cascade, the signer, bumping the wire signer, 14:35.440 --> 14:41.920 so it means it receives a zone file, either a file or X of R, X of R, X of R. Signs it, 14:42.000 --> 14:50.240 makes it a failable as X of R. We explicitly put in review hooks for the signed and unsigned 14:50.240 --> 14:55.600 zone, so when you unsigned zone, first in of the unsigned zone comes in, review hook gets called 14:55.600 --> 15:02.560 user can check like, do I have a sensible set of data, maybe it's a tiny zone, now when there's 15:02.560 --> 15:07.360 something went wrong, I don't want to sign it, you could put in some special records, check whether 15:07.440 --> 15:13.520 they are there, for sign, you can check whether the sign zone matches the unsigned zone, 15:13.520 --> 15:20.640 whether it has a fillet, insect chain or kind of stuff, and only when those review hooks return 15:20.640 --> 15:27.280 through, then you say, okay, you can surf that. Well, it uses external key manager, that I just described, 15:28.080 --> 15:36.400 and that we may also at some point integrate one as well, and we also find out as part of sort of 15:37.280 --> 15:45.120 real-world annoyances that people write to spend a lot of money on a box, and that box can 15:45.120 --> 15:52.400 do signing and it's signed slower than if you just do it in the application, and it costs a lot 15:52.400 --> 16:01.280 of money and people want to use that. And that is still fine, and now this expensive box comes 16:01.280 --> 16:07.520 with a binary block, and you're supposed to load this binary block in your program, and they're 16:07.520 --> 16:14.560 called that PKCS11, and then they say, well, you just call it, and so we have a hardware manufacturer 16:14.560 --> 16:18.880 that has a close source thing, and they give you a binary, what could possibly go wrong. 16:19.680 --> 16:26.400 So everything does go wrong, and we said it, okay, no way, we don't want this, we have a nice 16:26.400 --> 16:31.840 rest application, we're not going to load this stuff in a nice rest application. So we said, okay, 16:31.840 --> 16:36.720 we need to run that just in a different process, if it was a different process, crashes, it's still annoying 16:36.720 --> 16:42.560 that them can tell the user like, sorry, see, there's your problem, you have a weird HSM, 16:42.560 --> 16:50.480 you can figure out how to deal with that, maybe you generate some test traffic, and see how it 16:50.640 --> 16:56.720 crashes, or something like that. And then that was all good, and it is like, okay, now we need 16:56.720 --> 17:03.440 to talk to it. So, of course, we just design a new communication protocol to talk to that, 17:03.440 --> 17:10.480 well, maybe not, because there's an existing one called KMIP, and then nobody using it uses that. 17:10.480 --> 17:15.520 It's essentially now HSM's that do it, there's no application that you thought, okay, well, 17:15.520 --> 17:22.240 maybe instead of reinventing a new network protocol, we use a standard one, it's still relatively 17:22.240 --> 17:29.280 annoying, because I mean those protocols are weird, but we got it to work, and then we got into 17:29.280 --> 17:35.440 the heart part of computer science, we had to give it a name. So, so we have gone through many 17:36.160 --> 17:41.120 a names, and then we settled on the most descriptive one, and that this KMIP took PICCUS, 17:41.440 --> 17:49.200 11, which is fine, except you can type it unless you type it every day, and you can't pronounce it. 17:50.480 --> 17:56.960 So, now, recently, we have to decide to dig deep into the Lord of the Rings and come up with more 17:56.960 --> 18:06.640 fun, so now people can tell us whether they like that or not, any case, that's a cascade, 18:06.800 --> 18:16.480 before cascade, we started with cascade, also during cascade, and we learned that there's some 18:17.280 --> 18:24.960 parts of domain that are not very pleasant, domain has an octet abstraction, and I give you a bit of 18:24.960 --> 18:30.240 code that you may have for right now, and it's just a complex, we would say, okay, we want to use 18:30.320 --> 18:37.120 domain, we understand this stuff. We created a surfer middleware layer, and it's also to complex, 18:38.800 --> 18:44.480 and it's also like, okay, if you now look at domain, there's some stuff that you could do more 18:44.480 --> 18:51.440 efficiently, if you would read a cliché in the interface of some things. So, together that we decided, 18:51.440 --> 19:02.080 okay, we need to just rewrite the base DNS types, will be very unpleasant, but we need to do that 19:02.080 --> 19:12.960 to move forward. So, then we get to the plan for sort of the coming here, we need to make a 19:12.960 --> 19:20.160 production release of cascade, and we released an alpha last october, and then we got some 19:20.160 --> 19:26.480 really enthusiastic testers who created lots of issues, so we got a lot of stuff to fix, 19:27.280 --> 19:30.560 and now we need to fix all of that and get to in the production release. 19:31.920 --> 19:39.840 Like I mentioned, we need to do sort of the base of domain, and then out of cascade work, 19:40.720 --> 19:47.520 follows like, okay, we really would like to load some files very fast, so we probably want a new 19:47.600 --> 19:54.800 zone file parser, certainly in cascade, but trying to move that back to domain, and cascade leads to 19:54.800 --> 20:02.000 a really interesting zone file storage, because you constantly get all kinds of diffs, like you get 20:02.000 --> 20:08.000 an x-ifier with a new enzyme zone, and you need to sign that, and you want to cleverly keep that as 20:08.000 --> 20:15.600 a diff, so you can serve it again as an x-ifier, so we need to have a new internal way of storing 20:15.680 --> 20:24.000 zones that then hopefully also can migrate back to domain, and we can work on TNI, or that's 20:24.000 --> 20:29.680 it have been TNST, and me, more is a simple proxy that we have to experiment with looking up 20:29.680 --> 20:34.560 these server parts in the client part and the query routing, and all that kind of stuff. 20:37.280 --> 20:45.200 Then, now, sort of the moment where I would ask you, like, we want to have a DNS library that is 20:45.280 --> 20:51.360 useful to the open source community, and we know what we want for our own applications, 20:51.920 --> 20:58.640 but if there's stuff that you want from a DNS library, then please let us know, 21:00.240 --> 21:08.080 and then we can take it into account for how we evolve domain, so that's it for me. 21:15.280 --> 21:23.040 Okay, so the comment is, I felt for the update, and six-year-old, good. 21:23.040 --> 21:31.760 Is there a ability to request TLS connection with client out of the application set that 21:32.400 --> 21:36.320 certificate already, and if not, would it really possible to edit? 21:36.400 --> 21:48.000 Yeah, my question is, is there a possibility to set up a TLS connection with client authentication? 21:48.960 --> 21:58.560 And I think, but I never tried it, because we abstract over TCP and TLS, as an application, 21:58.560 --> 22:05.440 you can submit your own TLS connector, basically, and if that has a client certificate, 22:05.520 --> 22:09.520 then it should just work, but I never tried it. 22:24.000 --> 22:31.440 I don't know if we don't release, we haven't released a lot of this, so it's not on a regular 22:31.440 --> 22:36.720 other question is, I installed DNS, I, with Cardinal installed, can also do that with TLS T, 22:37.440 --> 22:44.720 and that is, so we're really behind publishing this, so if you want it it's better to just get 22:44.720 --> 22:51.440 clone the repo and then do a Gargo built, then trying to do the install, we may have to release 22:51.440 --> 22:53.600 one version, but if we did, it is very old.