[dns-operations] On server selection algorithms in dns resolvers

[Marek Vavruša]

On 23 November 2015 at 21:21, Mark Andrews <marka at isc.org> wrote:
>
> In message <93C2F218-FE0A-48A8-92FF-6114FA8E813A at dnss.ec>, Roy Arends writes:
>> When resolvers select a server to query, from a pool of many, does the
>> pool consist of just addresses, a combination of name-server name and
>> address or just name-server names?
>
> This is entirely implementation specific.

Yes, I think all the implementations are a bit different, maybe it
would be interesting to know what others do.

>> To illustrate, assume a delegation for .example with the following
>> records and glue in a fictional root zone.
>>
>> example. NS a.example.
>> example. NS b.example.
>>
>> a.example A 10.0.0.1
>> a.example A 10.0.0.2
>> b.example A 10.0.0.2
>>
>> When the strategy is to select from a pool of addresses or hostnames,
>> then there are two in each case, and if the distribution is equal, each
>> get 50% of queries.
>> When the strategy is to select from a pool of records, then there are
>> three (the three A records), and address 10.0.0.2 would get 66% and host
>> a.example" would get 66%, etc.
>
> Or it used srtt and it ends up 95% (50% + 45%) and 5%.  With zero knowledge
> named initially selects randomly by address.

I can speak for Knot resolver. It does basically what Geoff Huston
describes in "Happy DNS Eyeballs" [1].
So it compiles a preference list of resolvers with a limited size.
Since these are only 3, they would all fit in the list.
If the resolver knows nothing about them, they go in with equal chance.
If the resolver knows mean RTT, it is used for a dice roll with
p=1-(mean_rtt/max_rtt)
If the resolver knows that server is bad/not responding, there is a
p=5-10% that it gets in (cooldown).
IPv6 addresses are preferred by a 25ms bonus to RTT.

Then each query is given 3s to be solved with NSs from that list. The
resolver does "fast retransmit", meaning if the answer doesn't come
within expected RTT~300ms, the next less preferred NS is queried. If
the end of the list is reached and no answer comes, we start again.
When the timeout is reached, the score of the tried NSs is updated,
and new NS list is elected. If the list is empty, query resolution
stops.

Personally, I see a long list of NS records with a few addresses (see
currently broken 48.27.in-addr.arpa) each worse than a handful of NS
records, each with more addresses from a resolver's point of view.

[1]: https://indico.dns-oarc.net/event/24/session/11/contribution/11/material/slides/0.pdf

>> Thanks!
>>
>> Roy
>>
>> PS, Ive read a few papers on server selection algorithms, but none of
>> them specify server as name, address or combination.
>>
>>
>> _______________________________________________
>> 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
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> _______________________________________________
> 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