[getdns-api] comments on v0.245

Phil Pennock getdns-api-phil at spodhuis.org
Mon Jan 21 21:45:30 MST 2013

On 2013-01-21 at 18:04 -0800, Paul Hoffman wrote:
> It is identical to the "payload size" field in EDNS definition in RFC
> 2671. I'm not sure how to make it clearer.

I think most application users would not be familiar with the RFCs, so
clarification would just be a matter of clarifying that this is a
statement to the receiver of the maximum payload that can be supported,
unlike _most_ protocols, where it describes the size of what follows
within a frame.

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

I don't know of a place on typical systems; the problem is you're
defaulting to 512 and on FreeBSD, "options edns0" in /etc/resolv.conf
causes clients to default to 2^16-1.

Short of a horrible "magic comments" hack approach to augment
resolv.conf, you're down to a new file in /etc, I think.

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

If you keep the ulabel/alabel conversion routines and a way to skip IDN
work inside the API, then an application can do something special if it
wants to, or take a convenient extra that's "probably right" for most
applications.  It might be an extension item of "idn_auto_utf8" to let
the app take UTF-8 display form strings; I've not looked at the IDN
specs for a few years and I've forgotten the details of canonicalisation
/ nameprep and don't know if something would need to be in the extension
name for that?

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

Sounds good, and thanks for being willing to entertain the idea of
something crazy from me.


More information about the getdns-api mailing list