mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #2402] Conflict between ResolverOpts server selection options #977
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#977
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @andrewbaxter on GitHub (Sep 1, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2402
Sorry, I'm not sure this is really a feature, but it's not really a bug either (maybe?)
ResolverOptshas two parametersserver_ordering_strategyandshuffle_dns_servers. They don't mention each other, but it seems like they both operate on the same data, andshuffle_dns_serversoverwrites theserver_ordering_strategy. This could cause unexpected behavior (like if you setshuffle_dns_serversand forget about it, then later tweakserver_ordering_strategyto avoid some issue).@djc commented on GitHub (Sep 2, 2024):
server_ordering_strategywas added in #1766 (previously discussed in #1702) whileshuffle_name_serversoriginates from #1920. It does indeed look like there is substantial overlap, which we completely missed during review. To summarize:ServerOrderingStrategy::QueryStatisticsre-orders the servers by a metric designed by a decayed round trip time once per requestServerOrderingStrategy::UseProvidedOrderuses the specified order of the serversshuffle_dns_serverswill shuffle the list of servers for each run through the entire list of serversSo the interactions would be:
(QueryStatistics, true)doesn't really make sense, because now the statistics end up not being used due to shuffling(QueryStatistics, false)is the default and seems like a good default case(UseProvidedOrder, true)doesn't really make sense because shuffling makes it so that the provided order is not used(UseProvidedOrder, false)seems a like a decent alternativeSo we should probably drop
shuffle_dns_serversas a separate option and maybe tweak theServerOrderingStrategy. Maybe a good way out would be to provide an extra optionshuffle: boolforQueryStatisticswhich some shuffling behavior but would weight the shuffle via the statistics?@bluejekyll any opinions?
@samin-cf commented on GitHub (Dec 2, 2024):
Bump 🙂 @djc @bluejekyll
@djc commented on GitHub (Dec 2, 2024):
@marcus0x62 opinions?
@bluejekyll commented on GitHub (Mar 2, 2025):
Yes, we should clean this up. Definitely don't want confusing behavior, so we should make it clearer how these work with each other.