Re: [knot-resolver-users] The "better" algorithm for choosing nameservers explained?

It's the strangest that google (and I also tried Quad9) is so often selected, because the local resolvers are much much closer (ping latency under 0.5 ms) than the google one (~10 ms) and their reply is also MUCH faster, because they are the ones that HOLD the actual zone, they dont have to lookup anything, they just reply.

when they were available, they were the fastest (and thus selected) and when they were unavailable, the public resolver was used.

Thanks for the TL;DR Štepán, appreciate it. It's the strangest that google (and I also tried Quad9) is so often selected, because the local resolvers are much much closer (ping latency under 0.5 ms) than the google one (~10 ms) and their reply is also MUCH faster, because they are the ones that HOLD the actual zone, they dont have to lookup anything, they just reply. They are bind servers that I also manage, they ofcourse support EDNS. I never thought that order of the servers taken into account. I think I read somewhere,long time ago, they are selected based on ping OR speed of the reply. Which in my experience always worked great - when they were available, they were the fastest (and thus selected) and when they were unavailable, the public resolver was used. I will try dig into it more closer, and try to figure out, what could have changed and why the new algorithm thinks, that reply from public resolver is superior to internal authoritative server with the actual zone. In case it matters, yes, it's properly DNSSEC signed. Josef On Wed, Mar 10, 2021 at 6:35 PM Štěpán Balážik &lt;stepan.balazik(a)nic.cz <mailto:stepan.balazik@nic.cz>> wrote: Hi Josef, /new choice algorithm TL;DR:/ In 95% of cases choose the server that seems the fastest, at 5% choose server at random. Keep a rolling estimate of the round-trip times and their variation for each address. Overall, it's better-defined, takes choice fairly into consideration and is easier to debug. /to your problem:/ Nowhere in the docs (now or before 5.3.0) does it say that Knot Resolver should somehow prefer the stub targets closer to the start of the list. This was an undocumented implementation detail that changed with 5.3.0. In 5.3.0 there is no inherent preference toward any of the targets and the choice is made using a rolling estimate of RTT of each target. I suppose 8.8.8.8 is faster in its answers than your local resolver so it's chosen far more often – looking at the TL;DR above this distribution of packets is pretty much expected. For now I would suggest not putting addresses you don't want to be queried on the policy.STUB list. For the future versions, we will consider adding an option (like NO_CACHE) which would query the targets in the order of appearance on the policy.STUB list – I opened an issue in our repo for that [2]. Please note that we also added some requirements for servers Knot Resolver forwards to; namely they now have to support EDNS and 0x20 name case randomization (documented here [1]). Best wishes Štěpán @ CZ.NIC [1] https://knot-resolver.readthedocs.io/en/stable/modules-policy.html?forwardi… <https://knot-resolver.readthedocs.io/en/stable/modules-policy.html?forwarding#forwarding> [2] https://gitlab.nic.cz/knot/knot-resolver/-/issues/669 <https://gitlab.nic.cz/knot/knot-resolver/-/issues/669> On 10. 03. 21 17:10, Josef Vybíhal wrote: -- https://lists.nic.cz/mailman/listinfo/knot-resolver-users <https://lists.nic.cz/mailman/listinfo/knot-resolver-users>