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?
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
