[getdns-api] Changing the getdns transport options

[sara]

> On 12 Jun 2015, at 13:22, Shane Kerr <shane at time-travellers.org> wrote:
> 
> Neel & all,
> 
> On Thu, 11 Jun 2015 23:23:22 +0000
> "Goyal, Neel" <ngoyal at verisign.com> wrote:
> 
>> What about making it a new method to not break existing APIs /
>> bindings - set_dns_transports (note the plural) or
>> set_dns_transport_order?  Internally the old method can just call
>> this w/ a single element list, and the getter can return the head of
>> the list.
> 
> For the "set" operation, I like the idea of a new function, for the
> compatibility reason you describe.

Thanks both for the feedback. 

Firstly the official API spec doesn’t include TLS or STARTTLS, but we did add these to getdns v0.2 (see below), so at the very least we would need to carefully consider what new types to add to the old method to support this. But it could be just the simplest version of each option with no fallback. For users only interested in UDP they could then stick with the existing methods, but anyone wanting to anything with privacy would sensibly choose the new API, because it offers the ability to specify fallback options. 

Also note that I am arguing that the underlying TCP connection handling should should change too. At the moment the TCP related options are …TCP_ONLY  or …XX_KEEP_CONNECTIONS_OPEN. The API doesn’t currently go into detail about the precise difference. 

In the current getdns implementation the TCP_ONLY version does a single message on a TCP connection (very wasteful and only really useful for TC=1 fallback) and in contrast the KEEP_CONNECTIONS_OPEN option has no timeout associated with it all - it keeps the connections open until the context is destroyed. The latter is IMHO unwise because DNS servers are today poorly equipped to handle may long-lived connections. 

I would like to see the TCP based connection handling driven by an idle timeout instead (until there is a signalling mechanism for exactly how to behave on persistent TCP connections). Of course we can map the existing types to something roughly equivalent and explain all this, but the new 'list + timeout’ concept will be much more aligned with the implementation. So I think users should be at least nudged, maybe pushed or even forced to use them….

> 
> However, the "get" operation is a bit trickier. You probably do not
> want a backward-compatible version to return the head of list if the
> list has more than a single entry.

Minor detail, but the more recent options added in getdns 0.2 but not documented in the API have 2 transports:
GETDNS_TRANSPORT_TLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN
GETDNS_TRANSPORT_STARTTLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN

> 
> I still like the idea of having a backward-compatible version of "get",
> but I think it should return an error if the list is not 1-entry long.
> ETOOMANYDIMENSIONSTARDISEXTERMINATEEXTERMINATEEXTERMINATE or the like.
> 
> Also, having set_dns_transport() and set_dns_transports() with only the
> 's' at the end to tell them apart is the path to madness (by which I
> mean 4-hour debugging sessions in the middle of the night). If this
> approach is used, surely using a more radically different name is a
> good idea, like set_dns_transport_order(), set_dns_transport_list(), or
> the like.

Yes to both these suggestions if we go down this route.

> 
> A final question with the backward-compatible approach is whether you
> want to recommend that developers switch to the new method or not. My
> own take on it would be that there is no strong need, and if you do
> make a recommendation then probably a process of deprecating the old
> one needs to be undertaken (ick).

As you can tell I am in favour of deprecating them :-)

Sara. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://getdnsapi.net/pipermail/spec/attachments/20150612/13303d95/attachment.html>
-------------- next part --------------
_______________________________________________
getdns-api mailing list
getdns-api at vpnc.org