[Dnssec-deployment] On DNSSEC support in Applications (was Re: Root Zone DNSSEC Deployment Technical Status Update)

[Suresh Krishnaswamy]

Trying to simultaneously respond to a couple of email messages:

Paul Vixie wrote:
 > because there are still no
 > external applications that add value in the face of this metadata

There's certainly more than one application that already has DNSSEC  
support integrated. Agreed that more needs to be done and that there's  
some user-interface challenges to overcome, but I just wanted to make  
sure that folks knew about some of the patches we've built for  
applications -- e.g. firefox/thunderbird (which adds validation  
support for _all_ queries issued by the mozilla lookup engine),  
openssh, sendmail and postfix. The goal, again, is to integrate  
validation into the application through a validator library so that  
the application can react differently to DNSSEC results if it so wishes.

Paul Vixie wrote:
 > i don't think ssh behaves differently in the face of dnssec metadata.

The openssh patch that we've built adds this capability -- see http://www.dnssec-tools.org/readme/README.ssh 
  (the README is a bit dated, but the patch in DNSSEC-Tools 1.7 should  
apply to more recent versions of openssh).

Shumon Huque wrote:
 > How does OpenSSH see the AD bit? Does it make it's own DNS queries,
 > or is it using some enchanced resolver routines (if so which ones)?

In our case, we're using the enhanced routines that the proposed  
DNSSEC validator API ( http://tools.ietf.org/html/draft-hayatnagarkar-dnsext-validator-api-07) 
  provides. We don't look for the AD bit, we're looking at the DNSSEC  
status values that are returned by the new functions.

Paul Vixie wrote:
 > so there's still a lot wrong with the DNSSEC model as it pertains  
to apps;
 > it's not just the library API but also the concept of stub  
validation.

APIs are an important part, no doubt. And I also see value in  
providing a way for the full authentication chain to be returned by  
the recursive name server (but not for caching and efficiency of  
validation, but rather from the point of view of enabling the  
application to be able to "wait" for the correct answer to be returned  
in the face of a spoofing attack). With respect to the API, we have a  
start in draft-hayatnagarkar-dnsext-validator-api, and I believe the  
timing is about right to resume discussions on this topic.

Thanks!
Suresh