[getdns-api] Changing the getdns transport options

[Goyal, Neel]

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.

From: Sara Dickinson <sara at sinodun.com<mailto:sara at sinodun.com>>
Date: Wednesday, June 10, 2015 at 11:28 AM
To: "getdns-api at vpnc.org<mailto:getdns-api at vpnc.org>" <getdns-api at vpnc.org<mailto:getdns-api at vpnc.org>>
Subject: Re: [getdns-api] Changing the getdns transport options

Hi All,

Following the earlier discussion of transport options I would like further comments on replacing the relevant part of section 8.3 of the API spec with the following:

getdns_return_t
getdns_context_set_dns_transport(
getdns_context *context,
getdns_list *transport_list
);

Specifies what transport is used for DNS lookups. The transport_list is an ordered list, values are GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP, GETDNS_TRANSPORT_STARTTLS , GETDNS_TRANSPORT_TLS.


[I presume the BOLD type face on the web page denotes the default, in which case it would be GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP]

And adding in section 8.7:

It might also contain tls_port to specify which port to use to contact these DNS servers when using TLS; the default is recommended as 1021 in lieu of an assignment from IANA.


API Notes
--------
1) For all TCP based connections:

 — It is suggested from the default idle time should be 0. This is because several widely used server implementations (including BIND and Unbound) have a default configuration which cannot handle many long-lived TCP connections well.

 — The DNSOP WG is in the process of discussing protocol options to establish behaviour for long lived DNS-over-TCP connections. The question is how best to handle this in the API in the short term. It is likely that two useful configuration options for long-lived connections will be the 'idle_time' and the 'max_transactions_per_connection'. It is more convenient for users if they are context settings (as the query ‘timeout' and ‘limit_outstanding_queries’ are today), however we should consider if such values are more suited to being per-upstream or per-transport settings.

2) For STARTTLS/TLS connections I think we should also consider adding a per-upstream setting for “TLS Authentication data” and a context setting for “TLS versions/ciphers” in the future (current support is for TLS 1.2 only).

Implementation Note
---------------------------
In the 0.2 release, if multiple upstreams and multiple transport values are both specified then the transport list take precedence over the upstream list when initially sending queries. [This is in order to maximise the chance of using an encrypted transport when fallback to an unencrypted transport is allowed]. However on reply truncation (TC=1) the message is re-tried over TCP to the same upstream if TCP is in the transport list.

Regards

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