mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #605] Is get_name_servers() on windows useful? #245
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#245
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 @kolbma on GitHub (Nov 6, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/605
Is get_name_servers() in this way really useful?
It returns all name servers for all adapters. Adapters which are also deactivated or not connected. So you get a long list of name servers which are not connectable, because the networks are not reachable.
Isn't there any possibility to get the list of name servers used by the windows system right now?!
@bluejekyll commented on GitHub (Nov 7, 2018):
What is your concern about the current usage, beyond the "long" list? Is there a significant cost associated with this that you're concerned about? The Resolver will promote working connections over non-working connections.
Also, I don't personally use Windows, the support was added by @liranringel a while back. I'm not sure if the underlying library can evaluated active/inactive connections, but this could be an optimization. It would be useful on other platforms as well.
@liranringel commented on GitHub (Nov 7, 2018):
I can expose that info.
I'll update you when it happened.
@bluejekyll commented on GitHub (Nov 7, 2018):
Thanks, @liranringel. I still don't know of any root issue here, other than an optimization that may not have a huge effect. Also, it might be a big change to incorporate interfaces into the IP/routes for the nameservers, so I don't know when that work would even occur.
@kolbma commented on GitHub (Nov 8, 2018):
@bluejekyll Benjamin, yeah, maybe not much improvement. The story behind is, that I'm using trust-dns without resolver-part to do different DNS work. For this I'd like to base on the DNS settings of the system. So resolver got a dependency just for reading the config. I don't know what is your solution for resolver to get a working DNS server! The default is to use the one from Google. I know. But Google is evil. ;-) DNS shouldn't become so centralised. If you prefer the system config? How does it work? Does each client try to connect this list of servers until a connect works? Here I've many virtual interfaces for VMs. All provide a DNS server address for internal usage. So it needs some time to get through the list with connect-timeout to find the one between which can be used by the host. Sure this can be cached afterwards, but this information should be available by the system and the ugly try-and-error part could be skipped. The ipconfig crate seems to be very rudimentary and doesn't provide this, too.
@bluejekyll commented on GitHub (Nov 8, 2018):
Please see the response from @liranringel for potential support in the underlying library. I definitely see the benefit here, but I’m not totally clear on your usecase. It sounds pretty specific to a specialized scenario.
As to some of your questions, there are 4 options for DNS recursive resolvers, google, cloudflare, quad9 and your system config. The pre configured ones are just an ease of use thing, not meant to encourage people to use them one way or another.
In terms of usage, yes, each nameserver listed in the config of the resolver will be tried. After an initial pass, they will be sorted on usage based on connection status and then after that successes vs. failures. So yes, if this list is excessively long with many failed or down paths, then there could be a large expense to picking a working nameserver IP.
Mind you, all interface routing is performed by the OS and it’s own route tables, trust-dns-resolver does nothing special for that, it just selects an IP, and then the OS is responsible for selecting an active route to that IP.
@seanmonstar commented on GitHub (Jan 11, 2019):
It seems this may be causing issues with reqwest on Windows, as reported here: https://github.com/seanmonstar/reqwest/issues/431
@liranringel commented on GitHub (Jan 11, 2019):
Adapter.oper_statuswas added toipconfig.I think you also need the routing table to know which dns server you should use.
@bluejekyll commented on GitHub (Jan 11, 2019):
As I meantioned above, trust-dns isn’t tracking anything related to routing tables today. I also don’t have access to a Windows system to reproduce this.
Can we filter during initialization of the system configuration based on active interfaces? Or is this something that could change at various times due to laptops joining and leaving networks?
For other reasons, like mDNS support, I have considered starting to track NameServers against network routes, but that work is as yet unplanned and undesigned.
@Arnavion commented on GitHub (Jan 11, 2019):
Specifically for the reqwest issue, I don't think filtering out inactive adapters will help since the adapter contributing the IPv6 DNS server IP is up.