[getdns-api] some early API comments

[Paul Hoffman]

On Jan 21, 2013, at 1:53 PM, Evan Hunt <each at isc.org> wrote:

> While one rarely needs to specify the class of a query, it is sometimes
> useful (e.g., for version.bind/CHAOS/TXT), so there ought to be a
> request_class parameter for getdns().

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

> I see that others have already pointed out out the potential problems
> in passing QNAME as a C-style string. You might consider a a canonicalized
> getdns_qname type and a simple function for normalizing strings into that
> format; similar functions could convert in_addr and in6_addr to
> "in-addr.arpa" and "ip6.arpa" qnames.

That would mean that typical applications have to do a step before each call, which seems like a bad design for application developers, which is the target audience. I much prefer the "people who want odd names have to do funky-but-standardized encoding" that was suggested earlier.

> It would be nifty to be able to secure queries with TSIG or SIG(0),
> especially if there were any chance of this API being extended in the
> future to support DNS update, but useful even with just queries, especially
> if (as section 7.4 implies) the API will support AXFR/IXFR queries.

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?

> The design of the DNSSEC extensions appears to assume we'll be doing our
> own validation from the root (or from a designated trust anchor),

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?

Also, the getdns_context_set_dnssec_trust_anchors() call allows you to change the trust anchors.

> 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.

>  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.

--Paul Hoffman