I thought that if the query contained CD = 1 then the DNS response would not be validated, and precondition 1 would not be met.
But I’m probably wrong, so could you please suggest wording here? regards, Geoff > On 4 Apr 2018, at 10:21 am, Mark Andrews <ma...@isc.org> wrote: > > You are effectively saying that the resolver MUST ignore CD=1 for these > queries. > >> On 4 Apr 2018, at 7:36 am, Geoff Huston <g...@apnic.net> wrote: >> >> >> >>> On 4 Apr 2018, at 7:11 am, Paul Hoffman <paul.hoff...@vpnc.org> wrote: >>> >>> On 3 Apr 2018, at 13:45, Geoff Huston wrote: >>> >>>> Is the wording “that the resolver has to do DNSSEC validation on what it >>>> gets back from the authoritative server *regardless* of whether the >>>> originating client requests it?” a clarification that updates the >>>> validation behaviours as specified in RFC4035 and RFC6840 as to when a >>>> security aware resolver performs validation? Or merely a clarification of >>>> the precondition in the context of the sentinel behaviour but of no wider >>>> import? >>> >>> The latter. Otherwise, someone reading the document might not understand >>> that the response must be validated no matter what. >> >> >> So you are saying that the document should revert to the wording: >> >> All of the following conditions must be met to trigger special >> processing inside resolver code: >> >> o The DNS response is DNSSEC validated, regardless of whether >> DNSSSEC validation was requested. >> >> o The result of validation is “Secure". >> >> o The QTYPE is either A or AAAA (Query Type value 1 or 28). >> >> o The OPCODE is QUERY. >> >> o The leftmost label of the original QNAME (the name sent in the >> Question Section in the original query) is either "root-key- >> sentinel-is-ta-<key-tag>" or "root-key-sentinel-not-ta-<key-tag>”. >> >> >> (I’ve split the initial condition into two explicit preconditions to be >> consistent with the rest of the enumerated list) >> >> Any objections to this from the WG? I’ll wait for 24 hours and then post >> this wording as version 11 unless the WG says otherwise >> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
