WEBVTT

00:00.000 --> 00:09.000
Good afternoon, thank you for being here, thank you for your interest in networking

00:09.000 --> 00:17.000
DNS. I'm going to rush through this slide because it's time for the target shorter

00:17.000 --> 00:23.000
than I anticipated. So let's start with Boeing's thoughts, that's me. I've been around

00:23.000 --> 00:30.000
for a while, and I became the maintainer of Netbox DNS, rather, rather in voluntary, and

00:30.000 --> 00:35.400
I will also tell the story how that happened. So let's start with the

00:35.400 --> 00:44.000
2021. I was asked by customers who do projects for them, but mainly consisted of building

00:44.000 --> 00:52.000
up in DNS infrastructure for them, which started in the year 2009. I did a pro-edited

00:53.000 --> 01:00.000
concept. I made a proposal, and only 12 years later, I was asked to really implement

01:00.000 --> 01:08.000
that stuff. It's not him. So they wanted to have DNS infrastructure fine, that was

01:08.000 --> 01:14.000
whatever proposed, but unfortunately they also wanted to have a DUI for the DNS.

01:14.000 --> 01:19.000
And I, to be honest, have never done something like that before, and not a DUI guy,

01:19.000 --> 01:26.000
and so I had to find a solution for that problem because there was nothing, and I had

01:26.000 --> 01:31.000
to invent something. I had some selection criteria. It should be an open source tool.

01:31.000 --> 01:35.000
It should be a web best front end, because that's how you do it these days.

01:35.000 --> 01:40.000
It has to be a while maintained in the living project, not something like, for instance,

01:40.000 --> 01:48.000
PHP, other admin, which is fairly dead, but still around. It needed to have an API,

01:48.000 --> 01:53.000
because they wanted to do Ansible automation and wanted to provide provision that DNS

01:53.000 --> 01:59.000
service using Ansible. And it should be reasonable, lightweight. So they didn't want

01:59.000 --> 02:05.000
a huge monolithic application that also can do with DNS, but they wanted to have something

02:05.000 --> 02:12.000
that was focused on network management, iPad, maybe, and decent, and inclusiveness.

02:12.000 --> 02:17.000
So I came to the idea of using networks.

02:17.000 --> 02:21.000
I first came in touch with networks at various CCC.

02:21.000 --> 02:26.000
Congresses were always somewhere in the infrastructure review talk.

02:26.000 --> 02:30.000
Someone mentioned that they did all the infrastructure management and all the

02:30.000 --> 02:37.000
things, and I thought, well, that might be the right tool.

02:37.000 --> 02:41.000
I looked at networks, and networks can't do DNS.

02:41.000 --> 02:47.000
There is some limited support for DNS in networks, which means in iPad there is a field

02:47.000 --> 02:51.000
DNS name that you can use to fill the DNS name for IP address, but that is not

02:51.000 --> 02:56.000
sufficient to provision a DNS server, so not so well.

02:56.000 --> 03:00.000
But on the other hand, networks has a plug-in infrastructure.

03:00.000 --> 03:04.000
So my first idea was if it has a plug-in infrastructure, it should also have a plug-in

03:04.000 --> 03:09.000
for DNS. Unfortunately, not freely.

03:09.000 --> 03:15.000
It took me a while to find the project on GitHub, where it was called Netbox DNS,

03:15.000 --> 03:21.000
by a company named Aurora Research Lab, a couple of guys in Istanbul, very nice.

03:21.000 --> 03:27.000
And they had started only two months ago when I found the project, so it wasn't really

03:27.000 --> 03:30.000
pretty much here.

03:30.000 --> 03:33.000
But it could do the basic stuff that I need.

03:33.000 --> 03:38.000
It could maintain, it could maintain servers, it could maintain servers, and it could

03:38.000 --> 03:46.000
sign records to sounds, so basically for what I needed to do, it was pretty much a good

03:46.000 --> 03:48.000
framework.

03:48.000 --> 03:53.000
But what was very important, they also had invested a lot of time in creating automated

03:53.000 --> 03:58.000
tests for it, and automated tests are something I really love, and so they had one

