Our next speaker is Martin, who would be telling us about the domain crate, I think it's called.
He's been building for Rust and all the cool tools you will be building with it.
Probably, yeah.
Hello.
Back in 2015, so in the times before, two things happened.
One was that Rust released version 1.0 and became stable.
And the other was that I started working at a Nellitlabs.
You probably know Rust as the thing that everyone wants to write everything in,
and you might know Nellitlabs from things like Unbound, NSD, OpenDNSHack, and some more things.
So I thought I want to teach myself some Rust, and I need to teach myself some DNS,
so why not combine these things?
Now, what also happened at the same time Benjamin Fry was working on trust DNS,
which is now called Hickory DNS, and I figured, well, let's not do the same thing.
That would be silly.
So I came up with a different idea, which was instead of building a giant application,
or a set of applications, build lots of building blocks that people can then use
to build their own specialized DNS applications.
Because what happens is we have a lot of good sort of stuff for generic use cases,
resolvers, primary servers, that sort of stuff.
But if you want to build your own specialized DNS application, that's actually surprisingly hard.
I find that out the hard way.
For a project that we were doing, I needed a very specific primary server that was having a like a Rust interface,
and then instead of people actually telling me which specific resource records to publish,
they just wanted me to tell, I want this thing to happen.
And then I built this with a Python at the time with Flask and LDNS Python Reps,
which are surprisingly weird.
And I would rather have had something that I could just build this all in Rust.
So I think this is really a good idea.
And so I started working on it, learned a bunch of Rust, learned a bunch of DNS.
And where are we now with it?
This is the starting page for the documentation for the last released version, 093.
It's also apparently quite a lot happened before at 09 already.
So there's a bunch of things as you can see here.
Base is also the handling of DNS data.
So there's types in there for all the things you could think of.
The main names, resource records, record data, all the R types and all these various types.
And also messages, complete messages so you can build your own messages and whatnot.
There's R data, which is a massively incomplete set of record data types.
We only did the ones that we need because this is very early still.
And whenever you change something and you have like what is it, 6,000 record types,
you have to change all of that, which would be annoying.
So we limited ourselves to the ones that we need.
But there's a lot of stuff in there already.
There's all the basic ones.
There's the DNS-like ones.
Even someone contributed the SVCB or HTTP ones.
We even have that.
There is a stop resolver, very simple one, just as like a proof of concept.
Although that's, I think, the thing that most people actually use.
I wrote a signer.
Well, it's not complete because it doesn't do NSIC-3, but yeah.
I wrote some T-SIC support that is actually complete.
And that was kind of fun because that happened right at the time when there was an update to T-SIC.
So I contributed back some thoughts on the quality of the RFC for T-SIC,
which the original one is surprisingly weird.
Someone contributed some very basic validation things.
I think it's basically just validate and RR-SICs or nothing with looking at DNS keys and stuff like that.
And we have a zone file part of there because everyone has one.
And this is actually a second iteration.
I wrote the first one, so I wrote the second one,
which I probably also going to throw away and write the third one.
But we'll see.
This has also to do with, for NSD, a colleague recently built a zone file part that uses these,
what is this, the things with the multiple SIMD, and that is ridiculously fast.
So now I'm kind of embarrassed.
So it actually kept growing quite nicely.
But then, oh no, distractions.
We did a thing for routing or RPKI, which we wrote two products for,
Routinator and Krill, which are quite popular in that field.
But it wasn't actually that bad because both of them are written in Rust, obviously.
And these are actual products that are actually used by actual people.
So we got a lot of experience with writing in Rust, deploying Rust,
and also sort of got a bit more comfortable with doing things in Rust,
because if you sort of listen to a lot of people and they're all,
blah, blah, blah, fad, go away.
But actually, nobody really cared.
If you build an application that works, that is very convenient,
then of course everyone will like it.
And that then meant that we could take a step back.
The DNS is changing quite currently, like there's all of these new things,
like there is HTTPS, there's a lot of new transport protocols,
there's a lot of stuff happening right now.
So probably also the applications for DNS, the use cases for DNS are changing.
And I think it's a good idea to sort of explore that space
and see where we can get this by providing a lot of sort of building blocks
that you can just put together quickly and just like play around with things.
The sovereign tech fund, which is a German sort of funding organization
for fundamental internet infrastructure, they agreed with us.
So they funded a year of development for us, this,
which then allowed us to spec what we're going to do with domain this year
and allowed us to focus, to actually have like three people work on this
full time more or less this year.
So what's the plan?
We came up with three tracks.
First is the client track, which basically is all the things that need to be a DNS client.
So the thing that sends requests and then receives responses, matches responses,
and also sort of preprocesses responses.
So the three things that we have here on our list right now is basic transports.
We're currently only focusing on traditional DOS, DNS over Port 53,
so UDP, TCP and DUT, the other ones are coming.
But a year is actually not that long, surprisingly enough.
We're doing response caching and we're doing, that's going to be fun, a DNS-seq validation.
The second track is the server track.
So the thing that receives requests and then figures out what to respond with.
Again, basic transports.
We're doing all the things that you need for zone handling.
The key on plan is to have zone file parsing, which we've seen we already kind of sort of have.
Just need to make it nicer, which also probably means we need to add lots more record types.
Then stick all of that into a zone tree and use that zone tree to answer queries.
Straightforward enough.
Of course, DNS-exhining is a thing.
As I said, I already have parts of that.
We need to actually turn it from a proof of concept into an actual thing that you can use.
We're going to do this zone transfer so that you can then basically, with this server track here,
technically build your own authoritative, which then would solve the use case I heard earlier.
Then we have a third track, which we just called the bonus track, which is sort of the idea is,
well, we can build all of these things, but we don't know if they're any good if we don't use them.
So let's build something where we actually use our stuff and put it together.
One idea that we have is a DNS proxy.
Sometimes you call forwarder, like all this terminology is terrible and non-standardized,
but basically a thing that sits somewhere and receives requests,
but doesn't do the actual recursive resolving just forwarded to someone else.
What we've talked with various people about what they need is sort of a way to decide what to do with the request
based on a set of rules.
Look at the request, look at where it comes from, look at the R types, that sort of thing,
and then say I want to process it, I want to send it forward to some other recursive,
I want to respond to it here, or I just want to drop it because that's just the wrong thing.
So the sort of long-term goal for this thing is to build something that can do that with maybe a scripting language and whatnot.
But as an initial proof of concept, it will just basically be into some configuration.
Maybe you have to write the rules in Rust by hand, but they're not yet.
But no, there's even more.
We also want to do a diagnostics tool.
I'm not going to say dig.
Mostly because we need it for testing anyway.
But then we thought, well, just re-implementing dig is kind of sort of boring.
Let's look into something more useful.
And some of the things that we thought of was sort of like what DNSVis does.
So have a thing that you can go and check if your DNSX for your zone is correct, correctly set up.
Another idea was compare your resolver, your upstream recursive.
What that actually has on data compared to your authoritative.
Stuff like that.
So if you have ideas, we're definitely open for it.
First stage, we just want to sort of see how this thing is going to look.
And then finally, we have a bunch of things in LDNS, which were intended as examples and not as actual applications for people to actually use,
which then people actually used.
And that's kind of annoying because we're actually not maintaining them.
They're just there.
And then people sort of, you know.
So the thought here is, well, maybe we should actually make these official in some way for more shape and make them available.
So things like check that your zone is correct.
So was blah, blah, blah.
Sign a zone and whatever else there is.
And I think that all will keep us quite busy for the year.
And we're also hoping that by the end of the year, we actually have something that is useful for people.
So if you have ideas, if you want to, no, we don't have that yet.
Sorry, what was the question?
Oh, sorry.
The question was support for zone MD.
Zone MD, right.
Yeah, no, we have none yet.
Doing zone MD will expose all the mistakes you made in your design.
Excellent.
And or draw a path of destruction for your code base.
Yeah, but that's what it did for us anyway.
Yeah.
So we should probably do this actually as part of designing the zone tree thing that we're doing right now.
Yeah, that's a good idea.
Yeah.
Yeah.
Can you maybe elaborate a bit, a tiny bit on the actual Rust experience for this?
What did you learn, anything that surprised you in the DNS part or in the Rust part?
Yeah, so the question was what was the experience with Rust and DNS with this all?
Well, I started, this was basically my first real Rust project.
So like you're like a kid, everything is as it is and everything is like how it should be because that's what it is.
I think DNS wasn't all that surprising in and of itself.
The situation with the RFCs and stuff being hidden where you don't expect it is super annoying.
It absolutely helps if you have colleagues who have been doing DNS for 25 years, just like one desk over.
But all in all, I didn't have any surprises.
I couldn't think of anything.
Which is great fun.
I can recommend doing DNS.
Yeah.
Yeah.
Any particular Rust libraries you're using for parsing, for making together the packet that goes over the line?
So the question was whether we're using any other dependencies for parsing and whatnot?
No, we did all of our stuff ourselves.
Because ultimately it's relatively simple, right?
It's just binary, sort of you just go over a sequence of bytes and you pick out the things.
And I don't think it's worthwhile to just have some complicated thing for it.
And what we did is what might be interesting for other people is we didn't want to stick to a specific representation for these octet sequences.
So we did some abstractions over like vex or just slices or bytes or whatever.
And made all of these types from the basic type scenario for that.
Which makes the usage a bit iffy, because you now have these type arguments.
But it's super flexible.
In theory, you should be able to use this in an environment without an allocator.
So if you just built this on top of arrays by the arrays, then you should be able to do probably only a UDP.
But it should be possible to do a little DNS client for an embedded environment.
Which was one of the use cases that I was looking into which I thought interesting, probably not very widely used but fun.
Any other questions?
Do you have a cell in the file, sir?
Yes.
Does it preserve comments?
No.
This keeps happening if you don't know.
Is that something you would want?
Yes.
Okay.
Any other questions for the audience?
Oh, yes, sorry.
The question was whether we had a zone file parser and whether it would preserve comments, which it does not.
It currently only really just parses things into data structures too.
So it's not like a manipulation thing.
Yes.
Talking about bind files, there's bind files.
There's also the cop that you can have a name and you have a context to reference back to the previous record without having to fold things like people.
That's awesome.
Awesome.
So the question was whether I guess whether it's compatible with whatever bind does.
Yes.
Which it is because that's the standard.
Which is also super annoying because like the RFC is very.
It's true.
It really is.
So what we're also looking because also colleagues were building a new zone for buzzer for NSD and that has to be compatible with whatever we have.
Right.
Or at least with whatever NSD was doing before.
And I think they're mostly.
Compatible.
So what we're also looking into is maybe working on a sort of minimum definition of what is on.
I should look like if it's if it's sort of portable between everything and have that as an actual grammar.
That would be really cool.
But it's also loads of work.
So I'm not sure if this is going to happen.
That we have a question.
Yes.
I had a question.
So.
Have I understood it correctly?
You wrote.
Building books for building entire server.
Quite powerful.
But.
You never are.
Going forward to it.
Writing that server.
That is.
Yes.
So the question was whether.
We have plans to build an actual server and the answer is not currently.
The.
The.
Our sort of the sort of the.
What do you call it the distance that we're looking at is about five years.
And we don't have a plan for that.
But also we're very flexible.
Stuff comes up.
But currently we're very happy what we have with unbounded NSD.
Yeah.
And I'll be in a second.
Of course.
Thank you very much.
We promise stickers.
There's loads here.
So if anyone needs more decorations.