In message <d6648036-0a7c-4ea1-ae39-325949b18...@verisign.com>, "Wessels, Duane" writes: > > Seeing Warren's recent draft on updates of DNSSEC trust anchors encouraged > me to finish and submit what I think may be a better method for tracking > trust anchor updates. I've described an edns-key-tag option, which puts > trust anchor key tags in the EDNS OPT record. It is modeled after RFC > 6975, which is a way that clients can signal to servers the DNSSEC algorithms > that they support. > > https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/ > > Feedback would be welcomed. > > Duane W.
This really doesn't help anyone decide whether it is safe to withdraw the old key which is the critical point of a trust key rollover. All it shows is one of the clients has installed the new TA. If a stub client has the new key but the recursive server doesn't you will have (old + new). Similarly when the situation is reversed. What we are aiming for is knowing when the new trust anchor is universally installed. This requires that the common subset of keyid's be sent rather then the union. This subset may be empty if someone fails to follow a TA rollover. This also requires guidance on for how long client TA sets should be kept so that the common subset can be completed. It the last x hours the common subset of all TA seen is this list. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
