mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #1132] ResolverConfig and ResolverOpts loaded by read_system_conf should be updated automatically when system's conf is changed #609
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#609
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 @zonyitoo on GitHub (Jun 10, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1132
Describe the bug
After recover from hibernate on OS X,
AsyncResolver::lookup_ipwill not return even if network is fine (all the other applications works fine).To Reproduce
Steps to reproduce the behavior:
Nearly 100% reproduciable.
Expected behavior
AsyncResolver::lookup_ipshould work after recover from hibernate like all the other applications.System:
Version:
Crate: resolver
Version: 0.19.5
@zonyitoo commented on GitHub (Jun 10, 2020):
Not sure if it is related to: https://github.com/bluejekyll/trust-dns/issues/1073
@bluejekyll commented on GitHub (Jun 10, 2020):
This is potentially much better context and yes possibly related.
Any chance you could attach a debugger and grab a stack dump of the the threads? Might see the spot where we’re stuck.
@zonyitoo commented on GitHub (Jun 10, 2020):
I can sure that if the address is already in cache, everything works correctly.
I will try to gdb it tomorrow, when the problem shows up again.
@zonyitoo commented on GitHub (Jun 11, 2020):
Some related logs. Still don't know where it actually being blocked. I will try to reproduce it next day (I forgot to save the stack dump).
@zonyitoo commented on GitHub (Jun 11, 2020):
Lots of
name_server connection failure: request timed out.@zonyitoo commented on GitHub (Jun 11, 2020):
I see.. It is all about
trust_dns_resolver::system_conf::read_system_conf.read_system_confis called when server starts, but when I switch Wi-Fi, name servers are changed!! Buttrust_dns_resolverstill tried to use the old name servers.read_system_confmay need to reload if/etc/resolv.confchanged.@bluejekyll commented on GitHub (Jun 11, 2020):
Ah, so it's hanging on network configuration changes. I think we have an open story for how to support that. It would be interesting to come up with a good model for that. I've been hesitant to support it because of the dynamicity of it and recreating futures, etc, but maybe we should revisit that.
@zonyitoo commented on GitHub (Jun 11, 2020):
My solution is to add a script to watch
/etc/resolv.confand restart my servers when DNS configuration is changed.@zonyitoo commented on GitHub (Nov 17, 2020):
I found an issue https://github.com/c-ares/c-ares/issues/324 , it seems that we can call functions from
libresolvon BSD-like systems, specifically in this case, macOS.There are resolv, resolv-sys wrappers on crates.io.