03:58.000 --> 04:01.000
my heart.

04:01.000 --> 04:07.000
So what they couldn't do, they didn't do any validation of DNS names or values.

04:07.000 --> 04:11.000
You could enter pretty much everything, it was fine.

04:11.000 --> 04:17.000
Some of the tests matching that behavior and providing syntactically incorrect data,

04:17.000 --> 04:22.000
so actually the tests tested that the incorrect data you could enter were actually

04:22.000 --> 04:23.000
incorrect.

04:23.000 --> 04:25.000
And they had no automation at all.

04:25.000 --> 04:29.000
So when you created a name server and designed the name server to the zone,

04:29.000 --> 04:31.000
there was no endless record.

04:31.000 --> 04:35.000
If you wanted to have an SOA record, you had to comply with my hand.

04:35.000 --> 04:40.000
There was no generation of civil serial numbers, so essentially when you changed something,

04:40.000 --> 04:45.000
it was your responsibility to change the civil serial numbers.

04:45.000 --> 04:49.000
So the sound actually gets loaded by the secondaries.

04:49.000 --> 04:51.000
So that wasn't really optimal.

04:51.000 --> 04:57.000
And then at that point the API, they had implemented a couple of functions in the API,

04:57.000 --> 05:01.000
but some of them were just missing in some information that had to be in the zone,

05:01.000 --> 05:03.000
but it was not available using the API.

05:03.000 --> 05:12.000
So I had to do some work, but basically the starting point was quite good.

05:12.000 --> 05:17.000
On terms of validation, this thought will be mentioned in validation quite often.

05:17.000 --> 05:19.000
What can you validate?

05:19.000 --> 05:23.000
You can validate that an hour out type is actually a valid hour out type.

05:23.000 --> 05:29.000
You can validate that DNS names follow the general guidelines for maximum,

05:29.000 --> 05:36.000
about 63 octets in a label, maximum total length of 255 octets,

05:36.000 --> 05:41.000
and so on consisting of labels and dots.

05:41.000 --> 05:44.000
So the general format, you can validate.

05:44.000 --> 05:46.000
Then you can validate our forms.

05:46.000 --> 05:49.000
Now certain hours have certain formats,

05:49.000 --> 05:54.000
and that's the record for API4 must contain an IPv4 address.

05:54.000 --> 06:00.000
And as a quad-A record needs to contain an IPv6, we see it.

06:00.000 --> 06:07.000
Then there are funny constraints regarding some hour out types,

06:07.000 --> 06:12.000
without single buttons, that only have to be, that only may be available once,

06:12.000 --> 06:15.000
or maybe maybe find once per name,

06:15.000 --> 06:18.000
and there are also types like Scename and D-Name,

06:18.000 --> 06:21.000
which are actually only allowed once per cell.

06:21.000 --> 06:23.000
So you can validate that.

06:23.000 --> 06:28.000
Then it gets really funny when you start implementing PUNICode and IDN.

06:28.000 --> 06:34.000
Because PUNICode validation is sometimes a bit strange.

06:34.000 --> 06:39.000
And then you can validate our online.

06:39.000 --> 06:44.000
Named validation is really weird in some places,

06:44.000 --> 06:46.000
so that's also something you can do.

06:46.000 --> 06:52.000
So there are various levels of validation that you can apply to DNS ons.

06:52.000 --> 06:56.000
Named validation from examples, the first name is allowed,

06:56.000 --> 06:58.000
the second name is allowed as well.

06:58.000 --> 07:00.000
The third name is kind of allowed.

07:00.000 --> 07:05.000
Some name servers don't allow it unless you can do that.

07:05.000 --> 07:09.000
The last name is allowed, but not as a host name.

07:09.000 --> 07:13.000
The next one, the name after that is not allowed at all,

07:13.000 --> 07:17.000
because it contains two letters in the places three and four of the name,

07:17.000 --> 07:20.000
which is starting to get weird.

07:20.000 --> 07:23.000
The next one is allowed because it is well,

07:23.000 --> 07:26.000
it's a well-punished PUNICode for an IDN.

07:26.000 --> 07:29.000
The next one, the last one, XN minus BB,

