Brian,
On Aug 21, 2008, at 8:45 AM, Brian Dickson wrote:
How stable is the content of the root zone?
(Really, really stable, I'd guess.)
On average, there are about 20-30 changes to the root zone per month
(not including SOA serial number increments) with the trend
increasing. August has been a bit special (48 changes to date) due to
the Kaminsky thing.
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?
If the validating caching name server operators configured the root
trust anchor, they'd be able to validate chains of trust up to the
root and be able to remove the trust anchors they've configured for
signed TLDs.
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?
Obviously depends on the validity period of the signatures and the TTL
of the RRs.
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 unclear how going from a signed root zone to an unsigned root zone
would work. If you've configured your root trust anchor and you get
back a response that isn't signed, wouldn't that be treated as a
validation failure?
I'm specifically pondering "short period signed, long period
unsigned, repeat again and again...".
This would seem to maximize the chances for instability.
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)?
Implementation decision, I suspect.
As a cautious first step, does this make sense?
Doesn't appear to to me.
Or even doing this one some subset of root servers or root server
instances?
I think it would likely be a mistake for the root servers to not be
serving the same data. It would probably be challenging to debug for
most folks.
Now, I've always thought a separate root infrastructure that you had
to opt in to would be a good way to go, but this quickly gets bogged
down in extremely annoying (at least to me) layer 9 politics and I'll
let someone else try to push that boulder up the mountain this time
(Who me? Bitter? Never).
Regards,
-drc
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
