[getdns-users] Question on transport fallback option of the getdns API

Sara Dickinson sara at sinodun.com
Fri Aug 4 12:25:02 UTC 2017

> On 13 Jul 2017, at 14:01, Marcel van Garderen <marcel.van.garderen at broadforward.com> wrote:
> Hi getdns users,
> My name is Marcel and this is my 1st post to the user's list…
Hi Marcel, 

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…. 

> I have a question on the usage of the getdns API function getdns_context_set_dns_transport_list().
> With this function the user can provide an ordered list of transport protocols that will be used for DNS lookups.
> Fallback options are specified by including multiple values in the list.
That’s what the documentation says…but read on..
> I did some experiments with transport fallback using the following dns context (lib version 1.0.0b2).
> Here, the transport list is 'first try UDP and if it fails try TCP (the single IP address is masked)
> {#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 "https://getdnsapi.net" <https://getdnsapi.net/>>,#012  "resolution_type": GETDNS_RESOLUTION_STUB,#012  "version_string": <bindata of "1.0.0b2">#012}
> The issue is that I was not seeing any transport fallback attempts (using the same context). 
> 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.

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 
- for UDP when a response is received but contains the TC bit
- for TCP/TLS when a connection to the upstream cannot be made and no messages can be written (e.g. handshake failures).

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. 
> Changing the order (TCP with fallback to UDP) did not make any difference: it just kept on trying TCP.
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. 

I’ve added an issue to the issue tracker for this https://github.com/getdnsapi/getdns/issues/323 <https://github.com/getdnsapi/getdns/issues/323> for the team to review.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.getdnsapi.net/pipermail/users/attachments/20170804/1b4dac8c/attachment.htm>

More information about the Users mailing list