<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=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 13 Jul 2017, at 14:01, Marcel van Garderen <<a href="mailto:marcel.van.garderen@broadforward.com" class="">marcel.van.garderen@broadforward.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Hi getdns users,</p><p class=""><br class="">
</p><p class="">My name is Marcel and this is my 1st post to the user's list…</p></div></div></blockquote><div>Hi Marcel, </div><div><br class=""></div><div>Firstly - apologies for such a slow response! Most of the team were at IETF and on holiday the following week so this seems to have been lost…. </div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">I have a question on the usage of the getdns API function
getdns_context_set_dns_transport_list().</p><p class="">With this function the user can provide an ordered list of
transport protocols that will be used for DNS lookups.</p><p class="">Fallback options are specified by including multiple values in
the list.</p></div></div></blockquote><div>That’s what the documentation says…but read on..</div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">I did some experiments with transport fallback using the
following dns context<font face="Courier New, Courier, monospace" class="">
(lib version 1.0.0b2).</font></p></div></div></blockquote><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Here, the transport list is 'first try UDP and if it fails try
TCP (the single IP address is masked)</p></div></div></blockquote><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class=""><font face="Courier New, Courier, monospace" size="-1" class="">{#012
"all_context":#012 {#012 "append_name":
GETDNS_APPEND_NAME_TO_SINGLE_LABEL_FIRST,#012
"dns_transport_list":#012 [#012
GETDNS_TRANSPORT_UDP,#012 GETDNS_TRANSPORT_TCP#012
],#012 "dnssec_allowed_skew": 0,#012 "edns_do_bit":
0,#012 "edns_extended_rcode": 0,#012
"edns_maximum_udp_payload_size": 512,#012 "edns_version":
0,#012 "follow_redirects": GETDNS_REDIRECTS_FOLLOW,#012
"idle_timeout": 5000000,#012 "limit_outstanding_queries":
0,#012 "namespaces":#012 [#012
GETDNS_NAMESPACE_LOCALNAMES,#012
GETDNS_NAMESPACE_DNS#012 ],#012 "suffix": [],#012
"timeout": 1000,#012 "tls_authentication":
GETDNS_AUTHENTICATION_NONE,#012
"upstream_recursive_servers":#012 [#012 {#012
"address_data": <bindata for XXX.XXX.XXX.XXX>,#012
"address_type": <bindata of "IPv4">#012 }#012
]#012 },#012 "implementation_string": <bindata of
<a class="moz-txt-link-rfc2396E" href="https://getdnsapi.net/">"https://getdnsapi.net"</a>>,#012 "resolution_type":
GETDNS_RESOLUTION_STUB,#012 "version_string": <bindata of
"1.0.0b2">#012}</font></p><p class="">The issue is that I was not seeing any transport fallback
attempts (using the same context). </p><div class="">When the DNS lookup failed (using UDP, timeout), there was no TCP attempt during any of the next 10 lookups. The library just kept on trying UDP.</div></div></div></blockquote><br class=""><div>There is a subtlety here which really needs explaining properly in the documentation, so thanks for picking up on this. The fallback options only kick in </div><div>- for UDP when a response is received but contains the TC bit</div><div>- for TCP/TLS when a connection to the upstream cannot be made and no messages can be written (e.g. handshake failures).</div><div><br class=""></div><div>I believe the failure case you are seeing with UDP is actually a timeout, i.e a query was sent but no response was received. Currently getdns does not re-try queries (or fallback) after a timeout on any transport, it simply returns. Reviewing this behaviour has long been on our TODO list. </div><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Changing the order (TCP with fallback to UDP) did not make any
difference: it just kept on trying TCP.</p></div></blockquote></div>A further subtly kicks in on TCP with TCP fastopen, which makes connection setup failures behave like timeouts in the sense that the ‘write’ of the query appears to always work but there is no response. And this produces the behaviour you see. So it might be you currently have TCP fast open enabled by default, but if you disable it with the —disable-tcp-fastopen configure flag then you will see fallback to UDP if TCP fails. </div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’ve added an issue to the issue tracker for this <a href="https://github.com/getdnsapi/getdns/issues/323" class="">https://github.com/getdnsapi/getdns/issues/323</a> for the team to review.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Sara. </div></body></html>