[getdns-api] Upstream servers

[Robert Groenenberg]

Hi Sara,

Thanks for the explanation.
Just my luck: I did try two queries, should have done another one ;-)
Indeed, the third query uses the next server, great!

I understand the problem; configuring a timeout per upstream server
seems most logical. If I think of something else I'll let you know.

Cheers,
Robert

On 26-01-16 17:16, Sara Dickinson wrote:
>
>> On 26 Jan 2016, at 15:42, Robert Groenenberg
>> <robert.groenenberg at broadforward.com
>> <mailto:robert.groenenberg at broadforward.com>> wrote:
>>
>> Hi,
>>
>> I am looking into using getdns for doing ENUM queries from an
>> application. Based on the examples I've build a small test
>> application which works Ok as a stub resolver doing a query to a
>> configured upstream server.
>>
>> According to the API doc (http://getdnsapi.org/spec.html#8.7) a
>> /list/ of upstream servers can be configured. I would expect that
>> when the first server does not respond, the next one is queried.
>> However, I found that whatever the number of upstream servers
>> configured only the first is ever used (verified with
>> tcpdump/wireshark), no matter what the response (or lack thereof)
>> from that first server is.
>
> Hi Robert, 
>
> The timeout associated with the context is the total timeout to get an
> answer for the query. In the current implementation when using UDP,
> the same value is used to wait for a response from a particular
> upstream, so the first query on a context will use the first upstream
> and timeout the API call if no response is received within that time. 
>
> For a particular context getdns does use the upstreams in order,
> however if 2 timeouts are received from a particular upstream then a
> 'back-off' is put in place and the next upstream is used until the
> 'back-off' has expired and then the failed upstream is tried again. So
> if you re-try timed out queries on the same context you should see
> this behaviour. 
>
> (Note: TCP/TLS is a little different because if a problem is detected
> when trying to perform the handshake then the next server is tried
> immediately as long as the overall timeout hasn’t expired).
>
> We have had discussions about how to improve this, for example,
> letting the user specify the individual timeout for an upstream to
> respond and the total time they are willing to wait, but just haven’t
> got around to making the change. If you (or others) have ideas for the
> API change/algorithm to support this, please let us know.
>
> Regards
>
> Sara. 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.getdnsapi.net/pipermail/spec/attachments/20160126/0ebc45ae/attachment.htm>