>Are you trying to say that the behaviour of a validating stub resolver >is not in scope of the work on DNS(SEC)? >Because I was pretty sure it is. >See Thomas' post before on how separating validation from result >filtering (following the CNAME-chain) would be tricky to do outside of >the validating stub resolver (or only with significant overhead and re- >validation) for any implementation.
The function of a stub resolver is to send a DNS query to a recursive resolver and receive a reply. How the request is sent and how reply is validated is within the scope of the IETF. What happens later with the reply is not part of the stub resolver requirements. A DNSSEC validator is basically a function that can assign a status to a reply message: secure, insecure, indeterminate or bogus. Based on these, the a validating resolver can set the rcode to SERVFAIL, set or clear the AD bit. Filtering of DNSSEC secure replies is not tricky. It is just following CNAMEs until either a suitable RRset is found (or collection of RRsets) or nothing. In any case, if you don't like the protocol between the stub resolver and recursive resolver, the come with a concrete proposal to fix it. The IETF does not create standards for APIs. So a validating stub resolver is not really something that can be defined, because it is not a protocol. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
