-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul,
On 04/21/2011 05:19 PM, Paul Wouters wrote: > On Thu, 21 Apr 2011, Matthijs Mekking wrote: > >> 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. > > How is the NS set "updated" without validating that NS set using the > DNSKEY set and DS record of the winning operator? How do you know which DNSKEY is from the winning operator? There are two DS records at the parent (DS 11111, DS 22222) and the first one matches the cached DNSKEY RR. Best regards, Matthijs >> 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. > > But you can only get here if you had followed the new glue at the TLD, > validated the new NS set at the new operator, using its new DNSKEY set, > for which you would need the new DS. So by the time you're passed the > NS set, you have all the DNSKEY's needed for other zone content. > > The situation described in the draft cannot happen for proper validators. > > Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNtsQSAAoJEA8yVCPsQCW5wTsH/0lKs5wCgXeSGlZIP5bNTZW2 a+kqxF4J1683nHUIO1F1b9Mw3x7nZvg2EnZWV3bdjOdy6rVPVUSVwXsJ6dYc8/R9 RDU2bhqw0yS8Ck2os2czyuLTk/jiWOHJsYe8xsY22vVpNgEAWaTXyWlbyMzppuWc QCPNBXqcC3u1MtqN7A64oVF3qN8RJ8FrL7MuF5fM1I5ph+WBYXGnDdT4r9Y+2fhu wRK1U1DcwFgqSpPIC7ksPVNeiCS7AKkIirDeNT0PRkQTEeuycOq5wlUEYmX1YJ7e 2xHB2vWdq04NcCsq5S8SWwFbXV1X9nHZszEBgqWgVgDmvLzZG1ICVVmtBSEJlOc= =oy2D -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
