[getdns-api] Changing the getdns transport options

[Sara Dickinson]

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/20150610/391b2b9d/attachment.html>
-------------- next part --------------
_______________________________________________
getdns-api mailing list
getdns-api at vpnc.org