-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul,
On 04/19/2011 07:10 PM, Paul Wouters wrote: > 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? The losing operator still needs to publish the DNSKEYs of the winning operator. Otherwise, you can get in a situation where a validator fetches RRs from the gaining operators name server, but still have the losing operator DNSKEY RRset in cache (that thus does not contain the DNSKEYs of the winning operator). Best regards, Matthijs > Paul > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrpymAAoJEA8yVCPsQCW5JfYH/1LUWOXjtuKlAUZE9qzGYO0L wERbYJKxQIs8PBRn42Cl9syJGbmM2L37ebPXGl0lcjoRP5bSKU7mZj4Ksq+MZQ3s iHap6l+7nmA4rmCx7G64EKlF7cqMjrh1Eq0PnW8OZmpWUP2lokPEYa2fSjWBl1Y7 KWnEpL2SQ+1v5RbLOhCFgmn0daQJVh3eWpAltPLKdJaCakcQA7ua3rXvNQhh+hvg tjRJdFfCSeNiR+ismIJnZxCzqXDijySF2EOki5i86puRtfJQBnNqSPu+44wrrIrh 9iaB+xDhziWlW0LIkKQ8/ZwSyQezvuMwx86lT2bWBOgQMxTJ5NK39+hGObT3a58= =s+ku -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
