-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul,
On 04/20/2011 04:30 PM, Paul Wouters wrote: > On Wed, 20 Apr 2011, Matthijs Mekking wrote: > >>> 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). > > How would the RRs be fetched from the new operator? That means the NS > set was updated. For which it needed the new DS to confirm the NS set. > In which case there might be old (validated) cache from the losing > operator, > but no new records from that losing operator needing old DNSKEYs? Suppose 11111 is the keytag of the DNSKEY of the losing operator and 22222 is the keytag of the DNSKEY of the winning operator. I have still in my cache the DNKEY RRset with only the 11111 keytag. I have received a request for <www.example.com A>. It is not in the cache, I am going to query for it. The NS set was updated, pointing me to the version of the zone of the winning operator. www.example.com A 1.2.3.4 www.example.com RRSIG A ... 22222 example.com ... Signature made with keytag 22222 does not match the cached DNSKEY RRset with key 11111. Best regards, Matthijs > > Paul > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > 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/ iQEcBAEBAgAGBQJNr9nxAAoJEA8yVCPsQCW5UFkH/ijaxFmbtTz/24p4lI2FPo9e UABSsdrThqf5Ttd7HxHCSeZAIgjduzN5srJ8DRSJRvJJvTaafDUvvgbY8T+PDbCH I1+BXzzsJtaXPwf2C0c8rZEQYm+ouUVvUPeD8mHaNHR86/2XHDksbZBz/BPaP8l9 +hYwTfrC2ElwBvUBg4uIap9RBGL2oRXjnlKlYdRLGnBVCXmgD9cYUGrBbQXl6UpX IoWTkwNzeZY04B7NbTseCo9SJs6VWLSYKGrvP2ADjtt3uWPLzKtVfLFg8zf5PCFf KXjZ8KBOFJwsLla9FcTkKRwhUFqFlGRkWTzMSENoCivOHJHFx5BC7Nrc9l4sEIY= =fTTo -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
