[getdns-api] Upstream servers

[Sara Dickinson]

> On 26 Jan 2016, at 15:42, Robert Groenenberg <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 <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/3291981a/attachment.htm>