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