<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 26 Jan 2016, at 15:42, Robert Groenenberg <<a href="mailto:robert.groenenberg@broadforward.com" class="">robert.groenenberg@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 bgcolor="#FFFFFF" text="#000000" class="">
Hi,<br class="">
<br class="">
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.<br class="">
<br class="">
According to the API doc (<a class="moz-txt-link-freetext" href="http://getdnsapi.org/spec.html#8.7">http://getdnsapi.org/spec.html#8.7</a>) a <i class="">list</i>
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.<br class=""></div></div></blockquote><br class=""></div><div>Hi Robert, </div><div><br class=""></div><div>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. </div><div><br class=""></div><div>For a particular context g<span style="color: rgb(51, 51, 51); widows: 1; background-color: rgb(255, 255, 255);" class="">etdns 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. </span></div><div><span style="color: rgb(51, 51, 51); widows: 1; background-color: rgb(255, 255, 255);" class=""><br class=""></span></div><div style="widows: auto;"><span style="color: rgb(51, 51, 51); widows: 1; background-color: rgb(255, 255, 255);" class="">(Note: TCP/TLS is a little different </span><font color="#333333" class="">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).</font></div><div><span style="color: rgb(51, 51, 51); widows: 1; background-color: rgb(255, 255, 255);" class=""><br class=""></span></div><div><span style="widows: 1; background-color: rgb(255, 255, 255);" class=""><font color="#333333" class="">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.</font></span></div><div><span style="widows: 1; background-color: rgb(255, 255, 255);" class=""><font color="#333333" class=""><br class=""></font></span></div><div><span style="widows: 1; background-color: rgb(255, 255, 255);" class=""><font color="#333333" class="">Regards</font></span></div><div><span style="widows: 1; background-color: rgb(255, 255, 255);" class=""><font color="#333333" class=""><br class=""></font></span></div><div><span style="widows: 1; background-color: rgb(255, 255, 255);" class=""><font color="#333333" class="">Sara. </font></span></div><br class=""></body></html>