07:29.000 --> 07:33.000
is not allowed because it does not define a well-punished PUNICode.

07:33.000 --> 07:37.000
So when the IDN is up, stuff is really off.

07:37.000 --> 07:40.000
So what is it with 2020-1?

07:40.000 --> 07:42.000
First of all, beginning of the project,

07:42.000 --> 07:44.000
I needed to implement the stuff for my customer,

07:44.000 --> 07:47.000
so I did the stuff that my customer needed.

07:47.000 --> 07:50.000
So basic validation for IP addresses,

07:50.000 --> 07:54.000
sounds at nameserver names, so they couldn't enter something

07:54.000 --> 07:57.000
because it was completely breaking the DNSN.

07:57.000 --> 08:00.000
Then generation of PDA records for address records,

08:00.000 --> 08:03.000
which is relatively easy if you have IPv4 addresses.

08:03.000 --> 08:06.000
It is a hell when you have IPv6 addresses.

08:06.000 --> 08:10.000
Then generating an address records for the nameserver's defined in a sound.

08:10.000 --> 08:13.000
The automatic generation on SIA series is quite important,

08:13.000 --> 08:15.000
because that's normally forgotten.

08:15.000 --> 08:20.000
When something is changing, someone changes something manually.

08:20.000 --> 08:24.000
Then the generation of the rest remainder of the SIA sound fields

08:24.000 --> 08:26.000
from properties.

08:26.000 --> 08:28.000
I defined some properties in the sound,

08:28.000 --> 08:31.000
like expiry and so on,

08:31.000 --> 08:34.000
and created the SIA series from that,

08:34.000 --> 08:37.000
and also defined the possibility to define defaults.

08:37.000 --> 08:41.000
So they don't have to be answered every time.

08:41.000 --> 08:44.000
And many additions following your tests,

08:44.000 --> 08:47.000
because we needed to test the functionality,

08:47.000 --> 08:50.000
especially if we automatically need it to work properly,

08:50.000 --> 08:53.000
and so a lot of tests were created for that.

08:53.000 --> 08:55.000
And that was it.

08:55.000 --> 08:57.000
It has not was happy.

08:57.000 --> 08:59.000
The product could be finished,

08:59.000 --> 09:01.000
and they page and everything is fine.

09:01.000 --> 09:05.000
Unfortunately, that's not what's fun.

09:05.000 --> 09:08.000
So it continued.

09:08.000 --> 09:14.000
Something happened in the beginning of 2020,

09:14.000 --> 09:19.000
the networks project started in the initiatives

09:19.000 --> 09:22.000
of working group with an aim working group A3CC.

09:22.000 --> 09:26.000
And wanted to improve the interface of networks

09:26.000 --> 09:29.000
that plug-in offers to use.

09:29.000 --> 09:31.000
And because I had created the plug-in,

09:31.000 --> 09:34.000
and because that plug-in obviously had some impact

09:34.000 --> 09:36.000
on some people use it already,

09:36.000 --> 09:39.000
they came to me and asked me to participate in that working group.

09:39.000 --> 09:42.000
Which was a surprisingly short-lived working group.

09:42.000 --> 09:46.000
We were about it for about six or eight more weeks.

09:46.000 --> 09:48.000
And then it was finished, and then it was closed.

09:48.000 --> 09:52.000
And the next networks were actually contained

09:52.000 --> 09:54.000
the changes that we had agreed upon.

09:54.000 --> 09:56.000
That was quite funny.

09:56.000 --> 09:58.000
So now,

09:58.000 --> 10:01.000
plug-ins could use a lot of features that networks has,

10:01.000 --> 10:03.000
that were formally not a lot to use,

10:03.000 --> 10:05.000
but to be used by plug-ins.

10:05.000 --> 10:07.000
Dynamic model choice fields, custom links,

10:07.000 --> 10:10.000
where it puts export effort and templates and so on.

10:10.000 --> 10:13.000
And some other standard features that networks has

10:13.000 --> 10:17.000
for many of the models that it uses

10:17.000 --> 10:20.000
like change logging, tagging, journaling.

10:20.000 --> 10:22.000
That is very useful.

