 Hallo, welkom weer terug, onze volgende speaker is Leo van de Woestijn, die zal over wat hij zou willen zien in Catalogzones, maar deze prachtigheid is opgemaakt bij de DNA-developers. Floor is jou, in 15 minuten. Hallo, welkom en bedankt voor het zijn hier. Dit is mijn eerste presentatie, dus ik ben nervig, dus ik probeer te calmen, als ik te snel ga praten, dan laat ik me weten. Ook denk ik dat het een kort presentatie zal zijn na André en de andere kompliceerde presentaties. Nou, mijn naam is Leo van de Woestijn. Ik ben DNA-operator. Ik operateer een groot enicast voor de tweede grootste registreer. En besides that we have other name servers that do a lot of domain names, a couple of million. And we tried to maintain those. And I came across Catalogzones, which I found very interesting, but it wasn't that scalable yet. But still the concept I found interesting. It is, oh, you can put it in the back. You can put it in the back. So there's not much new. Shall I put it in the back? Yeah, maybe that's better. One moment. Sorry, interruption. So it's already a working concept. And another warning is that the presentation was prepared very quickly. And I have cold examples that have tiny phones. So if you want to see the codes, then maybe open already the slides on your laptop so you can read it, because maybe you cannot read it here. Okay, let's go. Well, as I said, I run in anycast. And of course I need to generate configurations. So I run like seven top level domain names on many locations. And I run them all in separate demons. So I ended up with hundreds of demons. So the way to configure this, the usual way I think is to use Python, Jinnja en Jamel en then synchronise that configuration and then you have to reload that configuration to be loaded. Yeah, that needs a profissioning place where you start your profissioning to those demons over out of bent. And yeah. So that's a common setup. Catalog zones contain the information that's like variable in your configuration. So basically the list of zones that you need to have loaded in your demon. The configuration of the demon is not so addressed, but the catalog zone is. So this is a code example that is working. What can I tell about it? Simply you have it in the master and your secondaries will load this. And then the PTRs on the right side you see the domain names that need to be loaded. And when you do a DDNS call on your master, the PTR record will be added or be removed. And then all your secondaries will load that zone or delete that zone. Yeah, so that this is simply working. I did that. It's fine. So but what I did is extending it a bit because not at the moment only bind supports catalog zones. And you want to use this concept also in other demons. So with the additional section on the bottom I can iterate over the zone. Oh, wait, I'm already at the next slide. So at the bottom here you see additional config that you can put in there like your masters. Like where to allow notifies from or allow transfer form. But the main important thing is the stuff on the top. So here is the stuff that I added. It's simply a zone and the record which I use for the integrity of the data. And it's a new record. I think it's still still draft. And you see the number 240 in there in that line. That is a field that is reserved for private use. So you can use it for putting hashes of parts of your records. And even just a part of the value of a resource record. That's all up to you. And I use it to generate a list of domain names. That I can compare in other demons if they're present or not. And then commands, vendor specific commands to do your mutations. So yeah, the benefit is that you don't need to reconfigure it. It goes automatically by the catalog shown is being refreshed. So yeah, it doesn't involve that much work anymore. Well, you don't need vendor specific commands for maintaining it. Well, actually, there's more lack of future thing because right now it's not supported yet. And you don't need additional support, which usually use R-sync or SCP of whatever you use to have your configuration proficient. For that you also don't need the user. Plus, let's say you serve DNS for multiple registries. Then you can have a catalog shown for each of your customer. And they can maintain that catalog shown. En then your secondary will add and delete domain names in those demons. Yeah, it simplifies a lot. I did a little bit of abuse of the RR type in the beginning to come to these results. Initially I wanted to use the NXT record, which is obsolete. It's the next record, sorry. Then I tried the Zona status record, which is assigned by ICANN. But it does not have a real RFC, it only had a draft. And therefore it's not supported in DNS Python nor in NSD. So the record does not exist in there. But while I was experimenting, then at the same time Cloudflare made the info record unabsolided. And that's then the record that I kind of abuse for this. So I still have a wish list that I would like to have added in the expired draft for catalog zones, which is define your masters with the SRV record. Let's see. Sorry, I have to read from a slide. Yeah, and do your masters a bit different. Well, the code example speaks for itself. So yeah, to have this standard, and I think additional work needs to be done. So I think I have to convince vendors of authoritative software to use this. But yeah, first it needs to be a standard. And I don't know how much enthusiasm there is for it. Yeah, so in Bind it's supported and in the others it's not. So for the ones that it's not supported, I now have to use additional software. And that I don't like so much, of course. So I will put code examples on my websites, which is dns.company slash cat zone. There's at the moment not that much yet, but I will soon put more stuff there. This is a list of references, which contain all the white papers and tutorials. I think you have to read it later on if you're interested. And that's the last slide, questions. Thank you, Leon. Oh, haha, this is Andrei ISC. So thank you, Leo. I thank you for being brave to doing your first presentation here. So with the catalogue zones, the situation is a little bit complicated because there's a draft lying in ITF, which nobody has the time to finish for the catalogue zones too. So if you want to be caught of the draft, it would be great because it needs more work. And then our implementation in Bayer needs to be updated to manage the new draft. We also have some other ideas what could be put into catalogue zones. But still, well, we had some plan and then the OH came en we just had to replan the thing. So DOH is the new kid on the block that's blocking all the... We consume a lot of that. Well, not all of it, but it consumes some of the time which we had to reserve for the catalogue zones. And then we need to synchronize with these faults, that those faults and the CZNIC who isn't here, but I don't know even if they are going to implement our catalogue zones yet. But yes, any help that anybody using catalogue zones can give us the DNS developers in terms of specification or even testing it, or even patches are always welcome. So if you are a DNS developer and care about catalogue zones and can you help with the bind code or NSD code or power DNS code, we all would like to accept patches from anybody. A good patches. Okay, thank you. I'd like to talk with that as well. Okay, that's nice to hear. This is Willem of Nounet Labs, who says he would like to help with that as well. Well, as it's question time, I can also ask you a question. Did anyone tried it in the audience? Catalogue zones in general? Yeah. Okay, that's not that much. But yeah, maybe if people understand the benefits of it. And speaking from power DNS, the problem we see is that we know everybody wants this, but none of the people that want this are our paying customers. There's no overlap there, which means we're not going to pull that card. Which means you. I think like power. Actually in my code example, if you look in my code example, it's here. So you see on the right a number, an ID for the domain name. And that's actually the power DNS domain ID. So you said you were doing an external implementation. The current power DNS experimental implementation is also external. It talks to the API. But I still, in 1989 I used power DNS, I think. And then I still have this database. The naming is still the same. And the other field that you see there left to the ID is the SOA. So then you can use it to look up in your local authority if you're in sync with the master. All right. Any other questions for Leo or from Leo? Okay. Thank you again. Thank you. My bad. We'll be back in five minutes with a final speaker.