Good afternoon, thank you for being here, thank you for your interest in networking
DNS. I'm going to rush through this slide because it's time for the target shorter
than I anticipated. So let's start with Boeing's thoughts, that's me. I've been around
for a while, and I became the maintainer of Netbox DNS, rather, rather in voluntary, and
I will also tell the story how that happened. So let's start with the
2021. I was asked by customers who do projects for them, but mainly consisted of building
up in DNS infrastructure for them, which started in the year 2009. I did a pro-edited
concept. I made a proposal, and only 12 years later, I was asked to really implement
that stuff. It's not him. So they wanted to have DNS infrastructure fine, that was
whatever proposed, but unfortunately they also wanted to have a DUI for the DNS.
And I, to be honest, have never done something like that before, and not a DUI guy,
and so I had to find a solution for that problem because there was nothing, and I had
to invent something. I had some selection criteria. It should be an open source tool.
It should be a web best front end, because that's how you do it these days.
It has to be a while maintained in the living project, not something like, for instance,
PHP, other admin, which is fairly dead, but still around. It needed to have an API,
because they wanted to do Ansible automation and wanted to provide provision that DNS
service using Ansible. And it should be reasonable, lightweight. So they didn't want
a huge monolithic application that also can do with DNS, but they wanted to have something
that was focused on network management, iPad, maybe, and decent, and inclusiveness.
So I came to the idea of using networks.
I first came in touch with networks at various CCC.
Congresses were always somewhere in the infrastructure review talk.
Someone mentioned that they did all the infrastructure management and all the
things, and I thought, well, that might be the right tool.
I looked at networks, and networks can't do DNS.
There is some limited support for DNS in networks, which means in iPad there is a field
DNS name that you can use to fill the DNS name for IP address, but that is not
sufficient to provision a DNS server, so not so well.
But on the other hand, networks has a plug-in infrastructure.
So my first idea was if it has a plug-in infrastructure, it should also have a plug-in
for DNS. Unfortunately, not freely.
It took me a while to find the project on GitHub, where it was called Netbox DNS,
by a company named Aurora Research Lab, a couple of guys in Istanbul, very nice.
And they had started only two months ago when I found the project, so it wasn't really
pretty much here.
But it could do the basic stuff that I need.
It could maintain, it could maintain servers, it could maintain servers, and it could
sign records to sounds, so basically for what I needed to do, it was pretty much a good
framework.
But what was very important, they also had invested a lot of time in creating automated
tests for it, and automated tests are something I really love, and so they had one
my heart.
So what they couldn't do, they didn't do any validation of DNS names or values.
You could enter pretty much everything, it was fine.
Some of the tests matching that behavior and providing syntactically incorrect data,
so actually the tests tested that the incorrect data you could enter were actually
incorrect.
And they had no automation at all.
So when you created a name server and designed the name server to the zone,
there was no endless record.
If you wanted to have an SOA record, you had to comply with my hand.
There was no generation of civil serial numbers, so essentially when you changed something,
it was your responsibility to change the civil serial numbers.
So the sound actually gets loaded by the secondaries.
So that wasn't really optimal.
And then at that point the API, they had implemented a couple of functions in the API,
but some of them were just missing in some information that had to be in the zone,
but it was not available using the API.
So I had to do some work, but basically the starting point was quite good.
On terms of validation, this thought will be mentioned in validation quite often.
What can you validate?
You can validate that an hour out type is actually a valid hour out type.
You can validate that DNS names follow the general guidelines for maximum,
about 63 octets in a label, maximum total length of 255 octets,
and so on consisting of labels and dots.
So the general format, you can validate.
Then you can validate our forms.
Now certain hours have certain formats,
and that's the record for API4 must contain an IPv4 address.
And as a quad-A record needs to contain an IPv6, we see it.
Then there are funny constraints regarding some hour out types,
without single buttons, that only have to be, that only may be available once,
or maybe maybe find once per name,
and there are also types like Scename and D-Name,
which are actually only allowed once per cell.
So you can validate that.
Then it gets really funny when you start implementing PUNICode and IDN.
Because PUNICode validation is sometimes a bit strange.
And then you can validate our online.
Named validation is really weird in some places,
so that's also something you can do.
So there are various levels of validation that you can apply to DNS ons.
Named validation from examples, the first name is allowed,
the second name is allowed as well.
The third name is kind of allowed.
Some name servers don't allow it unless you can do that.
The last name is allowed, but not as a host name.
The next one, the name after that is not allowed at all,
because it contains two letters in the places three and four of the name,
which is starting to get weird.
The next one is allowed because it is well,
it's a well-punished PUNICode for an IDN.
The next one, the last one, XN minus BB,
is not allowed because it does not define a well-punished PUNICode.
So when the IDN is up, stuff is really off.
So what is it with 2020-1?
First of all, beginning of the project,
I needed to implement the stuff for my customer,
so I did the stuff that my customer needed.
So basic validation for IP addresses,
sounds at nameserver names, so they couldn't enter something
because it was completely breaking the DNSN.
Then generation of PDA records for address records,
which is relatively easy if you have IPv4 addresses.
It is a hell when you have IPv6 addresses.
Then generating an address records for the nameserver's defined in a sound.
The automatic generation on SIA series is quite important,
because that's normally forgotten.
When something is changing, someone changes something manually.
Then the generation of the rest remainder of the SIA sound fields
from properties.
I defined some properties in the sound,
like expiry and so on,
and created the SIA series from that,
and also defined the possibility to define defaults.
So they don't have to be answered every time.
And many additions following your tests,
because we needed to test the functionality,
especially if we automatically need it to work properly,
and so a lot of tests were created for that.
And that was it.
It has not was happy.
The product could be finished,
and they page and everything is fine.
Unfortunately, that's not what's fun.
So it continued.
Something happened in the beginning of 2020,
the networks project started in the initiatives
of working group with an aim working group A3CC.
And wanted to improve the interface of networks
that plug-in offers to use.
And because I had created the plug-in,
and because that plug-in obviously had some impact
on some people use it already,
they came to me and asked me to participate in that working group.
Which was a surprisingly short-lived working group.
We were about it for about six or eight more weeks.
And then it was finished, and then it was closed.
And the next networks were actually contained
the changes that we had agreed upon.
That was quite funny.
So now,
plug-ins could use a lot of features that networks has,
that were formally not a lot to use,
but to be used by plug-ins.
Dynamic model choice fields, custom links,
where it puts export effort and templates and so on.
And some other standard features that networks has
for many of the models that it uses
like change logging, tagging, journaling.
That is very useful.
Then support for adding plug-ins specific top level menu items.
Formally, before I started to work out the project,
you could only find the plug-in menus under
sub-menu item plugins,
and then you had to look for it.
Now, if you can define your plug-in top menu at
a highest level of the menu, so you see it all the time.
That's very useful because many people ask me,
where is the plug-ins?
Where is the menu for the DNS plug-in?
Well, where is other under plugins?
Can we move it up?
No, we can't.
Okay.
That was possible.
That's by then.
And they made a very good plug-in development
to tutorial and general implementation for developers.
That was also very big improvements.
So, in my point, from my point of view,
A33 was a great success.
So, what happened in 2020, too?
That box 3.2 was released with the results of the working group.
I implemented a lot of functions.
I had worked around the limitations on.
So, that could be removed and could be moved to the official functionality.
I added support for the new GraphQL API, which was also not possible before.
I added views to the data model.
Because the data model, where the customer needed was not including views.
They only had one zone, one level, one view.
And I needed views for a couple of other customers and for my own environment.
Because I used special DNS.
Then I started to use DNS Python to validate names
and format our data format.
Because that is something you don't want to do yourself.
A lot of record types around it.
Sometimes the other data formats for these record types are very obscure.
Support for PUNicode and IDNs.
That actually was a by-product of using DNS Python.
Because the DNS Python has very good support for PUNicode and IDNs.
And support for the global search index.
That is also a great network tool.
We can enter something in the global search field.
And then all the models and all the items that are somewhere in that box
pop up that's matched the search.
So that also works for DNS items.
And all you can do is search for the DNS names and so on.
That was pretty good.
So 2023.
Net box field 5 came along and started to implement
the changes necessary to support net box field 5.
And then nothing happened.
The hours were not moved.
It then has been not merged anymore.
Nobody answered.
So the project was obviously dead.
And it is 2v6.
So I had to fork it.
I was thinking it was a decision that was had to be done very, very quickly
because 2v5 was imminent.
I wanted to support 3v5 from day one.
But it was not possible because I couldn't merge anything.
So I had to fork.
With GitHub, it is no real problem to fork projects.
You can use the net same name and so on and everything is fine.
But with Python, the name net box DNS was taken already.
By the old one.
That was dead.
So I needed to use a new name.
And that was the first problem.
The second problem I introduced by the decision to leave the directory three as it was.
That was a good decision in terms of maintaining compatibility with interfaces.
It was a very bad decision in terms of, well,
what happens when you find out the project, the plugin you installed is dead.
You install the new one.
Then you install the new one and play around a bit with it.
And after you did that, you removed the old one.
But not good.
So people broke the installations because of that.
Not good.
I had a number of issues that I had to answer and explain why what they did and why they could fix it.
And the GitHub search always found the old plugin because it had a couple of hundred stars.
And the new plugin was very new.
And so it didn't have any stars and nobody found it.
All the people opened pi hours and opened issues and so on in the old one.
And I moved them over to the new one.
So after that was done.
I could finish port internet box view of ice.
I could add a lot of validation.
I mentioned it earlier.
Single, single names and so on.
I could add a lot of validation for a bit more obscure case.
Someone came and said, well, I want to maintain my route zone.
My custom route zone in Netflix.
Which wasn't possible because you couldn't enter an empty zone name.
And so it's possible that was added as well.
And there was very good contribution by another user who made the first attempt of integrating between the iPad module of Netflix with DNS.
Which is not as easy as it sounds.
Because I mentioned there is only the DNS name field.
And you have to find the matching zones.
And well, what he did was signing zones manually to IP addresses.
And defining names manually.
And then you had integration between the iPad and DNS address.
And the DNS address record for it.
And the pointer record, which worked pretty well, but had some limitations.
So, 2024.
The next thing was figured by a user request.
They wanted to use our C20317.
So, I tried to find a way to integrate that as well.
I hope it has.
It worked sufficiently.
I increased the level of validation for record types.
I created a compatibility with a new box for version.
Which was a bit more as thought than with a minor version update.
And I developed a new one, a new way of implementing the link between the iPad and DNS.
Which I will explain a bit later.
And the added support for localization, which was possible since that box 3.7,
and that box 4.0, it became really usable.
I'll see, 23.7 is working on for an IPv4 problem.
You can only delegate the reverse zones at Thought Levels.
And many people and many organizations only have 25 to 49 domains.
So, they actually can't manage the reverse domains.
And I'll see 23.7.
Works by, well, putting the pointer records for these zones in some other zones.
And then creating C-names in the flash 24 version.
The reverse zones can only be maintained by provider.
But the C-names can then be managed by the people themselves.
The new DNS sync works a bit different from the old one.
And at least for my purposes and for the purpose of my customers a bit better.
I create nothing between DNS and IPAM prefix to one or multiple DNS views.
And when you know, the fun of DNS name for an IP address in the fixes.
That was the NAS will look in all the views for a matching zone.
And create the address record in the zones it finds.
That works pretty well.
It is still not perfect.
It still has some limitations.
But less than the former implementation I think it is pretty good compromise.
And something I can do than in the future.
So, what will come in 2025?
Support for DNS sec.
Actually, you don't have to do so much to support DNS sec because DNS sec normally is done by the name server itself.
But by the signing, in line signing.
But some fields can also be added to DNS zones.
Like key algorithms.
And whether to use Nsec or Nsec3.
So there can be some support in that box DNS.
Currently I am using custom fields for that.
But it can also be native.
Then an idea is to create so-called mirror zones.
But mirror all the records or a specified subset of records.
From one zone to another.
Use case, for example, do you have an internal and external zone.
And you want to have only a subset of the names in the internal zone.
Actually, expose to the external zone.
So that would be one of the use cases for mirror zones.
Then extend support for zone delegation when you have a zone.
And it's up zone.
You can also automatically generate the delegation records and so on.
That is also something that could be implemented and will be implemented in the midterm.
And in such a favorite feature here, I'm open to feature requests.
I'm open to suggestions.
And if anyone has an idea, please open an issue or feature requests.
Thank you.
Thank you very much.
Thank you.