[dns-operations] Documenting root slave operation Re: The (very) uneven distribution of DNS root servers on the Internet

[Olafur Gudmundsson]

On 17/05/2012 09:21, Andrew Sullivan wrote:
> On Wed, May 16, 2012 at 08:52:26PM -0400, Joe Abley wrote:
>>
>> All the possible outcomes I can think of that lie in this direction
>> winds up with pockets of broken DNS due to infrastructure that none
>> of the current operators can identify, and failures that affect only
>> a subset of users so that a fix is not necessarily obvious.
>
> I agree with Joe.  When I worked at a TLD registry company, we had a
> very similar case occur when a large ISP in one country was slaving
> the cc TLD zone for that country, and we didn't know it.  We made some
> infrastructure changes, and their slave stopped getting up to date
> copies of the zone, but they didn't check their logs.  Months later,
> we started getting complaints about updates not propagating to the
> zone; it was, of course, that that ISP had a months-old copy of the
> zone.  It took a long time to figure out what the problem was, because
> we had no idea that this was going on.  This particular incident
> sticks in my mind because it affected so many people (one of whom was
> some minister's brother or something, which of course made it all much
> worse), but I remember more than one such incident happening.
>
> I think this would happen to the root zone, too, and that seems worse
> than just one ccTLD.  Encouraging random people to keep local copies
> of the root without anyone knowing about it is almost certainly an
> excellent way to cause more DNS failures.
>

I think the point that PaulV has been making is lets document the best 
practices and learn from past mistakes and contain errors.
I can easily envision the document covering this case by saying:
"if you provision a root zone copy in your organization all your 
resolvers SHOULD do DNSSEC validation"

The reason is if they stop fetching the root zone then they will find 
out the hard way about a week later.
For this reason the document should also contain what to do if things go 
wrong.


Thus the document should say something like:
----
The root zone can be slaved from following server addresses
	axfr.foo.bar.example. port 9923
	xfr.bar. .... port n

You should configure your zone transfer statement to use multiple 
servers, you should regularly check that the servers listed are still 
active.
------

I can see having the current list of XFR servers listed in the the DNS.
_axfr._tcp.root-servers.net. SRV 10 10  9923 axfr.foo.bar.example

(root-servers.net. selected as I do not want to add anything to the root 
zone itself).

With an mechanism like the one above I can see MarkA hacking up his 
resolver to add a configuration option
	slave-root;
that will do all the magic and requires no other server configuration.

We can even add integrity checks to the root zone so that unsigned NS 
records are protected, something similar to SIG(AXFR) from the earliest 
DNSSEC drafts, but now publish them somewhere else and tie the check to 
the root zone serial number.
	
	Olafur



> Best,
>
> A
>