[getdns-api] some early API comments

[Evan Hunt]

> This is pretty rare. Since it's not part of IN, I feel comfortable making
> this a context setting.

That works.

> Nifty, but essentially never done today. Also, this would clearly be
> something done on a context basis, not a query basis. Can you propose
> what would need to be set for those?

For TSIG, a keyname and secret, or the name of a file containing such.

For SIG(0)... hm, I'll get back to you, I'm rusty on this.

> That was not my intention, but I might be misunderstanding what you mean
> by "our" in that sentence. The intention is that the API will do
> validation, and allow the application to do validation if it wants to.
> That's what the three DNSSEC extensions are for. Did I miss something
> there?
[...]
> Umm, what would an application care about "the AD bit"? They care about
> secure or not secure.

They almost always care about bogus (in that they usually don't want to
receive it).  They sometimes, though not always, care about the differences
between secure and unsecured.  (Note: I use "unsecured" here because the
traditional term "insecure" tends to make people who aren't familiar with
DNSSEC jittery; it just means the answer isn't signed, not that anything's
wrong with it).

And, applications don't always want to do their own crypto.  If my resolver
is validating, and I trust it, and I trust that there's no MITM between me
and it, then I may prefer to let *it* handle the crypto and tell me what it
learned.

 - If I send a query to this resolver with DO=0 and AD=0, I get SERVFAIL
   for bogus data, which is good, but I can't tell the difference between
   secure or unsecured responses.
 - Sending the same query with DO=0 and AD=1, I again get SERVFAIL for
   bogus data, but I get AD=1 for secure, and AD=0 for unsecured.
 - Sending it with DO=1, I get the same stuff, plus also the RRSIGs and
   other DNSSEC data included in the response.

So what I'm asking for is a DNSSEC context in which I don't set
a trust anchor, and neither the API nor the application does crypto,
but there can still be insight into whether the answers were secure or
unsecured.  (We don't have to worry about bogus in this context, because
that would've SERVFAILed anyway) This is only applicable when the resolver
is known to be validating, and the connection to the resolver is
trustworthy.

> >  Or, they might want to set the
> > CD bit on queries to bypass validation.  Are there mechanisms for this?
> 
> Please restate from an application view, not a DNS protocol view. :-) I
> do want to make as many things available to application developers, even
> advanced ones, but I'm not trying to simply mimic the DNS protocol.

If you send a query to a validating resolver with CD=1, the resolver won't
bother to validate; you'll just get the data, whether it's bogus, secure,
or unsecured.

This may sound modestly useless, but when you need it you need it badly:
for example, when you're launching ntpd on an embedded box and the lookups
for the NTP server addresses are all SERVFAILing because your clock is
still set to January 1 1970 and the signature inception dates are years in
the future. (Yeah, I have a few scars.) In terms of this API, I suppose,
I'm asking for a "force no validation" extension.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.