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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
