[getdns-api] Addition of new dns transport option

[Sara Dickinson]

That is a nicer approach - I guess I was assuming we didn’t want to make that big a change now…  As a long term solution that seems like the right thing, and I can work towards a demo that just adds a couple of  new types to the existing code and make that change later. 

Also, it seems to me like the default for TCP/TLS/STARTTLS should be to keep the connections open (if the underlying implementation can support it). 

I guess it is also worth pointing out that the UDP_FIRST_AND_FALL_BACK_TO_TCP option is currently using the DNS protocol (via the TC=1 bit), where as the other fall backs would be managed purely by the implementation.

Sara. 

> On 12 Mar 2015, at 17:32, Wessels, Duane <dwessels at verisign.com> wrote:
> 
> This all seems unfortunately complex.  In hindsight it may have been better
> to define more simple transport types (UDP, TCP, TLSPORT, STARTTLS) and
> then set them in the context as an ordered list.  If the first one in the
> list doesn't work, fallback to the next one, and so on...
> 
> Too late to change now?
> 
> DW
> 
> On Mar 12, 2015, at 10:11 AM, Sara Dickinson <sara at sinodun.com> wrote:
> 
>> Hi All, 
>> 
>> As I mentioned yesterday in the meeting there would need to be some additional transport types as arguments to the getdns_context_set_dns_transport() method to support DNS-over-TLS. The current set are:
>> 
>> GETDNS_TRANSPORT_UDP_FIRST_AND_FALL_BACK_TO_TCP
>> GETDNS_TRANSPORT_UDP_ONLY 
>> GETDNS_TRANSPORT_TCP_ONLY
>> GETDNS_TRANSPORT_TCP_ONLY_KEEP_CONNECTIONS_OPEN
>> 
>> To provide flexibility to perform different scenarios (depending on the privacy requirements of the client) as described in http://tools.ietf.org/html/draft-hzhwm-dprive-start-tls-for-dns-01 we could consider adding the following:
>> 
>> GETDNS_TRANSPORT_TLS_ONLY_KEEP_CONNECTIONS_OPEN
>> GETDNS_TRANSPORT_TLS_FIRST_AND_FALL_BACK_TO_STARRTLS_KEEP_CONNECTIONS_OPEN
>> GETDNS_TRANSPORT_TLS_FIRST_AND_FALL_BACK_TO_STARRTLS_THEN_TCP_KEEP_CONNECTIONS_OPEN
>> GETDNS_TRANSPORT_STARTTLS_ONLY_KEEP_CONNECTIONS_OPEN
>> GETDNS_TRANSPORT_STARTTLS_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN
>> 
>> 
>> 1) Does anyone object to adding all 5 of these options? (Implementation note: there are 10 enums reserved in the getdns code for transport options)
>> 
>> 2) The names here are explicit, but verbose. Should we consider condensing them?
>> 
>> 3) Is there a mechanism to mark those containing STARTTLS as ‘experimental’ in the spec?
>> 
>> One other note, the API does support specifying a set of upstream resolvers for stub mode (including a port), but there is no mechanism currently to specify a port to use for pure TLS.  We could extend the API or, more pragmatically for now, always use port 1022 (based on Allison’s comments) on the assumption one will hopefully be assigned by IANA. Thoughts?
>> 
>> Regards
>> 
>> Sara.
>> 
>> 
>> 
>> -------------------------
>> Sara Dickinson
>> 
>> http://sinodun.com
>> 
>> Sinodun Internet Technologies Ltd.
>> Magdalen Centre
>> The Oxford Science Park
>> Oxford
>> OX4 4GA
>> U.K.
>> 
>> _______________________________________________
>> getdns-api mailing list
>> getdns-api at vpnc.org
> 

-------------------------
Sara Dickinson

http://sinodun.com <http://sinodun.com/>

Sinodun Internet Technologies Ltd.
Magdalen Centre
The Oxford Science Park
Oxford
OX4 4GA
U.K.

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