systemd-resolved is timing out or takes forever to respond #24993
Comments
|
note that resolved does not lsten on the DOT port for the stub, you cannot use DOT locally to speak to resolved (also, why would you, it's local anyway). please turn on debug logging in resolved ("resolvectl log-level debug"), then reproduce the issue, and provide the logs this generates. It should tell you exactly what is going on. Most likely your just have DNS servers configured that are not reachable/don't implement the selected DNS features. |
|
Today I ran updates again and restarted device and it seems to now work if the domain is existing if not then it does the same thing as yesterday, timing out, attaching log on querying non-existing domain. (Edit: After using it for longer period of time, it still happens on existing domains too but very rarely but I can't reproduce it properly, it's kinda random, i will try to get log of it too but it's kinda funky) For the non-existing domains log, here: systemd-resolved log
So, when i caught it on existing domain I had other things running, personal things and it's in the log but basically everything went okay and then boom, this Basically, it tries to fire transaction for the domain then the SSL_shutdown appears and says "Switching server", it basically changes to alternative IP for the DNS and that resolves but it's very slow in that case and sometimes it doesn't and timeouts. For the last sentence: Nah, dog/dig tool worked perfectly with the same DNS providers also why would it be only 9 times out of 10 with resolved and i tried to disable all the extra features when testing it previously and tried 5 different DNS providers. Another edit: today it's again horrible, almost no queries finish sucesfully, even when DNSOverTLS is disabled the SSL_shutdown still there |
|
I updated and rebooted today, and it doesn't happen anymore, the SSL_shutdown doesn't show anymore and works as expected, no timeouts or such, it's fast it was, but I do still get some errors in the debug log of systemd-resolved. As such: Which seems really weird too as my understanding of it goes. |
|
After yesterday's update of glibc and so on it's happening again |
|
#25585 seems related I feel like it happens after every Glibc and OpenSSL update, does SystemD needs to be recompiled each time even though the ABI of the libs it depends on didn't change? I am really confused by this can anyone look at this? it completely criples the functionality of resolved |
|
EDIT: this proved to be caused by the local dns stub resolver getting overloaded Seeing similar issues here. For example, I can do: Debug log attached: Edit: In my case, it may be caused by mDNS (#14735) |
|
If it's useful for anyone else in my case the timeouts were because a machine with a public ip had set |
|
I honestly don't understand why we even need "revolved", it's slower and buggier than dnsmasq on a potato router with 128MB of RAM, what ever happened to KISS? what value does it add when it can't get a DNS record in under 200ms from a router 0.4ms away? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
251.5
Used distribution
Arch Linux as of 13.10.2022
Linux kernel version used
6.0.1-arch1-1
CPU architectures issue was seen on
x86_64
Component
resolvectl, systemd-resolved
Expected behaviour you didn't see
The DNS query to get resolved under second without timing out 99% of the time.
Unexpected behaviour you saw
The DNS query timeouts 9 out of 10 times and the 1 time it gets resolved takes like 20 seconds or more, resolvectl query timeouts after 2 minutes exactly. Tried with other tools like dig/dog to query DNS, and it works perfectly with the same DNS providers and even settings, like DNSOverTLS. If I specify DNS 127.0.0.53 for the dig/dog tool, it just never finishes.
Steps to reproduce the problem
I tried like 5 different DNS providers, all settings default, DNSSEC on off DNSOverTLS off on Cache off on all combination of all the settings literally and nothing helps. Always same behavior. I would try to downgrade SystemD but that would be just headache for me, i can't try that. Maybe it is some dependency problem? I have no idea
Additional program output to the terminal or log subsystem illustrating the issue
No response
The text was updated successfully, but these errors were encountered: