David Conrad wrote:
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.
That's reasonably stable, I'd say.
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.
For the root zone itself, it looks like the minimum is 86400, and lots
of RRs in the zone have various longer TTLs, such as 518400 (for the
authority records for "."), and 3600000 for A records for
[a-m].root-servers.net.
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?
Yes, it would. The question is, if there is a cached (validated) RRset
for the whole root zone, would the result of an attempted refresh where
the validation fails, result in the cached version still being kept and
considered valid?
In which case, things that normally trigger SOA serial number changes,
would ideally trigger the chain:
a) root zone content change
b) root zone SOA SN change
c) root zone gets signed
d) root zone SOA SN increments
e) serve signed root zone for TTL(refresh) * N + M (for some values N and M)
f) strip signatures from root zone, but don't change TTL (yes, I know,
bad practice, danger, danger, high voltage!)
or
f) strip signatures from root zone, increment TTL, server for
TTL(something else)
When time-out of TTL(something else) occurs, or when a change to the
root zone content is needed (including any new DS on child zone(s)), go
to (a).
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).
Perhaps this could be handled for volunteer clients, via extra rules on
the front-end load balancers on one or more root zone instances.
It is also conceivable that load balancers could look at D0 and choose
root server back-end instances based on whether or not DNSSEC versions
of the root zone make sense.
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
