[dns-operations] Resolvers choosing low latency nameservers

bert hubert bert.hubert at netherlabs.nl
Fri Jun 21 14:47:36 UTC 2013

On Fri, Jun 21, 2013 at 02:26:05PM +0000, Jain, Vipin wrote:
> This work, published from Verisign, takes a look at the server selection algorithms of the various recursive resolvers:
> http://www.sigcomm.org/ccr/papers/2012/April/2185376.2185387

For PowerDNS:

SyncRes::doResolveAt first shuffles the nameservers both randomly and on
performance order. If it knows a nameserver was fast in the past, it will
get queried first. More about this later.


Whenever a packet is sent to a remote nameserver, the response time is
stored in the SyncRes::s_nsSpeeds map, using an exponentially weighted
moving average. This EWMA averages out different response times, and also
makes them decrease over time. This means that a nameserver that hasn't been
queried recently gradually becomes faster in the eyes of PowerDNS, giving it
a chance again.

A timeout is accounted as a 1s response time, which should take that server
out of the running for a while.

Furthermore, queries are throttled. This means that each query to a
nameserver that has failed is accounted in the s_throttle object. Before
performing a new query, the query and the nameserver are looked up via
shouldThrottle. If so, the query is assumed to have failed without even
being performed. This saves a lot of network traffic and makes PowerDNS
quick to respond to lame servers.

(There is no banding.)



> >From my understanding, unbound  pretty much locks on the auth server with the lowest TTL, and keeps on using it. Bind, however
> is quick to discover recoveries. I don't recall any study on re-probing on an exact time scale, however, it will be pretty interesting to look at.
> Vipin Jain

> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

More information about the dns-operations mailing list