[getdns-api] some early API comments

[Phil Pennock]

On 2013-01-21 at 17:35 -0800, Paul Hoffman wrote:
> On Jan 21, 2013, at 1:53 PM, Evan Hunt <each at isc.org> wrote:
> > which is
> > useful and necessary, but people with a trustworthy connection to a
> > validating name server ("trustworthy" here meaning running on localhost, or
> > with a first-hop connection secured by TSIG/SIG(0)) might want to rely
> > instead on their resolver to do the validation, but be interested in the
> > value of the AD bit set in the response.
> 
> Umm, what would an application care about "the AD bit"? They care
> about secure or not secure.

For my peace of mind: with a validating resolver and a trusted link to
it, the AD bit _is_ equivalent, right?  That's the signal from a
validating resolver.  I think your API already covers this with the
`dnssec_return_status` extension, but the phrasing of your question
leads me to question my understanding.  AD bit == secure or not secure,
given a validating resolver.

In a branch of Exim which I need to update to current HEAD, I check the
AD bit so that a transport can confirm that DNSSEC is actively in used
and has been verified.  If I ever get time to get back and finish that
work, then the next step is to implement Tony Finch's draft for using
DANE with TLSA records for MX delivery, so that we can turn on TLS
verification based on trust anchors in DNS.  Clearly, honouring TLSA
records is only sane if the DNSSEC status is known.

As an app maintainer, I strongly want a modern competent portable DNS
API which can handle DNSSEC and let me determine which results are or
are not signed, with a library which can provide more assurance than
"trust the administrator to have bothered setting up a secure link to
the validating resolver".  On this point, if the new API _can_ handle
TSIG to a resolver as part of the context setup, I'd happily expose key
selection to the app configuration file so that admins can choose to run
the validator on localhost or can set up keys to talk to a remote
validator, but I can be sure that if my API says the result is secure,
the admin probably has not screwed up in a way which I'll later be
blamed for with a security advisory.

-Phil