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?
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
