[00:00.000 --> 00:13.360] Alright. Hello everyone. Thank you for packing the room. No pressure. As Peter mentioned, [00:13.360 --> 00:16.980] I'm Kevin Fleming. I've actually spoken at FOSDM quite a few times before but never [00:16.980 --> 00:22.240] in the DNS room. So this was a bit of a stretch to think that I might even get a talk accepted [00:22.240 --> 00:28.200] here and I'm thankful both that the team did and that you all decided to show up. So as [00:28.200 --> 00:34.320] he mentioned, I don't know if I called a mistake. I made a decision a few years ago about something [00:34.320 --> 00:39.360] that I wanted to do differently than I had been doing and as a result I am now running [00:39.360 --> 00:46.880] my own public DNS server. This is done for personal basis. I don't do this for pay or [00:46.880 --> 00:51.000] anything like that. It's the zero profit part. Nobody pays me to do this. In fact, it actually [00:51.000 --> 00:56.840] costs money so it's negative profit really if you want to think about it that way. Also, [00:56.840 --> 01:03.080] this is a bit odd but I wrote these slides in a somewhat unusual way where every title [01:03.080 --> 01:08.880] of a slide is actually a question from the audience which I will then answer in the slide. [01:08.880 --> 01:14.080] They get somewhat humorous further into the presentation. So if someone in the audience [01:14.080 --> 01:18.760] wants to play the role of the person asking the questions as we go to each slide that would [01:18.760 --> 01:23.360] be fantastic. In fact, you could all do it as a group. That would be even more fantastic. [01:23.360 --> 01:28.360] So if you decide to do that, that's great. If not, I will be happy to read them. [01:28.360 --> 01:37.640] Yes, exactly. So start off with everybody in the audience who currently is responsible [01:37.640 --> 01:41.280] for running authoritative name servers that are reachable on the public internet. Raise [01:41.280 --> 01:52.400] your hand and keep your hand up. Now, if you have your hand up but you're doing that because [01:52.400 --> 02:01.440] you run an internet service provider, put your hand down. So we're down to less than [02:01.440 --> 02:04.320] a quarter of the ones who had their hands up originally. That's more than I thought actually. [02:04.320 --> 02:11.400] I didn't think as many people were as strange as I am. So you can see what this up, I already [02:11.400 --> 02:16.440] covered most of this anyway. It's relatively easy to do obviously because this is phosom. [02:16.440 --> 02:20.160] I wouldn't be talking about if it required non-free software. It does not require anything [02:20.160 --> 02:25.560] that's non-free software. It can be fun for the subset of humanity that would come to [02:25.560 --> 02:30.680] a room like this. And it's also not expensive to do. [02:30.680 --> 02:33.440] So all right, now we're ready. We're going to the next slide. [02:33.440 --> 02:35.760] Okay, why don't you? [02:35.760 --> 02:41.160] Yeah, all right. Why would we do something like this? So the fun part we already covered. [02:41.160 --> 02:48.040] The second part is, for years in my personal infrastructure, I had been using, you're probably [02:48.040 --> 02:50.960] not familiar with Hurricane Electric. Most of them are bigger in the U.S. than they are [02:50.960 --> 02:54.960] here for hosting things. But the effort of free DNS hosting service, which I'd been [02:54.960 --> 03:02.560] using, was working fine. And then I decided I wanted to sort of enhance my DNS usage and [03:02.560 --> 03:08.640] implement DNSSEC for SSHFP records so I could stop having to deal with SSHP distribution [03:08.640 --> 03:15.880] issues. And a couple of other things, like I wanted to get real TLS certificates for [03:15.880 --> 03:20.720] all of my services. And of course, five years ago, Let's Encrypt was just a new thing. [03:20.720 --> 03:24.400] And DNS challenges were the best way to do that, blah, blah, blah. [03:24.400 --> 03:31.280] So the things I wanted, the DNS hosting service that I was using did not offer. So I thought, [03:31.280 --> 03:35.120] fine, I'll go find a different one. And I can't even remember where it came from. [03:35.120 --> 03:40.000] But years ago, some wonderful person on the Internet used to maintain a Google spreadsheet [03:40.000 --> 03:46.520] of all of the DNS hosting providers, commercial and otherwise, and all these different attributes [03:46.520 --> 03:51.720] of what they supported. And so I went to that spreadsheet and I filtered down to all the [03:51.720 --> 03:56.720] ones that had the things that I wanted. And there were three or four left. And none of [03:56.720 --> 04:02.480] them were ones I would actually have wanted to use. Most of them because the minimum cost [04:02.480 --> 04:06.480] was too high. They were designed for large enterprises that are doing this sort of thing [04:06.480 --> 04:11.240] all the time. So I thought, all right, fine. I will consider another alternative. [04:11.240 --> 04:20.480] All right. What do you need? So for those of you who have been around on the Internet [04:20.480 --> 04:24.560] for a much longer time than a lot of the people who I see in the room who aren't old enough [04:24.560 --> 04:31.760] for this, if you ever had to fill out the actual paperwork to register a domain name [04:31.760 --> 04:35.560] with network solutions and fax it to them, you will know what I'm talking about. For [04:35.560 --> 04:41.320] those of you who went way over your head, don't worry about it. So it used to be a [04:41.320 --> 04:45.640] long time ago that this was a really complicated thing to do. Today, it's not such a complicated [04:45.640 --> 04:49.880] thing to do. So these are the really simple things you need. You need some place to host [04:49.880 --> 04:54.680] the service that's going to be the source of truth for all of your zones. What do they [04:54.680 --> 04:58.800] contain? Obviously, you can choose to put that in lots of different places. I choose [04:58.800 --> 05:02.680] to put it on a private network that's not reachable from the Internet because it's better [05:02.680 --> 05:07.520] and more secure that way. You need a few places on the Internet where you can make your zones [05:07.520 --> 05:14.400] available to the Internet. Preferably, those are not all in the same machine or all on [05:14.400 --> 05:19.200] the same network or all on the same data center or preferably not even all on the same continent, [05:19.200 --> 05:23.160] really. It would be best if they're geographically distributed, if they're not all going to go [05:23.160 --> 05:27.500] down because you put them all in the same hosting provider and their control plane breaks [05:27.500 --> 05:32.880] all the time, Microsoft, and their entire cloud infrastructure goes down all at once [05:32.880 --> 05:38.040] around the world. So keep those things in mind when you decide where to put these things. [05:38.040 --> 05:42.280] It's perfectly fine to put these on Raspberry Pi's and your friends' houses if that's something [05:42.280 --> 05:45.960] you choose to do. If you have friends geographically distributed around the world who are willing [05:45.960 --> 05:50.480] to do that for you, that's fine. But there are plenty, and trust you, but there are plenty [05:50.480 --> 05:55.600] of other ways to do it as well. You will of course need DNS authoritative server software. [05:55.600 --> 05:59.880] There's lots of those out there. There's a bunch of people in this room who are responsible [05:59.880 --> 06:05.280] for Power DNS, so I'm thankful for giving me the chance to do this. And then, and this [06:05.280 --> 06:11.520] is actually trickier than you would seem, your domain register, the place you host your [06:11.520 --> 06:14.520] domains possibly, the also place you bought them from, although they don't have to be [06:14.520 --> 06:18.920] the same, needs to let you have the tools to set this up. They need to be able to let [06:18.920 --> 06:23.240] you specify your own name servers, not all of them will. And if you want to do DNS sec, [06:23.240 --> 06:28.920] they have to let you upload DNS records for your signing keys for your zones. Fewer of [06:28.920 --> 06:32.960] them will do that. Many of them that are especially the free ones do not give you the ability [06:32.960 --> 06:33.960] to do that. [06:33.960 --> 06:37.960] Is that really enough? [06:37.960 --> 06:44.920] Yeah. That's really it. There's not a whole lot required to do this. Now, this is all [06:44.920 --> 06:48.960] written from the point of view of me doing this personally. I would actually be happy [06:48.960 --> 06:53.360] to use the same kind of structure if I was doing this for, let's say, a small on profit [06:53.360 --> 06:58.240] organization or something like that. I would not go in this specific direction if I was [06:58.240 --> 07:02.240] responsible for doing this for 10,000 domains for a bunch of people who are paying me to [07:02.240 --> 07:08.280] do that. Things would have to be much more complicated in that situation. But now, going [07:08.280 --> 07:14.280] back to the way things were decades and decades ago, network solutions time, back then we [07:14.280 --> 07:20.360] did not have Google public DNS, cloud for our public DNS, quad nine public DNS, massive [07:20.360 --> 07:25.880] ISPs with millions and millions or billions of subscribers that ran resolvers on behalf [07:25.880 --> 07:31.880] of their clients. So back then, if you wanted to host your own zones, your own authoritative [07:31.880 --> 07:36.280] servers, pretty much every like small chunk of the internet was going to, if it needed [07:36.280 --> 07:41.000] to know the answer for one of your names, it was going to be reaching out to your servers [07:41.000 --> 07:46.280] to get it because there was no caching layer in between them and you. That's no longer [07:46.280 --> 07:50.160] true. I mean, obviously, lots of us also run our own resolvers. And so we are going to [07:50.160 --> 07:57.200] be part of the noise that's hitting your authoritative servers. But if you have a website that millions [07:57.200 --> 08:03.160] and millions of people on mobile phones are going to touch, those mobile carriers resolvers [08:03.160 --> 08:07.000] are going to go ask your servers for the answers and then hold on to them for however long [08:07.000 --> 08:10.600] you've told them they're allowed to hold on to them a day or two days or a week or whatever [08:10.600 --> 08:15.320] is appropriate. So you don't really need big, beefy servers to do this. Really, really [08:15.320 --> 08:23.000] tiny little machines are perfectly fine for doing this sort of thing. Also, even the smallest [08:23.000 --> 08:29.000] machines you can get in clouds nowadays have multi gigahertz CPUs with very fast RAM. And [08:29.000 --> 08:34.280] as I think Stefan pointed out in his last talk, a normal, non-dynamic authoritative server [08:34.280 --> 08:38.480] is very fast. It's very predictable. It doesn't take a lot of time to come up with an answer. [08:38.480 --> 08:42.120] Probably all of the data it needs is in memory already anyway. So these are not, they don't [08:42.120 --> 08:44.120] have to be really super powerful machines. [08:44.120 --> 08:46.120] Why did you do this? [08:46.120 --> 08:49.720] Yeah. So I covered some of that already. Actually, I kind of did that backwards, didn't I? I [08:49.720 --> 08:54.920] talked about that before I was supposed to. Darn it. So a couple of the things that I [08:54.920 --> 09:00.840] ran into when I was doing the search was there was quite a few of the available ones. If [09:00.840 --> 09:04.760] you just wanted to host one or two zones, they were okay. The prices were reasonable, [09:04.760 --> 09:08.680] actually considered doing it. At the time, I think I had seven. Now, I've probably got [09:08.680 --> 09:13.280] 11 or 12 for various different purposes because we all just grab domain names for projects [09:13.280 --> 09:18.120] and then never use them for anything, but you keep them around. So I thought there was [09:18.120 --> 09:21.840] a thread on the Fediverse about that. People ran, it's one round of poll. How many domain [09:21.840 --> 09:27.800] names do you own that you've never used? The number was high. [09:27.800 --> 09:32.360] And so there were some where, you know, if you went above three, like it was $100 US dollars [09:32.360 --> 09:38.400] a month for the service to be able to do this. There were others who, shockingly, charged [09:38.400 --> 09:42.600] by query volume and not by the number of zones. It's like, well, I can't, I don't have to [09:42.600 --> 09:47.040] control over that. I mean, if someone starts hammering the servers, not paying attention [09:47.040 --> 09:52.360] to the TTLs, I don't want my bill to suddenly be $14,000 for this. This is crazy. So fine, [09:52.360 --> 09:55.920] we are not going to do that. All right, ready. [09:55.920 --> 09:57.640] What do you use today? [09:57.640 --> 10:04.160] Well, what do I use today? So, like probably a lot of people at POSDEM, I have at least [10:04.160 --> 10:09.640] one reasonably beefy computer at home, network storage appliance. So there's a container [10:09.640 --> 10:16.600] on that where I run the hidden primary authoritative server. Many people who, there was lots of [10:16.600 --> 10:20.760] people who will choose not to put things in Amazon Web Services. I'm not going to complain [10:20.760 --> 10:27.720] one way or the other, choose whatever you like. I will say that their ARM-based nano [10:27.720 --> 10:33.280] virtual machines are the cheapest machines I could find that were not VPSs, that I could [10:33.280 --> 10:37.240] actually install my own software on and open up my own ports and make them available to [10:37.240 --> 10:42.280] the internet. There are lots and lots and lots of cloud providers out there, obviously, [10:42.280 --> 10:47.600] and if you can do this with a, you know, one CPU, Graviton 2 nano instance, you can certainly [10:47.600 --> 10:52.160] do it with a Raspberry Pi or some other small computer like that. If you weren't trying [10:52.160 --> 10:56.240] to use PowerDNS, you could probably do it with an ESP32, although I don't think I want [10:56.240 --> 11:01.600] to try that, but you could probably do it. So, I have three, I have two of those and [11:01.600 --> 11:05.560] then I have a dedicated server in a data center which I use for off-site backups and running [11:05.560 --> 11:09.520] my mastodon server and matrix server and all that kind of stuff. I put another one there [11:09.520 --> 11:14.000] just because. And it gives me good distribution. One's on the west coast of the US, one's [11:14.000 --> 11:18.280] on a roughly east coast of North America, it's not in the US and Canada, and then one [11:18.280 --> 11:23.760] of them is in Europe, so that works out fairly well. So, and then in our home network, because [11:23.760 --> 11:29.880] my home network is wildly over-engineered, I have two PC engines, APUs, which are our [11:29.880 --> 11:33.840] border devices that connect us to the internet and handle all sorts of things. They're the [11:33.840 --> 11:37.880] ones that run the resolvers, the recursive resolvers my wife learned about when she [11:37.880 --> 11:42.280] saw the slides. And then, of course, they also have a copy, they also have authoritative [11:42.280 --> 11:49.160] servers sitting right next to the resolvers for a reason that I will talk about in a minute. [11:49.160 --> 11:53.560] And now, you don't have to read this because we're on the same topic. So, I use PowerDNS [11:53.560 --> 11:59.200] auth server on all of them. I use SQLite databases because they're really simple and [11:59.200 --> 12:03.840] I want to try to keep all of the machines except the primary as stateless as possible [12:03.840 --> 12:10.200] and simple to manage and deploy. That also means that I use DNS-based distribution of [12:10.200 --> 12:14.480] the data. So, it's not like a shared mass-equal database or any of that sort of much more [12:14.480 --> 12:19.360] complicated thing. But, again, since this is why I went back to before, I would not [12:19.360 --> 12:23.200] do this if I was doing this for 10,000 zones for paying customers. SQLite 3 would probably [12:23.200 --> 12:27.920] not be the best choice. Well, actually, SQLite 3 probably would be okay. AXR would not be [12:27.920 --> 12:33.560] okay in that situation because you'd be doing this constantly pushing out zone updates. [12:33.560 --> 12:38.440] And then, because I use Ansible to manage all of my infrastructure and since there was [12:38.440 --> 12:44.720] no actual good Ansible modules to poke at the PowerDNS API to create zones and manage [12:44.720 --> 12:49.160] them and set up TCIC keys, I wrote some, which there's a link to at the end of the presentation. [12:49.160 --> 12:55.480] What is that cost? Oh, I thought you were asking for the Ansible modules. Yeah, good [12:55.480 --> 13:02.440] job. Good job. Excellent. So, what is all this cost? So, you already got the NAS, putting [13:02.440 --> 13:07.240] another container and it's free, right? Especially if something is lightweight as a primary auth [13:07.240 --> 13:12.960] service server, almost no resources whatsoever. I translated all of the costs I'm paying [13:12.960 --> 13:19.240] AWS into Euro for you. You can see that it cost me less than four Euro a month to host [13:19.240 --> 13:24.960] those machines. Now, that includes paying for them for up front for three years. So, because [13:24.960 --> 13:29.320] of the AWS basically cuts the price in half if you do that as opposed to paying for it [13:29.320 --> 13:35.800] on a monthly basis. But, it's 78 Euro for three years. If you decide two years in that [13:35.800 --> 13:39.560] you don't want those machines located there anymore and you're basically throwing away [13:39.560 --> 13:43.080] 20 Euro of up front payment, that's not the end of the world. We're not talking about [13:43.080 --> 13:47.800] a gigantic amount of money here. And then, because I have the rented server and the other [13:47.800 --> 13:52.560] data center, putting a server on that was free as well. The software, of course, is [13:52.560 --> 13:59.040] all free and the modules I wrote are also free. So, cost is very low. The half of the [13:59.040 --> 14:06.400] cost per month is actually the storage cost from AWS for the root volume for the VMs. [14:06.400 --> 14:13.000] The actual cost of the VM is less than the storage cost if you do it this way. So, and [14:13.000 --> 14:17.360] they won't let you create a root VM, a root volume that's smaller than 8 gigabytes even [14:17.360 --> 14:24.440] if you don't need that much. That's the small, well, I'm using the Debian AMI and it has [14:24.440 --> 14:29.000] a hard-coded minimum of at least 8 gigabytes for the root volume. So, I suppose I could [14:29.000 --> 14:32.960] make my own and try to cut that down by another few pennies or something like that. So, what [14:32.960 --> 14:38.520] do I do with that? So, as I mentioned before briefly, all of the network infrastructure [14:38.520 --> 14:44.400] I manage uses real up-to-end group certificates for all a browser accessible and actually [14:44.400 --> 14:51.440] some non-browser accessible endpoints. I had been using self-signed certificates previously. [14:51.440 --> 14:54.280] For those of you who've done that, you know how painful that can be having to make [14:54.280 --> 14:59.520] sure that everything has the right CA certificate to trust them and everything has it. I don't [14:59.520 --> 15:03.880] want to do that anymore. So, much easier to use. Let's encrypt for that. Similar thing [15:03.880 --> 15:10.800] for SSH. All of this 25 different SSHable endpoints across this infrastructure. Managing [15:10.800 --> 15:15.840] root key rotation for them was a pain because then things that had copies of the public [15:15.840 --> 15:20.440] half of the key all had to be updated and everything else. Using SSHFP solves that problem [15:20.440 --> 15:26.040] entirely except that it requires DNSSEC. Well, I mean, open SSH requires that it be a signed [15:26.040 --> 15:32.880] answer for fairly good reasons. So, I'm not going to try to work around that. And then [15:32.880 --> 15:38.440] something I didn't mention before is doing this not only gives you access to be able [15:38.440 --> 15:45.440] to host all of the, you know, standards track RFC DNS records, you probably get to do lots [15:45.440 --> 15:51.520] of cool things that aren't actually standards track RFCs yet. So, for example, HTTPS records [15:51.520 --> 15:55.440] which are still just a draft and we don't even know if they're really going to end up [15:55.440 --> 16:00.400] being approved or not. It probably will. And Firefox and Chrome already know how to use [16:00.400 --> 16:06.720] them. I host all of those already for my HTTPS services because why not? It just took almost [16:06.720 --> 16:12.280] no effort to set it up. I do Ansible based management for all of this stuff. And then [16:12.280 --> 16:16.760] I'm sure that most of the open source auth servers out there can do online signing, but [16:16.760 --> 16:21.280] Power DNS auth server certainly can. So, I don't have to worry about, you know, regularly [16:21.280 --> 16:25.520] re-signing the zones and handling all the key to speech and everything else because it [16:25.520 --> 16:31.560] does all that for me. So, the last thing that's mentioned there, which I'll get to just a [16:31.560 --> 16:37.560] little bit, but I have it on purpose. How many of you know what catalog zones are? Wow. [16:37.560 --> 16:43.560] That's shocking because it's you. You wrote the code. Of course, you know what it is. [16:43.560 --> 16:50.280] So, catalog zones made this whole thing much simpler. In fact, we were joking dinner last [16:50.280 --> 16:55.160] night that there's probably would have had to be three slides in the section about how [16:55.160 --> 16:58.760] to do maintenance of all of this that don't have to exist anymore because catalog zones [16:58.760 --> 17:06.400] take care of the whole thing for you. So, I just led right into this, didn't I? So, [17:06.400 --> 17:11.880] obviously, new software releases have to be deployed. For the moment, although I know [17:11.880 --> 17:18.240] Peter's working on it, there aren't currently ARM64, AR64 packages in the Power DNS repos. [17:18.240 --> 17:23.240] So, I use their builder scripts to just build them myself and make publish my own packages [17:23.240 --> 17:26.640] to my machines to install them. Eventually, I won't have to do that first part and I'll [17:26.640 --> 17:32.440] just run app to get update and it'll install the new packages. And then whenever I need [17:32.440 --> 17:37.560] to add or remove zones, I go to my Ansible Playbooks and I change the list of zones that [17:37.560 --> 17:43.760] I want to maintain, go run them and they poke at the API to do the right things. First of [17:43.760 --> 17:50.120] all, make sure those zones now exist or no longer exist on the hidden primary server. [17:50.120 --> 17:53.840] And in the past, they also had to reach out to all of the other servers to make the corresponding [17:53.840 --> 17:57.360] change. So, every secondary had to know that you've added a new zone so that it could know [17:57.360 --> 18:02.160] a lot of the data. Catalog zones take care of all of that for me. So, now when I stand [18:02.160 --> 18:05.600] up a new secondary server, I only have to tell it which catalog zones it's supposed [18:05.600 --> 18:09.840] to pay attention to and which server those are supposed to come from and then it automatically [18:09.840 --> 18:14.040] populates its secondary zone list all by itself and it's automatically updated every [18:14.040 --> 18:20.120] time I add or remove zones. It takes, I don't know, a minute maybe for all of them to be [18:20.120 --> 18:26.040] updated and everything is happy. It's really fantastic. So, there's going to be more cool [18:26.040 --> 18:35.080] stuff we're going to do with that in the future. So, step zero, one, two, three, four, put [18:35.080 --> 18:39.240] them all together. That first one is the most important thing. Go find out what your domain [18:39.240 --> 18:44.120] registrar supports. If they don't give you the tools you need to be able to do this, [18:44.120 --> 18:47.400] you're going to have to move your domains to a different registrar or give up. Those [18:47.400 --> 18:53.320] are obviously two choices, equally valid. So, but there are lots and lots and lots of really [18:53.320 --> 18:58.080] good ones out there, different parts of the world. So, it's easy enough to find out. There's [18:58.080 --> 19:03.040] a very short list of things you need to be able to do. The biggest things are the DS [19:03.040 --> 19:07.080] record is probably going to be the most, the first thing to check. Will they let you upload [19:07.080 --> 19:11.560] DS records for your own zones? If they won't, you're dead. You can't do DNS sec with your [19:11.560 --> 19:17.360] zones and that registrar. You have to switch to somebody else. The one I currently use [19:17.360 --> 19:24.880] supports both IPv4 and IPv6 glue records, but only IPv4 through the web interface. IPv6 [19:24.880 --> 19:29.400] has to be done via support ticket, which is annoying, but it doesn't change very often, [19:29.400 --> 19:34.800] so I'm willing to live with that pain. So, decide which server-server software you want [19:34.800 --> 19:38.400] to use. Obviously, that's going to be an important decision for you. Decide where you want to [19:38.400 --> 19:43.760] put all the stuff, where you want it to live, both the hidden primary and all the secondaries. [19:43.760 --> 19:48.040] And then, how are you going to manage the zone list? And as you can see there, if your [19:48.040 --> 19:51.960] answer has happened to follow that category, you can do exactly what I did and be on your [19:51.960 --> 20:00.520] way. Now, a little bit of bonus here. I did write that as a question. I forgot I changed [20:00.520 --> 20:08.120] it. So, on those network appliances in our home network, I run the recursive resolver [20:08.120 --> 20:15.000] for all of the clients on the home network to use to resolve names. And with our last [20:15.000 --> 20:23.800] ISP, we had more outages than I would have liked to have. And once you start setting [20:23.800 --> 20:28.840] up something like this, you forget the IP addresses for all of your own infrastructure. [20:28.840 --> 20:36.040] You only know the names. And when you've made the zone signed and your resolvers can't [20:36.040 --> 20:42.120] reach the internet, they can't resolve any of the names because they can't, in my case, [20:42.120 --> 20:46.920] my domain is km6g.us, so they have to know what's signed at the root, what's signed [20:46.920 --> 20:52.440] at the US, what's signed and all that stuff, right? So, we would have very bizarre cases [20:52.440 --> 20:58.000] where things inside the network stopped working because our internet link was not working [20:58.000 --> 21:02.040] correctly even though the things we were trying to use didn't use the internet at all. They [21:02.040 --> 21:06.360] just couldn't talk to each other because they couldn't resolve names. So, now I have [21:06.360 --> 21:10.640] the resolvers sitting right with an authoritative server sitting right next to them that hosts [21:10.640 --> 21:16.160] all of our zones that nothing talks to except the resolver so that even if that box can't [21:16.160 --> 21:19.760] talk to the internet, it can still resolve any of our internal names with no problems [21:19.760 --> 21:25.800] at all. An additional thing there, thank you again to the... [21:25.800 --> 21:36.120] What's that? I am, yeah, yeah, so what happens here is a feature in the Power.DS recurser [21:36.120 --> 21:42.240] which I will say unabashedly, I wrote, which is that you can actually tell the auth server [21:42.240 --> 21:46.320] to set notifies to their recursers, which is not something you would think would have [21:46.320 --> 21:50.840] ever, I mean it's not something that's normal. It's really cool though because what we do [21:50.840 --> 21:55.120] is when that happens, the recurser says, aha, that's a notification from the authoritative [21:55.120 --> 21:58.960] server that any content I might have in my cache for that zone is probably stale, throw [21:58.960 --> 22:04.920] it all away. So that means if I've got internal infrastructure changes, I've moved the container [22:04.920 --> 22:09.040] to a different machine and its IP address has changed, within a minute everything that [22:09.040 --> 22:13.120] needs to use that will get the correct address as long as it's not running a local cache [22:13.120 --> 22:19.680] on the box itself. So, and then as I said, over engineering I used anycast and OSPF and [22:19.680 --> 22:25.280] all kinds of other stuff to reach the recurser resolver. So, there's a bunch of links, the [22:25.280 --> 22:29.760] slides all are up on the FOSDM website, so feel free to download them. All of these links [22:29.760 --> 22:35.120] are useful and you can see even the HTTPS thing which is not, not even a stent, what's [22:35.120 --> 22:41.600] that? Oh, you're right, I forgot to put that link in there. Tell me where it is and I'll [22:41.600 --> 22:49.600] add it. Yeah, so, and that's that, I have two and a half minutes left. So, so questions, [22:49.600 --> 22:56.960] yes sir? You said you wanted to be required to add, change DS records. For anyone else [22:56.960 --> 23:03.960] want to do, to do this, please note that some TLDs require you to send up the DNS key record [23:03.960 --> 23:07.920] and they will hash it to DS. Ah, okay. So, he just missed me a comment that depending [23:07.920 --> 23:13.080] on which TLD your zones are under, you may have to send a different thing for them depending [23:13.080 --> 23:20.080] on exactly what they want from you. So, that's fine, thank you. Don't fight, yes, that one. [23:20.080 --> 23:28.080] Just another comment, some TLDs are scanning for CDS, CDNSP and CDNs. Yes. So, you don't [23:28.080 --> 23:35.080] have to play with the registrar at all. Right. Emerging technology that's been around for [23:35.080 --> 23:40.680] a really long time. Yeah, so I just, so I had just a repeat that there are some top level [23:40.680 --> 23:45.160] domains not related to the registrar that will actually notice the correct type of records [23:45.160 --> 23:48.920] in your zone and pick up the keys from there so that you don't even have to manually update [23:48.920 --> 23:55.920] them when you change them or rotate them. Yes. Yes. Okay. Robust infrastructure but [23:55.920 --> 24:03.680] you still use only one DNS software. That's a good point. I have diversity and robust [24:03.680 --> 24:07.720] infrastructure but no diversity in the software. That's absolutely a good point. I'm okay [24:07.720 --> 24:21.800] with that risk though. Yes, sir. So, how do I ensure that I'm not under attack on the [24:21.800 --> 24:29.400] virtual machines and how do I apply CV updates? So, because of I'm a geek every Saturday morning [24:29.400 --> 24:33.880] before my wife gets up I run this gigantic Ansible playbook that goes and touches everything [24:33.880 --> 24:37.960] and applies all package updates and reboots and it needs to be rebooted and all of that [24:37.960 --> 24:43.800] sort of thing. So, I'm reasonably good there. Plus, on the public facing machines I have [24:43.800 --> 24:48.520] the Debian unattended upgrade thing in place so that if a really important thing gets a [24:48.520 --> 24:53.120] package update shut comes in and gets applied it will do it for itself. So, I don't have [24:53.120 --> 24:59.160] to restart that. What was the other question? What was the other part of that one? Oh, the [24:59.160 --> 25:07.160] attack thing. So, this is really cool. Those particular AWS VMs have a hard cap on the [25:07.160 --> 25:12.280] amount of CPU that they're allowed to use. So, if somebody tries to do a DOS attack [25:12.280 --> 25:18.680] on them they just stop getting responses. So, I don't have to do anything. It's just [25:18.680 --> 25:23.200] not granted that resolution of my zones would be harmed by that. But, these are personal [25:23.200 --> 25:28.480] zones. We're not hitting them all that hard from outside. So, that's kind of a neat feature [25:28.480 --> 25:32.440] that it's just a side effect of the way those particular VMs work is you're limited in how [25:32.440 --> 25:36.760] much CPU you can use. So, yep. And, are we out? [25:36.760 --> 25:37.760] Out of time, yeah. [25:37.760 --> 25:38.760] All right. Thank you, Captain. [25:38.760 --> 26:00.240] Thank you. Thank you all.