<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi All, <div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><div class="">GETDNS_TRANSPORT_UDP_FIRST_AND_FALL_BACK_TO_TCP</div><div class="">GETDNS_TRANSPORT_UDP_ONLY </div><div class="">GETDNS_TRANSPORT_TCP_ONLY</div><div class="">GETDNS_TRANSPORT_TCP_ONLY_KEEP_CONNECTIONS_OPEN</div></div><div class=""><br class=""></div><div class="">To provide flexibility to perform different scenarios (depending on the privacy requirements of the client) as described in <a href="http://tools.ietf.org/html/draft-hzhwm-dprive-start-tls-for-dns-01" class="">http://tools.ietf.org/html/draft-hzhwm-dprive-start-tls-for-dns-01</a> we could consider adding the following:</div><div class=""><br class=""></div><div class="">GETDNS_TRANSPORT_TLS_ONLY_KEEP_CONNECTIONS_OPEN</div><div class="">GETDNS_TRANSPORT_TLS_FIRST_AND_FALL_BACK_TO_STARRTLS_KEEP_CONNECTIONS_OPEN</div><div class=""><div class="">GETDNS_TRANSPORT_TLS_FIRST_AND_FALL_BACK_TO_STARRTLS_THEN_TCP_KEEP_CONNECTIONS_OPEN</div><div class=""><div class="">GETDNS_TRANSPORT_STARTTLS_ONLY_KEEP_CONNECTIONS_OPEN</div><div class=""><div class=""></div></div></div><div class="">GETDNS_TRANSPORT_STARTTLS_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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)</div><div class=""><br class=""></div><div class="">2) The names here are explicit, but verbose. Should we consider condensing them?</div><div class=""><br class=""></div><div class="">3) Is there a mechanism to mark those containing STARTTLS as ‘experimental’ in the spec?</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Sara.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">
<div class="">-------------------------<br class="">Sara Dickinson<br class=""><br class=""><a href="http://sinodun.com" class="">http://sinodun.com</a><br class=""><br class="">Sinodun Internet Technologies Ltd.<br class="">Magdalen Centre<br class="">The Oxford Science Park<br class="">Oxford<br class="">OX4 4GA<br class="">U.K.</div>
</div>
<br class=""></div></body></html>