Hi Paul,
I disagree with some of your assumptions, and therefore also with your
conclusions:
On 15. 07. 25 17:02, Paul Wouters wrote:
Just count the numbers
of validation failures in the chain.
This is understandable from the resolver view -- the resolver simply
needs to limit the amount of work per inbound query.
However, this is also terribly wrong. How can a zone operator rely on
things that happen in the parent zone, or anything above in the chain?
What if the root zone generates ZSKs and KSKs independently (it does),
the TLD uses Offline KSK (it often does) and the user's SLD employs
multi-signer (as we often recommend)? Or if the user operates 2nd and
3rd level domains with similar multi-signer setups...
so the best course of action is to do
nothing to the protocol.
The protocol is broken right now. The authoritative operators/vendors
are not instructed (or even warned) to do anything with keytag
conflicts, and some major resolver vendors unilaterally invented and
implemented a feature that makes the resolution randomly fail. The issue
is sneaky because it happens with very low probablility (something like
1/64k^2 * #ofZonesVulnerableToKeytagConflict), it might not yet have
even happened at all, but it might break things terribly. The best
course of action is to invent clear rules for both sides, such that if
obeyed, the resolution will work 100.00000% of the time.
Libor
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
