On Thu, 30 Jul 2015, Wessels, Duane wrote:
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/
I thought about this too after Warren's suggested hack queries. Of
course since EDNS is hop-to-hop this would not survive from the client
to the root.
If we want to gain visibility, we could look at something where we
request that the validating client sends an additional root ksk query
to one the known root servers despite any forwarder settings. While it
might get filtered out, it would at least give the root some visibility
into percentages of clients that have rolled to the new key. If we do
this, than I think using edns instead of the hacked query would be a
cleaner implementation.
Additionally, Mark brought up a good point that if you are behind a
forwarder that did not roll to a new KSK yet, that you would be negatively
affected too - even if you can get the information using CD=1 you still
most likely won't get anything from the upstream cache.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
