> That aim doesn't seem consistent with the statement that the > proxy won't be trusted with DNSSEC validation. That way you > still need a rather complex DNS code, ideally in a library. > And you'll need to query to stub for extra records to form the > whole chain, so that you even can validate. Overall I don't > advise splitting DNSSEC validation away from the other stub work > - cache in particular. Also because of the mechanisms that you > want to happen in case validation fails.
It seems to me that there are basically two cases: 1) The application does not depend on the security of the lookup. For example, a AAAA lookup that is used in a TLS connection. In this case, the proxy could do DNSSEC validation or leave it to the upstream resolver. 2) The DNS lookup is security sensitive, for example a DANE lookup. In my option, the application should do local DNSSEC validation and not trust either the proxy or the upstream resolver. If that requires the application to have a cache as well, then that is just part of the implementation of local DNSSEC validation. My experience with the getdns library, is that local DNSSEC validation can work quite well without a local cache. In my opinion the complexity of local DNSSEC validations comes from application requirements. This complexity will exist with or without a local proxy. If consensus among application/library developers is that DANE lookups can rely on DNSSEC validation done by a local proxy, then obviously, we can change the wording in the draft. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
