DNS fails with "Using degraded feature set" in logs until resolved is restarted #13432
Comments
|
Likewise, on debian unstable using systemd 242. First requests works, until the grace period is over: At which point requests start to fail until resolved is restarted. |
|
Also reproduces on 243. |
|
This has more implications than I previously realized. On a connection which suffers from packet loss (gsm), resolved will downgrade the probed featureset and by returning to normal will also stop working. |
|
Can no longer connect to any openvpn server on ubuntu 19.10, and the logs are flooded with these messages. |
|
I also have this issue on my |
|
Maybe makeing use of either one of the below, in a drop-in of the units involved, would fix things:
|
|
~$ systemctl status systemd-resolved.service
06:36:59 ubuntu systemd-resolved[821]: Using system hostname 'ubuntu'.
06:36:59 ubuntu systemd[1]: Started Network Name Resolution.
06:37:12 ubuntu systemd-resolved[821]: Using degraded feature set (UDP) for DNS server 8.8.8.8.
06:37:23 ubuntu systemd-resolved[821]: Using degraded feature set (UDP) for DNS server 1.1.1.1.
06:44:56 ubuntu systemd-resolved[821]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 1.1.1.1.~$ cat /etc/systemd/resolved.conf
[Resolve]
DNS=8.8.8.8 1.1.1.1
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=yes
#DNSStubListener=yes |
|
I have this same issue after changing my mxlinux from sysvinit to systemd v241. `cat /etc/systemd/resolved.conf [Resolve] |
|
With this config: [Resolve]
# CZ.NIC https://www.nic.cz/odvr/
DNS=193.17.47.1#odvr.nic.cz 185.43.135.1#odvr.nic.cz 2001:148f:ffff::1#odvr.nic.cz 2001:148f:fffe::1#odvr.nic.cz
FallbackDNS=
Domains=local
DNSSEC=yes
DNSOverTLS=yes
MulticastDNS=no
LLMNR=no
Cache=yesTrying to resolve an invalid domain: Triggers the "Using degraded feature set" message in the logs: |
|
Same issue here using Systemd version 248.3-2-arch With this config: |
|
Same issue here on Fedora 34 running systemd-248.7-1 |
|
I'm having the same issue for years now, observed with Virtualbox on Windows 10, hosting either ubuntu 18.04 and I recently did a new VM install with ubuntu 20.04 (systemd 245 (245.4-4ubuntu3.11)) The journal contains lines like below, it lists an ipv6 address now, but before I also observed ipv4 addresses. I had the same already being attached to my openwrt router or my ISP (Telenet)'s gateway. I am using the Virtualbox NAT network adapter as a network device, and also a virtualbox network device bridged to my laptop's wired ethernet. There are a few DNS servers configured: |
|
I have similar symptoms, but I also discovered something else: The issue disappears for me when I switch to a VPN. Test caseI have to update PIP dependencies. Not exactly an unknown thing in the world of Linux, but for some reason it takes very long to the point that I abort. Then, when I enable the VPN and restart the PIP update, it goes very fast. Other processes, like Firefox or video games, don't seem to suffer from this problem. Base setupWith VPNLogsSystem |
|
Just started to run into this recently as well. Seams to start when I open up a specific game Elder Scrolls Online Though steam and Proton, Does not matter the version of proton. systemctl --version 0.48
systemd 248 (v248.7-1.fc34)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unifiedOct 05 14:10:51 tear systemd-resolved[14085]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server {DNS1}.
Oct 05 14:10:56 tear systemd-resolved[14085]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server {DNS2}.
Oct 05 14:11:12 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:11:12 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS2}.
Oct 05 14:11:15 tear systemd-resolved[14085]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server {DNS1}.
Oct 05 14:11:26 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:11:26 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:11:36 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:11:36 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:11:46 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:11:46 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:11:51 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:11:51 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:12:01 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:12:01 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:12:11 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:12:11 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:12:16 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:12:21 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:12:31 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:12:31 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:12:41 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:12:41 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:12:41 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:12:51 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:12:51 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:12:51 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:13:01 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:13:01 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:13:06 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:13:16 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:13:16 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:13:16 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:13:26 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:13:26 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:13:32 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:13:42 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:13:42 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:13:42 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:14:55 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:14:55 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:14:56 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:16:25 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:16:30 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:16:35 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:16:51 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:16:51 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:16:56 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:17:02 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:19:55 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:19:55 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:22:12 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:22:12 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:22:23 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:22:23 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:22:33 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:22:33 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:22:43 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:22:43 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:22:48 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:22:48 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:24:56 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:25:01 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:26:25 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:26:25 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:27:59 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:27:59 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:28:04 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:28:15 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:28:15 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:28:15 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:29:55 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:29:55 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:33:25 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:33:36 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:33:36 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:33:36 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:33:46 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:33:46 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:33:51 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:35:01 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:35:01 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:38:57 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:39:07 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:39:07 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:39:12 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:39:23 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:39:23 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:39:23 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:40:01 tear systemd-resolved[14085]: Using degraded feature set TCP instead of UDP for DNS server {DNS1}.
Oct 05 14:40:01 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}.
Oct 05 14:41:30 tear systemd-resolved[14085]: Using degraded feature set UDP instead of TCP for DNS server {DNS1}. |
|
Same issue, on multiple machines using Ubuntu 20.04. Restarting systemd-resolved fixes it, but even when setting caching to no, it still fails regurarly again. |
|
Recently encountered the same issue on Fedora 35. Use systemd-resolved, systemd-networkd and iwd. |
|
Here's what worked for me on ubuntu 20.04.4 LTS, and survived a reboot :) In firefox, while using vpn and not, I was getting a lot of pr_end_of_file_error errors, or pages -- esp. smile.amazon.com -- would not load completely, or my first click on a page would seem to go nowhere (???). Then I found the degraded messages in the logs: Previously I was trying to use google dns 8.8.8.8 and 8.8.4.4, and was getting the degraded log message only for the latter. I switched to cloudflare below. (Side note: I think my rotation of vpn providers helped mess things up, but enabling and disabling (current: surfshark) vpn now does not mess things up for me.)
the part changed: I wasn't sure if this one was generated from somewhere else, but it seems needed to fix the network interface device (see below): the part changed: I don't use ipv6 because vpn, but in case you want them: restart the things, and check the result: at this point, per the last command, my internet ethernet device was stuck on the old dns settings, so... should be OK now: should be OK now: just for fun: dnssec test page: |
|
addendum to previous for 22.04 LTS: |
|
Note when replacing systemd-resolve with resolvectl to forego the "--" dashes behind the commands. So instead of treating them as flags just do I had a very similar issue to this on 22.04, my truncated logs are below. Restarting systemd didn't help, only stopping the service completely and putting nameserver Prior to my issue I'd been using ProtonVPN and OpenVPN (not simultaneously). My laptop died while ProtonVPN was connected and when restarting it the issue came up - all I had to do was reconnect to ProtonVPN (See above how to initially connect to wifi) and then turning it off, enabling systemd-resolve again and all works fine. I'm not getting my below error messages anymore.
|
|
Still getting burned by this. None of the resolved hacks mentioned above work for me. |
|
@Rick1029 Did you have any luck fixing this issue? I also was using ProtonVPN and I believe something interrupted the connection. |
|
@Rick1029 Update: I was able to resolve this at least temporarily by manually downing the "ipv6leak" network interface created by ProtonVPN. |
|
Does anyone think this issue will ever be fixed? |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Same problem in elementaryOS 6.1 (i.e. Ubuntu 20.04) with systemd 245 journalctl logs: /etc/resolv.conf: Restarting systemd-resolved doesn't fix it for me. The only thing that's been working so far is manually editing /etc/resolv.conf and THEN restarting the service. |
|
I faced this trouble when install a new Ubuntu Jammy on vm, but after some operate, it now working good without those annoying logs. I tried some steps bellow:
content of file /etc/netplan/00-installer-config.yaml content of file /etc/systemd/resolved.conf |
|
|
I am not sure its a good solution, by it works for me:
|
|
@JamesLIAOHJ you can already change those settings per |
|
Hi, On my side, I moved from 192.168.0.X to 192.168.2.X on my router because none of the solutions above worked. When I tried to go with a browser to http://192.168.0.1, I got a 404 despite having the router web interface... Something seem to catch and redirect to a 404, but what? I dunno Now after the change, if go with a browser to http://192.168.2.1, I've got the router web interface. Don't know why suddenly it stopped to work on Ubuntu 22.10. If I go on another network and IP is 192.168.1.X, no issues (and never had issues). Any clues? |
|
In my case i think i what is causing the problem (but not yet why), Indeed when i disable tailscale service i do not get this log anymore. $ resolvectl status
...
Link 4 (tailscale0)
Current Scopes: DNS
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 100.100.100.100
DNS Servers: 100.100.100.100Any idea if this is fixable, and how? |
Means that your tailscale doesn't support or is not configured for At moment i don't even know what that protocol is, just rewording the message for you... edit: It might also mean your
|
I though [Resolve]
DNS= 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#FallbackDNS=
#Domains=
#DNSSEC=no
DNSOverTLS=opportunistic
#MulticastDNS=yes
#LLMNR=yes
#Cache=yes
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
|
It is for the global setting, but not for the per-link if so needed. (resolved.conf.html#DNSOverTLS=)
See the bolded lines for a hint.
|
|
If i understand correct what you implied, the bolded line means that the error i'm receiving happens only once, when the downgrade of the tailscale DNS is first contacted, correct? Could the above description explain by the timing of the logs i'm receiving? Dec 20 11:10:33 hostname systemd-resolved[596]: Using degraded feature set UDP+EDNS0 instead of TLS+EDNS0 f>
Dec 20 11:10:39 hostname systemd-resolved[596]: Using degraded feature set UDP+EDNS0 instead of TLS+EDNS0 f>
Dec 20 11:41:00 hostname systemd-resolved[596]: Using degraded feature set UDP+EDNS0 instead of TLS+EDNS0 f>
Dec 20 11:41:02 hostname systemd-resolved[596]: Using degraded feature set UDP+EDNS0 instead of TLS+EDNS0 f>
Dec 20 13:07:07 hostname systemd-resolved[596]: Using degraded feature set UDP+EDNS0 instead of TLS+EDNS0 f> |
|
Well i suppose queries do not use a "keep-alive" that long or at all, maybe thats why you get repeated log messages 🤷♀️ PS: your last output shows it's using the |
|
I do also have this problem again and again.
Sometimes, the "+EDNS0" also shows up (but I can not reproduce when which error message occurs). DNSSEC is set to no but this did not change anything. Is there anything else I could provide to help finding a solution? It is really annoying because I need VPN to work :( |
|
I still see this on a Fedora 36 host; IPs are from DHCP server (incl DNS). ...but when I point it to my router (which distributes a list with two local DNS resolvers), I get: restarting |
I suspected that in my case it had something to do with ProtonVPN, however the downing of the interface doesn't survive the reboot. cd /etc/NetworkManager/system-connections \
&& sudo rm -r pvpn-ipv6leak-protection.nmconnection \
&& sudo systemctl restart NetworkManager |
Same on |
Same on 253.5, as far as I can tell.
|
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Try setting |
Just an FYI - I have Ubuntu 22.04 and ran into this issue with a Tenda N300 WiFi router. I've been using my cellphone as a WiFi hotspot, and the Ubuntu machine worked great that way. But, switching to this router it failed with the messages shown here about downgrading and using UDP instead of TCP or whatnot. I've read a bunch of postings all asking about the same problem, and have tried many of the advice, all of which is mentioned on this issue thread. The above suggestion to switch from the NNN.NNN.0.NNN network to the NNN.NNN.2.NNN network, that worked. This router was configured by default for the .0. network, switching to .2. fixed the problems. The problem I observed is primarily about DNS resolution - in that DNS names wouldn't resolve, and in FYI |
With respect, when the only way to troubleshoot defective software is to activate developer mode (and flood the logs with messages), the bug is still with the software. What happened to the principles of "break loud" and "give useful error messages"? Notwithstanding an actual software patch with useful troubleshooting messages, I guess debug mode will have to suffice. My particular problem with resolved seemed to resolve magically, so I'm of no more use other than "keep running updates and hope." |
|
I'm on an Ubuntu 22.04.3 LTS Jammy ARM guest on Parallels/M1max and have recently started experiencing the same - ping shows randomised drop outs and checking iTerm on the host, ping/browser processes no problem, so its def the Ubuntu guest not the host and thus not the hardware. Would be good to work out what's causing it, as my network access is interrupted constantly. Reproduced on systemd 249. |
|
@robogeek I'm having exactly the same symptoms as you. I'll try to change to 0.2 and see if that works for me. Update: just did that it worked. |
|
Reading through this bug report, and reading through the code in dns_server_possible_feature_level in resolvd-dns-server.c, I have to say that I'm generally disturbed by the logic. Just looking at the logic, the obvious failure modes are:
That is, quite frankly, a nasty mixture of issues. I'm not sure how other resolvers such as unbound handle these cases, but someone should take a hard look at how this can be done better. At a guess, it's probably safe to assume that the server isn't going to change to become less capable on us. Sure, in theory it could, but that should be an extremely rare event. As such, remembering that we have successfully done X in the past should mean that we don't simply disable X when something doesn't work later on. As an example, if we have previously gotten successful responses for DNSSEC queries, then there's a pretty solid chance that disabling DNSSEC later for reasons aside from packet size isn't going to do us any good. Likewise, if we have been doing DNS over TCP successfully, and DNS over TCP starts timing out, disabling TCP is unlikely to help. On the other hand, if we start getting connection refused, then we shouldn't wait for multiple retries before disabling it. And if we want to potentially reset our degraded state after some time, perhaps we should do something like remember why we downgraded, and use that to choose a query that should trigger the same failure to cause us to send the query twice, once with the current feature set, and once with the full feature set, and only reenable the full feature set if we now get a proper response for the test query. I'm not saying that these would all be simple to implement, but this ticket has been open for over 4 years now. It might be worth trying some of them. |
|
I'm experiencing this issue on a Proxmox machine atm on a new Fedora installation and I genuinely don't understand how there is no solution to this problem yet. As extra information: |
Lol. It shouldn't make any difference, but it fixed the problem here as well. Dynamic DHCP The same with I have no idea what is exactly wrong, but it's worth trying if you have the same issue. @robogeek thank you, just ~2h wasted instead of many more. |
|
my 2 cents for slow DNS on Ubuntu 22.04.3 LTS, I simply needed to install resolvconf:
that suddenly solved my issue, some details here https://askubuntu.com/a/1012648 |
|
Can confirm that we saw this issue with Some notes:
Saw this in the journal: |
|
I don't see any debug log, or packet capture, or steps to reproduce in this thread. |
|
@rpigott See my comment (#13432 (comment)) that goes into the logic issues. To reproduce you need a network environment with a packet loss rate which is high enough to periodically drop DNS packets to/from the DNS server, but low enough that the connection is otherwise usable. I suspect that iffy wifi connections account for a decent number of the reports, but it should be reasonably practical to setup an environment to simulate this. https://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux has some halfway decent instructions on setting up a network interface to have a configurable percentage of packet loss and/or delayed packets. Like most people who get enough of networking to be able to easily work on the problem, I have a wired connection with no packet loss to speak of between my system and the DNS server. So it's not a bug which I run into in my day to day, but it is one that I've seen in the wild with my spouse's laptop every now and then. |
|
Sorry, but your comment is wrong. sd-resolved remembers the features it observed the remote server reply to and doesn't downgrade past that for packet loss, only if replies are mangled (missing or malformed options etc). Anyway even if that behavior is broken, the claim in this report is that sd-resolved "stops working", which I understand to mean that no queries succeed at any feature level for an indefinite period of time. That isn't the result of intermittent packet loss. The log messages are innocuous or symptomatic of something else. If you think there is an unresolved bug here, and you want to see progress, then please reproduce it, preferably on 255 or later, and provide a debug log. It shouldn't be difficult to obtain if you can reproduce. You can enable debug logging at runtime with And, please, describe whatever behavior you actually observe with more detail than "stops working". |
|
I've hit this issue as well. I'm fairly confident that the root cause in my case is slight packet loss on an (inevitable) powerline connection in my home LAN. Thus, I'd like to configure FWIW, I think the |
|
I'm getting this issue on a single machine out of hundreds of other identical, healthy machines on the same network. Cable/port and other external connectivity issues have been tentatively ruled out. We believe it may be caused by OS corruption.
|
and others
systemd version the issue has been seen with
242 (debian testing)
No problems before upgrading to testing. Stretch worked ok (232).
Used distribution
Debian testing
Problem
DNS resolution stops working. Logs around the time show
Around the same time, wan interface has some problems, loses DHCP lease, IPs/routes etc. are changing. Perhaps resolved doesn't pick up some changes and is tied to old ones?
Broken state persists for 10 hours.
systemctl restart systemd-resolvedfixes the problem immediately.Configuration
I don't think it affects anything, and this works fine (when DNS is working locally that is), but just in case: I'm exposing the stub listener as the DNS server on the LAN:
The text was updated successfully, but these errors were encountered: