Petr, Have you taken a look at the getdns API specification that Paul Hoffman put together at http://www.vpnc.org/getdns-api/ ?
This addresses many of your points for both stub resolvers and a recursive resolver that would run on a platform local to the applications. -- Glen Wiley KK4SFV Sr. Engineer The Hive, Verisign, Inc. On 2/26/14 10:44 AM, "Petr Spacek" <[email protected]> wrote: >Greetings, > >I'm Petr Spacek from Red Hat's Identity Management group. We plan to >extend >support for DNSSEC (including DANE and others) in open-source software >and we >would like to discuss the right implementation approach with you. > >We can see two very basic approaches: >A) Do DNSSEC response validation in each application. >B) Let recursive resolver do the validation and use AD bit in the >application. > >We consider the first approach (i.e. each application doing response >validation) too heavy-weight and hard to administer for various reasons: >- Response validation is sensitive operation and application programmers >should not do it themselves. >- A variant where every application calls validation library is still not >optimal. Experience with crypto libraries shows that there are many >opportunities to use a library incorrectly (in a way which works but is >not >secure). >- This approach has potential to create administrative nightmare if each >application decides to maintain own set of trust anchors etc. We can see >results of such approach in PKI world ... > > >We believe that better approach is to centralize validation in local >system-wide recursive resolver and use AD bit for signaling that data are >trustworthy to applications. An application should use stub-resolver to >talk >to local recursive resolver and use received AD bit to decide e.g. if it >is >possible to trust TLSA records or not. > >Unfortunately, there are use cases where neither a locally running >validating >resolver nor a trusted path to a remote resolver are available and >deployment >of such is unacceptable. > >It seems that existing stub-resolvers unconditionally trust recursive >resolvers and just forward the AD bit back and forth. This behavior is >okay >only if no application relays on the AD bit. In other words, supporting >DANE >with current stub-resolvers practically requires to add a configuration >option >'recursive resolver is un/trusted' to each and every DANE-enabled >application >and library. (This is exactly what OpenSSH client does. An additional >problem >is that this value has to be maintained as network configuration changes >over >time.) > > >We would like to make DNSSEC implementation in applications as simple and >secure as possible. That is a reason why we are looking for a solution >for a >case where AD bit can't be trusted because validating resolver is not >available for whatever reason. It would allow applications to use AD bit >without explicit configuration per-application if we solve this case >somehow. > >Is there any 'standard' way to handle described situation? > > >We have the following proposal (some people say it is controversial): >- Extend stub-resolvers with a new call for resolver initialization: In >case >of ldns it would be something like: ldns_resolver_new_frm_file_trusted() >or >for glibc res_init_trusted(). >- The new call will initialize library as usual + read some system-wide >configuration (it can be whatever, imagine for example a new file >/etc/resolv.trusted). >- Client applications will use the same API (except the initialization) >to do >DNS queries. >- When a DNS answer is received from network the stub-resolver will >consult >configuration read from /etc/resolv.trusted: >-- If the particular recursive resolver is listed as trusted - pass AD >bit to >the application. >-- *Otherwise: Clear AD bit and pass the answer with AD=0 to the >application.* > >This allows an administrator to configure system-wide policy. In case >with >locally running validating resolver or e.g. IPSec tunnel to trusted >resolver >admin can declare it as trusted and nothing changes. However, this >mechanism >allows the system to be safe even in configurations *without* validating >resolver. No explicit configuration in application is need, just one >system-wide setting. > >It could seem like a minor improvement or a hack, but it allows >applications >to trust the AD bit unconditionally and as a result it significantly >simplifies DNSSEC implementation and configuration on client machines. We >hope >that this simple approach will allow us to implement and deploy DANE and >similar technologies widely. > >This proposal can be seen as temporary solution before secure transport >mechanisms like IPSec or CGA-TSIG are widely available and used. The main >advantage is that it is easy to implement and it doesn't require any new >technology so we can use it in applications today. > >We would like to hear your opinions and recommendations for this area. > >Thank you for your time. > >-- >Petr Spacek >Software Engineer >Red Hat > >_______________________________________________ >DNSOP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
