Hi Warren, all, On 15-01-18 02:51, Warren Kumari wrote: > The (new) rules: > A: If the qname starts with _is-ta, and the included keyid is *NOT* in > the trust store, the resolver changes the answer to a SERVFAIL > (otherwise things proceed normally). > B: If the qname starts with _not-ta and the included keyid *IS* in the > trust store, the resolver changes the answer to a SERVFAIL (otherwise > things proceed normally).
It is still not clear to me which trust anchor a validator should use for the sentinel processing. Is that (1) the root trust anchor with corresponding keyid, (2) the trust anchor with matching keyid for the domain that is queried, so the example.com trust anchor in your example, or (3) any trust anchor from the trust store with a matching keyid? 1. Does not require changes in the root zone and makes it possible for anyone to create a root KSK test. It also means that this test can not be used for any non-root trust anchor. 2. Requires changes in the root zone, but makes it possible to test the trust anchor for any zone. 3. Reduces the usefulness of the data. You know that a trust anchor for that keyid is configured, but you don't know for which zone. Given the limited number of keyids this does not sound like a good option. A trust anchor in the trust store with the keyid of the new root KSK does then not imply that validation will work after the keyroll. -- Ralph _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