10:22.000 --> 10:26.000
Then support for adding plug-ins specific top level menu items.

10:26.000 --> 10:30.000
Formally, before I started to work out the project,

10:30.000 --> 10:34.000
you could only find the plug-in menus under

10:34.000 --> 10:37.000
sub-menu item plugins,

10:37.000 --> 10:39.000
and then you had to look for it.

10:39.000 --> 10:43.000
Now, if you can define your plug-in top menu at

10:43.000 --> 10:47.000
a highest level of the menu, so you see it all the time.

10:47.000 --> 10:50.000
That's very useful because many people ask me,

10:50.000 --> 10:51.000
where is the plug-ins?

10:51.000 --> 10:52.000
Where is the menu for the DNS plug-in?

10:52.000 --> 10:54.000
Well, where is other under plugins?

10:54.000 --> 10:55.000
Can we move it up?

10:55.000 --> 10:56.000
No, we can't.

10:56.000 --> 10:57.000
Okay.

10:57.000 --> 10:58.000
That was possible.

10:58.000 --> 10:59.000
That's by then.

10:59.000 --> 11:02.000
And they made a very good plug-in development

11:02.000 --> 11:06.000
to tutorial and general implementation for developers.

11:06.000 --> 11:08.000
That was also very big improvements.

11:08.000 --> 11:12.000
So, in my point, from my point of view,

11:12.000 --> 11:15.000
A33 was a great success.

11:15.000 --> 11:18.000
So, what happened in 2020, too?

11:18.000 --> 11:23.000
That box 3.2 was released with the results of the working group.

11:23.000 --> 11:26.000
I implemented a lot of functions.

11:26.000 --> 11:31.000
I had worked around the limitations on.

11:31.000 --> 11:37.000
So, that could be removed and could be moved to the official functionality.

11:37.000 --> 11:42.000
I added support for the new GraphQL API, which was also not possible before.

11:42.000 --> 11:45.000
I added views to the data model.

11:45.000 --> 11:49.000
Because the data model, where the customer needed was not including views.

11:49.000 --> 11:52.000
They only had one zone, one level, one view.

11:52.000 --> 11:56.000
And I needed views for a couple of other customers and for my own environment.

11:56.000 --> 11:59.000
Because I used special DNS.

11:59.000 --> 12:06.000
Then I started to use DNS Python to validate names

12:06.000 --> 12:09.000
and format our data format.

12:09.000 --> 12:13.000
Because that is something you don't want to do yourself.

12:13.000 --> 12:15.000
A lot of record types around it.

12:15.000 --> 12:20.000
Sometimes the other data formats for these record types are very obscure.

12:20.000 --> 12:24.000
Support for PUNicode and IDNs.

12:24.000 --> 12:27.000
That actually was a by-product of using DNS Python.

12:27.000 --> 12:31.000
Because the DNS Python has very good support for PUNicode and IDNs.

12:31.000 --> 12:34.000
And support for the global search index.

12:34.000 --> 12:36.000
That is also a great network tool.

12:36.000 --> 12:39.000
We can enter something in the global search field.

12:39.000 --> 12:44.000
And then all the models and all the items that are somewhere in that box

12:44.000 --> 12:47.000
pop up that's matched the search.

12:47.000 --> 12:49.000
So that also works for DNS items.

12:49.000 --> 12:52.000
And all you can do is search for the DNS names and so on.

12:52.000 --> 12:54.000
That was pretty good.

12:54.000 --> 12:56.000
So 2023.

12:56.000 --> 12:59.000
Net box field 5 came along and started to implement

12:59.000 --> 13:03.000
the changes necessary to support net box field 5.

13:03.000 --> 13:08.000
And then nothing happened.

13:08.000 --> 13:10.000
The hours were not moved.

13:10.000 --> 13:12.000
It then has been not merged anymore.

13:12.000 --> 13:14.000
Nobody answered.

13:14.000 --> 13:17.000
So the project was obviously dead.

13:17.000 --> 13:20.000
And it is 2v6.

13:20.000 --> 13:23.000
So I had to fork it.

13:23.000 --> 13:31.000
I was thinking it was a decision that was had to be done very, very quickly

