So about, so two years ago, exactly my colleague Martin presented here about Domain, and
if I now look at what I've been in the slides, then it's like, wow, it's the only two years
ago.
So I mean, it was a very nice introduction of how Domain came to be, so if you didn't
see it, then he used a link to that session, very short summary.
He started Domain as a side project experiment with last, to an experiment with DNS.
And basically two years ago, there was a basic messaging, DNS messages and all kinds of
types was all available in Domain create, and a bit before that time, it only
we said, well, what if if we do the new DNS application, we're doing it in Rust, what
would it need?
So also, well, we keep NSD, everything not go to the right, that keep on balance, not
go to the right, that maybe we will have new applications to that in Rust.
So we made some plan, and it was like, well, we need to do that next to our existing works,
and it was more like a 5 year plan, what is the stuff that we would like to have to start
writing applications.
We didn't have a clear idea of what, so we just make it into generically stuff, this
you would probably need.
So this is just my personal opinion, what Domain should be, I mean, I don't think we
ever set an official vision for Domain, but to put some dot on the horizon, just say that
it needs to be the most complete DNS libraries, so whatever there isn't DNS, eventually,
it should be available in Domain.
We want to have high performance, we want to be able to build high performance applications,
so we want to have a low level of primitives that really allow us to optimize for performance,
but at the same time, if you want to quickly write an application that needs some DNS,
then you shouldn't be sort of bogged down by all kinds of details, there should be nice high
level primitives, so it's a bit of a tension, like how do you maintain that in a single library.
And a third one is it should be the foundation for our Rust-based DNS applications,
because in C, we have the curious situation that we have C library for DNS, called LGNS,
and then we have NSDN unbound and they both don't use that library, so unbound has sort of
it own copy of the library, but they're completely different API, so we don't want that for us.
So then what happened was that STF grants became available, and we said, well,
let's take all of this five-year work and separate the proposal for a lot of money for one year,
and then see what happens, and then we got accepted, so suddenly we had to do a lot of work in one
year, and that was 2024, and then it turned out in 2025 that what we really need to have
is a new DNS sign that will replace open DNS access, so we started working on cascade,
and that is good because cascade is then a real-world application that forces domain to work,
because it doesn't work, you don't have a sign, so this is just schematic of the sort of work
that we envisioned, it's like, okay, you need to be able to send requests, so you have client transport,
you need to be able to receive requests and handle them, so server transport, we need to do something
with a DNS sign, we wanted to have a sort of a DNS, very application that we called DNS, I
had a big vision for that, and we also wanted to get rid of L DNS, I get later in what sense,
and so we said, well, we need to have DNS T, so we put that all in the grant proposal,
and then for a client transport, it's like, oh, well, you sent a UDP packet and you get a reply,
oh my, what do you expect, and it turns out it's a surprisingly rich, so the first data
grant is indeed doing UDP, but it's like, maybe you don't always want UDP, we have a
testing framework called Stairline, and that just short circuit's it, but it hooks into the
all of the DNS stuff you have for data grant, but you can also say that maybe I want to have a specific
UDP thing, like maybe I'm on the wrapper that collects the testics, or I want to bind to specific interface,
so you can define your own object that does UDP and then you hook it in and then it works,
and then we do the same thing for String, because from a DNS point of view, TCP and TLS,
basically look the same, so you can be generic over that, and it also does eggs of fun and
eggs of fun, over that, and then when you have such a TCP connection, then it is annoying,
because if the TCP connection is open for a wild and idle, and the client is supposed to close it,
but the server may also close it, you don't have to bother an application with that, so we have
a multistream that basically says, well, virtually just a single TCP connection, but under the
hood, you will get a new one when you need it, and if you then combine the multistream with the
data grant one, then you get what we traditionally think as DNS over point 53, because you send
a request over UDP, then make it a Tring clear, it is a bit set, and then you have to continue
of a TCP. Then it is nice to have something like a cache, and it is nice if the cache looks
like a transport, because then you can just have your existing code that generates requests and
looks at replies, but there is a cache in the middle, in case you send similar queries more often.
Then you find that resoul for my IPv4 and IPv6 address, or you may have not a port resoul for
them, but to talk to that. So, they don't, basically says, well, you've got a bunch of addresses,
it keeps the test takes in it, try to talk to the fastest one, but you can also go the other way
around to say, well, I have a bunch of things that all do exactly the same thing, and I want to
make sure that the loads get sort of even lead to stability over everything that works,
if the load balancer. Finally, we have T-sake, because well, if you want to do a zonesense for
or an update, or notifies people like to have this stuff signed. So, a nice collection of client
transports for all of the TNS queries. Then you get sort of the opposite for surface,
with a bit of a different structure, you get the TCP and TLS transports that are all sort of
a bit simpler than the client path, but you want to have some generic code that handles a cookies,
we have some notify middle-werving that can talk to a zone maintainer, and then tell the zone
maintainer. Oh, you've got a notify, maybe you want to refresh this zone. Of course, you want T-sake again,
and you also need to do special things with AXFAR and AXFAR. And then sort of, as a part of
where we would like to go, but we have no real idea yet, is that if you get a request,
then maybe some things are local zones, some things should go, we'll do this upstream or that upstream.
So, we have a simple query router, just based on QNN, but in the real world, people root queries
on lots of other stuff, and we have to figure out how to really make that available to applications.
Okay, then DNS-sake, a DNS-sake, validator for messages, basically you give it a reply,
and it says, well, this reply was secure in secure in determinant or bogus, and then you can do this
a validator also, again, as a client transport, where it turns bogus into surfail unless CD is set,
and it sets AD when it's secure, and then you just connect this validator into whatever other
client transport configuration or that you had, and suddenly all your replies are DNS-sake validated.
So, this validation, the signing, you need to build and sack and sack free chains,
and you need to sign the zone, then we've figured out that if you want to do some signing,
you need to have some sort of key management, and we wanted to move part of the key management,
especially the key roles into the library, while at the same time, not lockering us into
what say, whether the DNS-sign-i key is stored on disk or in the HSM, or something like that,
and it's a pretty generic thing that doesn't, that only has sort of a concept of keys,
and then tells the application, like, now you need to cross-stract a DNS key RR set with the following keys,
or you need to sign something with those keys, or the NS record, and then the library should figure out
how to actually do that with the right bits. And we have two crypto-beckens at a moment,
there is a rust thing called ring, that can do a lot of stuff, and the nice thing is it's written
in rust, but it's not complete, and then we have open SSL, which is also complete, but on some
platforms it's a pain to build, and you can also get problems that the rust open SSL bindings
bind to basically everything, so when you compile the application and that, for example, an open
BSD, that our code doesn't work, because we assume that open SSL has a ADR for 8, I think it is,
and then the library, SSL doesn't have that, and then the people complain and stuff like that.
In any case, and then the upcoming rust thing called Graviola, that when that's ready,
then you probably add this a beckon, but we could add other beckons as well.
So DNSI, we had big vision for that, and that is, we want to have a command like tool,
that can really tell you about DNS stuff from your command line and sort of be smart about it,
and then what we shouldn't, didn't have the time, so we started doing a deck like thing,
and now it's still a deck like thing. We try to make the output more user-friendly, so maybe that
helps, but still efficient for the future is we want to do smarter things like,
I don't know, maybe it can tell you why your DNS sec is broken, or something like that.
So for L DNS, it's a library, and we want to get rid of that library, because it doesn't have
a particular nice API. If you use it from C, it's very easy to make all kinds of annoying mistakes
and stuff like that, and it's not that much user-friendly, but it's not like the whole world
is running on L DNS. One problem is that L DNS, the library, comes with example programs,
and people with understood example programs and they use them in production, and I'm also guilty
of that. I mean at home, I'm running a home, crown DNSic signer that is written around L DNS sign,
so, so we realize that if we don't want to make a lot of people very miserable,
then if we say, L DNS is going away, then we need to have replacement for the L DNS utilities.
So that is basically what DNS T started out. It has some of them, I'm plan to do more of them,
and then when you call them with the L DNS name, then they have the same options, and we try to
make it as competitive as possible. It's not 100% the same, but roughly it's the same.
And then if you call it with the DNS T name, then you get the sort of utility, but you get
more than a command line flags and other clean up and other options and stuff like that.
And now we add it one new utility to that DNS T thing that is not in L DNS, and that is
a DNSac key manager, and that is basically taking this code in domain for key management,
and then makes it into a concrete application that can do key roles and all that kind of stuff,
so that if you build a DNSic signer, then the key manager is already taken care of.
Okay, so there was 2024. 2025 started working on cascade, the signer, bumping the wire signer,
so it means it receives a zone file, either a file or X of R, X of R, X of R. Signs it,
makes it a failable as X of R. We explicitly put in review hooks for the signed and unsigned
zone, so when you unsigned zone, first in of the unsigned zone comes in, review hook gets called
user can check like, do I have a sensible set of data, maybe it's a tiny zone, now when there's
something went wrong, I don't want to sign it, you could put in some special records, check whether
they are there, for sign, you can check whether the sign zone matches the unsigned zone,
whether it has a fillet, insect chain or kind of stuff, and only when those review hooks return
through, then you say, okay, you can surf that. Well, it uses external key manager, that I just described,
and that we may also at some point integrate one as well, and we also find out as part of sort of
real-world annoyances that people write to spend a lot of money on a box, and that box can
do signing and it's signed slower than if you just do it in the application, and it costs a lot
of money and people want to use that. And that is still fine, and now this expensive box comes
with a binary block, and you're supposed to load this binary block in your program, and they're
called that PKCS11, and then they say, well, you just call it, and so we have a hardware manufacturer
that has a close source thing, and they give you a binary, what could possibly go wrong.
So everything does go wrong, and we said it, okay, no way, we don't want this, we have a nice
rest application, we're not going to load this stuff in a nice rest application. So we said, okay,
we need to run that just in a different process, if it was a different process, crashes, it's still annoying
that them can tell the user like, sorry, see, there's your problem, you have a weird HSM,
you can figure out how to deal with that, maybe you generate some test traffic, and see how it
crashes, or something like that. And then that was all good, and it is like, okay, now we need
to talk to it. So, of course, we just design a new communication protocol to talk to that,
well, maybe not, because there's an existing one called KMIP, and then nobody using it uses that.
It's essentially now HSM's that do it, there's no application that you thought, okay, well,
maybe instead of reinventing a new network protocol, we use a standard one, it's still relatively
annoying, because I mean those protocols are weird, but we got it to work, and then we got into
the heart part of computer science, we had to give it a name. So, so we have gone through many
a names, and then we settled on the most descriptive one, and that this KMIP took PICCUS,
11, which is fine, except you can type it unless you type it every day, and you can't pronounce it.
So, now, recently, we have to decide to dig deep into the Lord of the Rings and come up with more
fun, so now people can tell us whether they like that or not, any case, that's a cascade,
before cascade, we started with cascade, also during cascade, and we learned that there's some
parts of domain that are not very pleasant, domain has an octet abstraction, and I give you a bit of
code that you may have for right now, and it's just a complex, we would say, okay, we want to use
domain, we understand this stuff. We created a surfer middleware layer, and it's also to complex,
and it's also like, okay, if you now look at domain, there's some stuff that you could do more
efficiently, if you would read a cliché in the interface of some things. So, together that we decided,
okay, we need to just rewrite the base DNS types, will be very unpleasant, but we need to do that
to move forward. So, then we get to the plan for sort of the coming here, we need to make a
production release of cascade, and we released an alpha last october, and then we got some
really enthusiastic testers who created lots of issues, so we got a lot of stuff to fix,
and now we need to fix all of that and get to in the production release.
Like I mentioned, we need to do sort of the base of domain, and then out of cascade work,
follows like, okay, we really would like to load some files very fast, so we probably want a new
zone file parser, certainly in cascade, but trying to move that back to domain, and cascade leads to
a really interesting zone file storage, because you constantly get all kinds of diffs, like you get
an x-ifier with a new enzyme zone, and you need to sign that, and you want to cleverly keep that as
a diff, so you can serve it again as an x-ifier, so we need to have a new internal way of storing
zones that then hopefully also can migrate back to domain, and we can work on TNI, or that's
it have been TNST, and me, more is a simple proxy that we have to experiment with looking up
these server parts in the client part and the query routing, and all that kind of stuff.
Then, now, sort of the moment where I would ask you, like, we want to have a DNS library that is
useful to the open source community, and we know what we want for our own applications,
but if there's stuff that you want from a DNS library, then please let us know,
and then we can take it into account for how we evolve domain, so that's it for me.
Okay, so the comment is, I felt for the update, and six-year-old, good.
Is there a ability to request TLS connection with client out of the application set that
certificate already, and if not, would it really possible to edit?
Yeah, my question is, is there a possibility to set up a TLS connection with client authentication?
And I think, but I never tried it, because we abstract over TCP and TLS, as an application,
you can submit your own TLS connector, basically, and if that has a client certificate,
then it should just work, but I never tried it.
I don't know if we don't release, we haven't released a lot of this, so it's not on a regular
other question is, I installed DNS, I, with Cardinal installed, can also do that with TLS T,
and that is, so we're really behind publishing this, so if you want it it's better to just get
clone the repo and then do a Gargo built, then trying to do the install, we may have to release
one version, but if we did, it is very old.