[getdns-api] comments on v0.245

[Phil Pennock]

Hi Paul, it's good to see this document, I think the new API you propose
is generally good and overdue.

I see Evan's comments in the archive and I too am interested in how this
interoperates with a validating resolver.

On the names, RFC 4343 section 2.1 covers the display form and escaping;
if this display form is not the form handled by default, then it would
be a useful extension option to make it available.

Onto my own discussion points (the reason for subscribing):

I'm assuming that most users of the API will not already be DNS experts,
but are trying to do The Right Thing and it should be easy to support
this.  I wonder if in addition to "dnssec_return_only_secure" the
easy/suggested approach for most apps should be "dnssec_strip_bad" ?
If there is a root zone trust anchor, then this would strip bogus and
indeterminate; if there is not a root zone trust anchor, then it just
strips bogus.

This would let developers do "the right thing for most apps" without
having to put in their own skipping of entries and getting it wrong as
they add a trust anchor.

3.3 / OPT records: is `payload_size` meant to be the sender system's
payload size, as exported in the CLASS field?  Because a natural reading
of the API doc as it is suggests that this is the payload size of the
packet being sent.  This probably just needs minor rewording for
clarification.

This leads onto a question: should the API honour a system configuration
file, in the style of resolv.conf, which can set options?  I can't help
but think that most applications should *not* be manually setting the
`payload_size` field, but that the default should be large enough to
handle transactions seen in the wild today with DNSSEC and 512 doesn't
cut it.  Any value chosen will be wrong somewhere, so this seems like
the sort of thing that would have a system default.  My additional 2c is
that a default of 1216 is 64 less than the 1280 minimum MTU demanded by
IPv6, far less than various tunnels impose in practice, and probably
large enough that turning on DNSSEC won't break "normal" queries, so
1216 would be a reasonable choice of default.

Further, `getdns_context_create()` honours resolv.conf: what happens in
the presence of `options` directives in that for this API?  My BSD
system supports my having "options edns0" as a line in that file, and I
do so.  tcpdump shows that this gives UDPsize=65535 on the wire.

3.4 : the `resolver_type` names are confusing until you think about them
a bit, since they're combining contrasting elements.
  GETDNS_CONTEXT_RECURSIVE_STUB
  GETDNS_CONTEXT_NONRECURSIVE_LOOKUP
My first reaction was "what if I've forwarding to a recursive resolver
and am just a stub, is that not supported?" until I realised that's what
the first one is.  This API is _always_ going to resolve.  So those
names are GETDNS_CONTEXT_<packet-type-set>_<extra>.  Would it be less
confusing to have GETDNS_CONTEXT_STUB and GETDNS_CONTEXT_RECURSING ?


Given the API design considerations of use by application developers,
shouldn't handling of IDN be done by default instead of an additional
manual step?

Also, would it be useful to add a useful SRV wrapper where you can say
"look up this SRV prefix for the name and return the results as a list
of IP addresses, with families, to connect to, having resolved all names
and used the priorities and weights of the SRV specification" ?  Years
ago, I wrote a small C library to handle this, and gave it another layer
which could then work through and try to connect, and if it succeeded in
connecting, invoke an optional callback function to test the interface,
then return the open socket for the first connection which succeeded and
passed the optional taster callback.  I didn't polish it to publish (I
think it's probably still broken on tip from a half-done feature creep
addition).  The first part of this is the sort of thing which, as an app
developer, is useful because it takes things like the SRV specification
and a name and turns it into "list of usable things".  The socket
connection layer is probably overkill for your API.

-Phil