13:31.000 --> 13:33.000
because 2v5 was imminent.

13:33.000 --> 13:36.000
I wanted to support 3v5 from day one.

13:36.000 --> 13:39.000
But it was not possible because I couldn't merge anything.

13:39.000 --> 13:41.000
So I had to fork.

13:41.000 --> 13:45.000
With GitHub, it is no real problem to fork projects.

13:45.000 --> 13:48.000
You can use the net same name and so on and everything is fine.

13:48.000 --> 13:52.000
But with Python, the name net box DNS was taken already.

13:52.000 --> 13:53.000
By the old one.

13:53.000 --> 13:54.000
That was dead.

13:54.000 --> 13:56.000
So I needed to use a new name.

13:56.000 --> 13:58.000
And that was the first problem.

13:59.000 --> 14:05.000
The second problem I introduced by the decision to leave the directory three as it was.

14:05.000 --> 14:11.000
That was a good decision in terms of maintaining compatibility with interfaces.

14:11.000 --> 14:15.000
It was a very bad decision in terms of, well,

14:15.000 --> 14:20.000
what happens when you find out the project, the plugin you installed is dead.

14:20.000 --> 14:22.000
You install the new one.

14:22.000 --> 14:26.000
Then you install the new one and play around a bit with it.

14:26.000 --> 14:30.000
And after you did that, you removed the old one.

14:30.000 --> 14:33.000
But not good.

14:33.000 --> 14:37.000
So people broke the installations because of that.

14:37.000 --> 14:38.000
Not good.

14:38.000 --> 14:46.000
I had a number of issues that I had to answer and explain why what they did and why they could fix it.

14:46.000 --> 14:52.000
And the GitHub search always found the old plugin because it had a couple of hundred stars.

14:52.000 --> 14:54.000
And the new plugin was very new.

14:54.000 --> 14:56.000
And so it didn't have any stars and nobody found it.

14:56.000 --> 15:01.000
All the people opened pi hours and opened issues and so on in the old one.

15:01.000 --> 15:06.000
And I moved them over to the new one.

15:06.000 --> 15:08.000
So after that was done.

15:08.000 --> 15:10.000
I could finish port internet box view of ice.

15:10.000 --> 15:13.000
I could add a lot of validation.

15:13.000 --> 15:14.000
I mentioned it earlier.

15:14.000 --> 15:16.000
Single, single names and so on.

15:16.000 --> 15:19.000
I could add a lot of validation for a bit more obscure case.

15:19.000 --> 15:23.000
Someone came and said, well, I want to maintain my route zone.

15:23.000 --> 15:27.000
My custom route zone in Netflix.

15:27.000 --> 15:31.000
Which wasn't possible because you couldn't enter an empty zone name.

15:31.000 --> 15:34.000
And so it's possible that was added as well.

15:34.000 --> 15:48.000
And there was very good contribution by another user who made the first attempt of integrating between the iPad module of Netflix with DNS.

15:49.000 --> 15:51.000
Which is not as easy as it sounds.

15:51.000 --> 15:54.000
Because I mentioned there is only the DNS name field.

15:54.000 --> 15:59.000
And you have to find the matching zones.

15:59.000 --> 16:06.000
And well, what he did was signing zones manually to IP addresses.

16:06.000 --> 16:08.000
And defining names manually.

16:08.000 --> 16:13.000
And then you had integration between the iPad and DNS address.

16:13.000 --> 16:16.000
And the DNS address record for it.

16:16.000 --> 16:21.000
And the pointer record, which worked pretty well, but had some limitations.

16:21.000 --> 16:24.000
So, 2024.

16:24.000 --> 16:28.000
The next thing was figured by a user request.

16:28.000 --> 16:32.000
They wanted to use our C20317.

16:32.000 --> 16:36.000
So, I tried to find a way to integrate that as well.

16:36.000 --> 16:39.000
I hope it has.

16:39.000 --> 16:42.000
It worked sufficiently.

16:43.000 --> 16:48.000
I increased the level of validation for record types.

16:48.000 --> 16:52.000
I created a compatibility with a new box for version.

