On Mo, 16.11.20 21:48, Petr Menšík (pemensik@xxxxxxxxxx) wrote: > But it does not have to learn everything about a server, because it > switched the active one. If it has to, try to find way to store server > instance features per server IP, not per link. We do exactly this. But we also have a grace period after which we forget everything again, and go back to the best server feature level again, which then takes some time to settle back on the actual server feature level. When we always use the same server, then we probe it once, and use it for the full grace period without any further delays. When we use numerous servers, and a different one for each lookup, then this means we have to probe each and every single one of them once and that slows down things. It's a very easy calulation: if you use n=1 servers for 500 lookups within the grace period, you experience 1 slow lookup in the worst case that required the feature probing, plus 499 speedy lookups because we already knew the earlier probing results. If otoh you use n=250 servers for 500 lookups you experience 250 worst case slow lookups, since we need to learn for each server individually what it can and can't do, plus 250 speedy lookups. And then, after the grace period is over, you get another 250 slow lookups... > > It might be something to add as opt-in, and come with the warning that > > you better list DNS servers that aren't crap if you want to use that, > > so that we never have to downgrade protocol level, and thus the > > learning phase is short. > > Sure enough, many router DNS implementations are bad or ugly. If it can > choose from full featured validated ISP resolver and crappy router > implementation, prefer the one with better features. Most likely it is > much better maintained as well. I am sorry, but that is not a suitable approach for an "edge" DNS clients. We need to go through the DNS server info we acquired through DHCP or so, since private domains do exist. We must keep router admin pages accessible. Hence, the "server spread" thing where queries are spread over a ton of DNS servers only really works if configured for the manual opt-in case. It's not something we could ever deploy by default. By default we need something that works, doesn't break private domains, and isn't slow. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
