On Tue, 19 Apr 2011, Antoin Verschuren wrote:
Section 4.3.5.2, first paragraph:
"If the registry and registrars allow for DS records to be published,
that do not point to a published DNSKEY in the child zone, the
Double-DS KSK Rollover is preferred to resolve the non-cooperative
case."
I think this should be:
"the Double-DS KSK Rollover is preferred to resolve the cooperative
case."
In the non-cooperative case even a Double-DS does not make sense, and
one should go insecure.
I'm not sure if this is true in all cases.
Let's split the cases of non-cooperative. I think these will be:
1) shut down all dns
2) make no changes
3) make malicious changes
Against 1) and 3) you cannot do much (technically). Queries going to
the losing DNS operator will be manipulated, with or without valid
RRSIGs. One could argue here to immediately drop their DS record so
at least their manipulation does not enjoy the protection of DNSSEC
validation. Putting in your own DS might even change those queries from
"insecure" to "bogus", which would be even better.
For queries that do not go to the losing DNS operator, having a new DS record
would cause new queries to be "secure" instead of "insecure".
For queries that have partially cached trust paths, adding your new DS
won't hurt, removing the old DS might make it better
So with this case, I agree with you. But these are likely the more rare
cases.
2) I believe is the more common case. It is eve more important to child
centric zones. Adding a DS won't hurt, and leaving the old DS in there
won't hurt either. Once most of the child centric zones finally caught
up with the new parents, the old DS can be removed.
Perhaps it is worth splitting the non-cooperative in these use cases?
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
