[dns-operations] Documenting root slave operation Re: The (very) uneven distribution of DNS root servers on the Internet
ogud at ogud.com
Thu May 17 18:21:58 UTC 2012
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
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
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
With an mechanism like the one above I can see MarkA hacking up his
resolver to add a configuration option
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.
More information about the dns-operations