Hi Mark, > On Jul 29, 2015, at 9:45 PM, Mark Andrews <ma...@isc.org> wrote: > > 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.
I'm not sure I follow what you're saying. It doesn't show when one of the clients has installed the new TA, it shows the TAs that "all" of them have. > > 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. That is true for any particular query, yes. But in all likelihood the recursive server will send queries on its own, or forward queries from stubs without a TA. If the stub has the new key but the recursive doesn't, we would be able to detect that. By analyzing all the queries from an address we would be able to see that some have the new TA and some don't. The reverse situation would not be detectable as currently proposed. > > 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. Yes, that might work. > > 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. I wasn't proposing that recursives should keep state on key tags that they've seen but if people think its reasonable then I am open to it. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