16:52.000 --> 16:57.000
Which was a bit more as thought than with a minor version update.

16:57.000 --> 17:06.000
And I developed a new one, a new way of implementing the link between the iPad and DNS.

17:06.000 --> 17:09.000
Which I will explain a bit later.

17:10.000 --> 17:14.000
And the added support for localization, which was possible since that box 3.7,

17:14.000 --> 17:17.000
and that box 4.0, it became really usable.

17:17.000 --> 17:22.000
I'll see, 23.7 is working on for an IPv4 problem.

17:22.000 --> 17:28.000
You can only delegate the reverse zones at Thought Levels.

17:28.000 --> 17:34.000
And many people and many organizations only have 25 to 49 domains.

17:34.000 --> 17:38.000
So, they actually can't manage the reverse domains.

17:38.000 --> 17:41.000
And I'll see 23.7.

17:41.000 --> 17:49.000
Works by, well, putting the pointer records for these zones in some other zones.

17:49.000 --> 17:55.000
And then creating C-names in the flash 24 version.

17:55.000 --> 17:59.000
The reverse zones can only be maintained by provider.

17:59.000 --> 18:05.000
But the C-names can then be managed by the people themselves.

18:05.000 --> 18:09.000
The new DNS sync works a bit different from the old one.

18:09.000 --> 18:14.000
And at least for my purposes and for the purpose of my customers a bit better.

18:14.000 --> 18:24.000
I create nothing between DNS and IPAM prefix to one or multiple DNS views.

18:24.000 --> 18:30.000
And when you know, the fun of DNS name for an IP address in the fixes.

18:30.000 --> 18:34.000
That was the NAS will look in all the views for a matching zone.

18:34.000 --> 18:39.000
And create the address record in the zones it finds.

18:39.000 --> 18:41.000
That works pretty well.

18:41.000 --> 18:43.000
It is still not perfect.

18:43.000 --> 18:44.000
It still has some limitations.

18:44.000 --> 18:48.000
But less than the former implementation I think it is pretty good compromise.

18:48.000 --> 18:53.000
And something I can do than in the future.

18:53.000 --> 18:56.000
So, what will come in 2025?

18:57.000 --> 18:59.000
Support for DNS sec.

18:59.000 --> 19:05.000
Actually, you don't have to do so much to support DNS sec because DNS sec normally is done by the name server itself.

19:05.000 --> 19:07.000
But by the signing, in line signing.

19:07.000 --> 19:11.000
But some fields can also be added to DNS zones.

19:11.000 --> 19:13.000
Like key algorithms.

19:13.000 --> 19:16.000
And whether to use Nsec or Nsec3.

19:16.000 --> 19:19.000
So there can be some support in that box DNS.

19:19.000 --> 19:21.000
Currently I am using custom fields for that.

19:21.000 --> 19:23.000
But it can also be native.

19:24.000 --> 19:28.000
Then an idea is to create so-called mirror zones.

19:28.000 --> 19:33.000
But mirror all the records or a specified subset of records.

19:33.000 --> 19:35.000
From one zone to another.

19:35.000 --> 19:40.000
Use case, for example, do you have an internal and external zone.

19:40.000 --> 19:44.000
And you want to have only a subset of the names in the internal zone.

19:44.000 --> 19:46.000
Actually, expose to the external zone.

19:46.000 --> 19:50.000
So that would be one of the use cases for mirror zones.

19:50.000 --> 19:53.000
Then extend support for zone delegation when you have a zone.

19:53.000 --> 19:54.000
And it's up zone.

19:54.000 --> 19:58.000
You can also automatically generate the delegation records and so on.

19:58.000 --> 20:03.000
That is also something that could be implemented and will be implemented in the midterm.

20:03.000 --> 20:07.000
And in such a favorite feature here, I'm open to feature requests.

20:07.000 --> 20:08.000
I'm open to suggestions.

20:08.000 --> 20:14.000
And if anyone has an idea, please open an issue or feature requests.

20:14.000 --> 20:15.000
Thank you.

20:15.000 --> 20:16.000
Thank you very much.

20:20.000 --> 20:22.000
Thank you.