[getdns-api] comments on v0.245

[Paul Hoffman]

On Jan 21, 2013, at 5:16 PM, Phil Pennock <getdns-api-phil at spodhuis.org> wrote:

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

I am assuming that the API will have a root zone trust anchor, so those two would be equivalent, yes?

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

I tried to make it clear that typical applications didn't have to do anything with the context. Maybe I undershot, or maybe folks are getting too excited when they see the context options.

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

It is identical to the "payload size" field in EDNS definition in RFC 2671. I'm not sure how to make it clearer.

> This leads onto a question: should the API honour a system configuration
> file, in the style of resolv.conf, which can set options?  

Sure.

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

Where in typical OS configurations would one find a good value for payload size?

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

The API should honor all OS defaults first, certainly. It sounds like you want a context configuration that isn't there now, that allows the application to change the payload size. That's doable.

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

Probably so. If others like that, I can certainly change them. That's the marvel of C macros. :-)

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

What do you mean "by default"? IDNA requires applications to handle the A-label to U-label transition either themselves or in an API. I don't want to force an application to do it the way the API demands: I want to offer both. If you can see a clean way to do that, I'm all ears.

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

If SRV-using application developers want this (and there will certainly be some of them on the mailing list), I'm happy to add it.

--Paul Hoffman