Andrew Sullivan wrote:
On Fri, Aug 22, 2008 at 12:01:16AM +1000, Mark Andrews wrote:
The issues David was pointing out have been visible for years. So
to has the recovery behaviour if one choose to look for it. There
is nothing new in what David has been saying.
I think you may be missing the import of what he's saying, though.
The entire deployment strategy for DNSSEC has been a gradual
deployment strategy, in which zone operators may start signing their
zones and expect zero effects for security-oblivious resolvers. That
assumption is still accurate, but we appear to have failed to think of
one class of deployment: the security-oblivious resolver operator with
a security-aware resolver.
Yes, some of those people are already running into the issues, and yes
the recovery is happening. But David was asking, "If we just start
signing now, will anything happen to people who don't care about
DNSSEC?" The answer, one might be surprised to learn, is, "Yes,
although probably nothing unrecoverable." That answer is not as
encouraging as, "No."
longer desirable now that DNSSEC is seeing deployment. It much
better to get the problems fixed and that requires noise.
Well, that's certainly true.
Here's a couple of leading questions (not directed at anyone in
particular, just whoever knows the answers):
How stable is the content of the root zone?
(Really, really stable, I'd guess.)
If a signed root zone were installed on the root servers for some period
of time, e.g. one refresh interval,
what would the effects be towards DNSSEC-configured caching, validating
resolvers?
And, if the signed root zone were pulled after that period, and replaced
with the unsigned version, how long
would the "good" aspects of the cached DNSSEC bits continue to be useful?
If the root zone were to "strobe" between signed and unsigned, what
minimum duration of "signed", and what
maximum duration of "unsigned" would be likely to not cause operational
problems for the aforementioned
DNSSEC-configured caching, validating resolvers?
I'm specifically pondering "short period signed, long period unsigned,
repeat again and again...".
And what about DNSSEC-capable, but non-DNSSEC-configured caches, when
used by DNSSEC-validating
clients? Does this differ from the first case (caching validating
resolvers)?
As a cautious first step, does this make sense? Or even doing this one
some subset of root servers or root server
instances?
It's kind of like dipping one's toe into bath water, to avoid getting
too badly burned, while still testing the waters.
Just thinking outside the box, out loud...
Brian Dickson
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
