WEBVTT 00:00.000 --> 00:07.000 We'll start with 10 minutes left. 00:07.000 --> 00:13.000 Next up, a late-distance schedule. 00:13.000 --> 00:17.000 We'll throw it in cash and we'll be talking about using a cut-look zone in the phone 00:17.000 --> 00:19.000 and it has to be clear. 00:19.000 --> 00:20.000 So early now. 00:20.000 --> 00:22.000 Do you want to start doing? 00:22.000 --> 00:24.000 No, we're in late. 00:24.000 --> 00:25.000 Yeah, yeah. 00:25.000 --> 00:27.000 So recursion of cut-look zones. 00:28.000 --> 00:30.000 The problem. 00:30.000 --> 00:31.000 Space. 00:31.000 --> 00:34.000 If you run a recursor, power it in as recursor, 00:34.000 --> 00:36.000 some other recursory solfer. 00:36.000 --> 00:39.000 It often happens that you have special zones. 00:39.000 --> 00:44.000 Sones that need to be treated special in a way that they have to be sent to a specific 00:44.000 --> 00:46.000 authoritative receiver. 00:46.000 --> 00:49.000 A authoritative server, for example. 00:49.000 --> 00:51.000 Local zones. 00:51.000 --> 00:54.000 Sones or split horizon zones. 00:54.000 --> 00:57.000 Sones that are not ordinary public zones. 00:57.000 --> 01:00.000 Those zones, those forwards, 01:00.000 --> 01:06.000 often depend on specific configuration of your authoritative server that serve those 01:06.000 --> 01:07.000 zones. 01:07.000 --> 01:10.000 If a zone gets created, you have to update recursor. 01:10.000 --> 01:12.000 That points to that zone. 01:12.000 --> 01:14.000 So the forwards. 01:14.000 --> 01:17.000 In your recursor are probably multiple recursor. 01:17.000 --> 01:23.000 Depends on configuration that's happening elsewhere. 01:23.000 --> 01:25.000 Well, there are many ways to do that. 01:25.000 --> 01:28.000 By hand, of course. 01:28.000 --> 01:33.000 We also know that that probably won't go right all the time. 01:33.000 --> 01:39.000 You can maybe create some scripts to get your specific zones from an 01:39.000 --> 01:46.000 authoritative server setup to some mingling, text mingling and load that 01:46.000 --> 01:49.000 configuration into a recursor. 01:49.000 --> 01:54.000 Some parameters recursor also has an API to do that. 01:54.000 --> 01:59.000 You can manipulate the forwarding tables using an API. 01:59.000 --> 02:04.000 But it also requires custom scripting to actually get the information from the author 02:04.000 --> 02:11.000 setup and what complicates matrices is it is often the case that the authoritative 02:11.000 --> 02:15.000 server is managed by a different party or different admin and recursor. 02:15.000 --> 02:19.000 So you have to do co-ordination. 02:19.000 --> 02:27.000 Well, that's also a source of issues, at least in many cases. 02:27.000 --> 02:35.000 And so what you would like to have is a way to automatically define forwarding 02:35.000 --> 02:41.000 zones in a recursor-free solver based on data coming from an authoritative server. 02:41.000 --> 02:46.000 And we investigate catalog zones to do that. 02:46.000 --> 02:48.000 So what are catalog zones? 02:48.000 --> 02:53.000 The catalog zone is actually a DNS zone, but it's a special zone, which tells 02:53.000 --> 03:00.000 other authoritative server, which zones actually exist on an authoritative server. 03:00.000 --> 03:09.000 And their main goal is to synchronize the configuration of a primary authoritative server with 03:09.000 --> 03:10.000 secondaries. 03:10.000 --> 03:15.000 So if a zone gets curated on a primary server that is secondary server knows that, 03:16.000 --> 03:18.000 can update its internal configuration. 03:18.000 --> 03:28.000 And also when a zone is deleted, that the deletion happens on the secondary server. 03:28.000 --> 03:33.000 Catalog zones as the name implies are shown to themselves. 03:33.000 --> 03:39.000 The NES people like to model the world into zone data. 03:39.000 --> 03:46.000 Our PC zones is another example of modeling data into a zone format. 03:46.000 --> 03:51.000 But the nice thing is, because it's a zone, you can transfer it using the known well known 03:51.000 --> 03:57.000 transfer mechanisms, IXFR or AIXFR. 03:57.000 --> 04:08.000 And so what we did is using existing XFR code in the recursor. 04:08.000 --> 04:13.000 That code already existed to retrieve RBC zones. 04:13.000 --> 04:20.000 We used that to retrieve a catalog zone, do some processing and calling the internal API code 04:20.000 --> 04:31.000 to transform that catalog zone into a set of forebarning definitions for the recursor. 04:31.000 --> 04:36.000 And so this was a very quick talk. 04:37.000 --> 04:39.000 You want to go to your example? 04:39.000 --> 04:43.000 I will show an example, and then what Kevin will actually. 04:43.000 --> 04:46.000 So this is the way it looks. 04:46.000 --> 04:51.000 You define a catalog zone, which is to be transformed from some authoritative server 04:51.000 --> 04:54.000 or could be a couple of those. 04:54.000 --> 05:01.000 And for each zone in that catalog zone, a forebarning will be defined with a target forebarning IP address. 05:01.000 --> 05:08.000 And if a zone a catalog zone member is in a group, which is optional thing, a catalog zone can do. 05:08.000 --> 05:13.000 It will use some other definition to define the forebarning. 05:13.000 --> 05:20.000 And Kevin will now discuss how we use that in his production environment. 05:20.000 --> 05:21.000 Yep. 05:21.000 --> 05:31.000 So first I have to thank Otto for doing the implementation for this. 05:31.000 --> 05:35.000 I was the one who opened the feature request and had planned to do all the work and didn't do any of the work. 05:35.000 --> 05:36.000 He did all of it. 05:36.000 --> 05:37.000 So thank you for that. 05:37.000 --> 05:44.000 So I actually use this for another reason, besides the ones that Otto mentioned, which is all of my 05:44.000 --> 05:50.000 connectivity inside my land is all done using DNS all in public domains. 05:50.000 --> 05:53.000 But sometimes my ISP link is down. 05:53.000 --> 05:58.000 And then that means I can't even get into my own machines, including the router to figure out why the link is down, 05:58.000 --> 06:00.000 because I use DNS names for everything. 06:00.000 --> 06:06.000 So that means I want to have a local authoritative server that the recursor can talk to, that knows how to resolve my domains, 06:06.000 --> 06:09.000 even if it can't get to the internet. 06:09.000 --> 06:15.000 And on top of that I use DNS sec, which would be even worse if you can't reach the internet, because it won't validate anything. 06:15.000 --> 06:17.000 So this has worked out extremely well. 06:17.000 --> 06:23.000 It means now when I make changes, all of the changes to automatically happen in all of my authoritative servers and in the 06:23.000 --> 06:25.000 recursors and multiple locations. 06:25.000 --> 06:28.000 And one of the things we needed to mention there is, 06:28.000 --> 06:34.000 pardonous recursors supports incoming notifies, which were originally implemented by me, 06:35.000 --> 06:37.000 just to wipe caches, so you could say, 06:37.000 --> 06:40.000 if this zones content have changed in your authoritative server, 06:40.000 --> 06:42.000 forget anything you might have in your cache, 06:42.000 --> 06:46.000 but auto extended that so now when it pulls a catalog zone down, 06:46.000 --> 06:48.000 if the catalog zone itself changes, 06:48.000 --> 06:51.000 the authoritative server can tell the recursor, 06:51.000 --> 06:53.000 the catalog zone has changed, 06:53.000 --> 06:56.000 please re-download it and update your list of forwarders. 06:56.000 --> 06:59.000 So this has all come together very, very smoothly. 06:59.000 --> 07:01.000 And I think we're done. 07:01.000 --> 07:02.000 All right. 07:02.000 --> 07:04.000 Unless we're going to take questions. 07:04.000 --> 07:05.000 Do we have time for that? 07:09.000 --> 07:10.000 Okay. 07:10.000 --> 07:11.000 Anybody have a question? 07:11.000 --> 07:13.000 If not, we have a question. 07:22.000 --> 07:26.000 I don't think there's been any other attempt to try to do this in the recursor. 07:26.000 --> 07:27.000 I'm sorry, yeah. 07:28.000 --> 07:32.000 The question was, was there any other attempt to do this in another way in the recursor? 07:32.000 --> 07:34.000 In the power DNS authoritative server, 07:34.000 --> 07:35.000 there are other methods. 07:35.000 --> 07:39.000 The auto primary auto secondary thing solved much of the same problem, 07:39.000 --> 07:41.000 but was not a standardized method, 07:41.000 --> 07:43.000 so it was unique to power DNS. 07:43.000 --> 07:46.000 This is not since it's just part of DNS itself. 07:46.000 --> 07:52.000 So I think that it really became clearer that you could do this in the recursor 07:52.000 --> 07:55.000 once you could do it in a non proprietary way. 07:56.000 --> 07:57.000 All right. 07:57.000 --> 07:58.000 Thank you.