> > > 3rd proposal > ============ > We have one more thing which needs more manpower to be verified. Right > now, the section 3.1. Preconditions is: > >> 3.1. Preconditions >> >> All of the following conditions must be met to trigger special >> processing inside resolver code: >> >> o The DNS response is DNSSEC validated and 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 QNAME is either "kskroll-sentinel-is-ta- >> <key-tag>" or "kskroll-sentinel-not-ta-<key-tag>" >> >> If any one of the preconditions is not met, the resolver MUST NOT >> alter the DNS response based on the mechanism in this document. > > and later 5. Sentinel Test Result Considerations discusses how to > interpret results, including considerations for CD bit handling between > recursor and forwarder (we are not speaking about stubs here!). > > The current text in section 5 is written with an assumption that query > with +CD bit cannot result in "Secure" status and thus cannot trigger > sentinel processing, but this depends on implementation. > > E.g. Knot Resolver stores RRs in cache along with their validation > status, so if a client(s) send query *without* CD bit, the RRs will be > validated and then stored into cache along with its state, e.g. Secure. > Later, when another client asks the same query but with +CD bit, the RR > will be read from cache and its state will be Secure despite of the CD bit. > > > Now, if we were literally following the version 06 of this draft, we > would trigger the sentinel processing despite the CD bit because the > state is Secure (as cached from a previous query). I suspect that this > is not what authors of text in section 5 expect ... > > To counter this I propose to add another precondition: > - CD bit in the query is not set > > IMHO it should solve the problem with implementation-specific cache > behavior. > > Does anyone see a problem with this addition? What did I miss?
I think this is correct Petr - i.e.I agree that it would be clear to add a further precondition that the CD bit in the query is _not_ set. I was VERY surprised to see the opposite text sneak its way into a pull request, and equally surprised that a co-author of the draft approved the request and pushed the -09 version without raising this on the mailing list, particularly as it directly contradicts your message here. The current text in -09 reads: The DNS response is DNSSEC validated, regardless of whether DNSSSEC validation was requested, and result of validation is “Secure" I believe this text in the current draft is incorrect and leads to the wrong behaviour. The idea is for the resolver to act in a manner that is consistent with the way it would behave in a hypothetical key roll scenario - and if the query has the CD bit set the resolver would return the response without this special process. Geoff _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
