i get DNS resolution problems since fedora 33. Every new installation of fedora 33 as well as the latest fedora 34 give me those problems. Resulting in firefox being unusable because not resolving addresses and loading like forever or return a timeout of request after long time of waiting. Also fwupdmgr cannot download/refresh its data when using systemd-resolved. Sometimes even DNF fails to retrieve packages from mirror servers.
If i disable the systemd-resolved service and edit test-wise my
/etc/resolv.conf by removing the systemd-resolved stub listener loopback IP and put in the IP address of the DNS server in my network everything works fine. Also when i’m overcoming systemd-resolved by modifing the hosts in
/etc/nsswitch.conf removing the resolve entry from the hosts line everything works fine.
The thing is i want to use systemd-resolved or let’s better say i want to get it working correctly. The strange thing is that the settings look correct when calling
resolvectl status. Means it shows the correct IP address of the DNS server in my network. But if i query a problematic domain that wouldn’t resolve in firefox the query takes again very long and results in a timeout. But if use the option to explicitly use IPv4
resolvectl query github.com -4 it works instantly and systemd-resolved is able to resolve domains in the blink of an eye.
Would be thankful for any help.
This may sound silly, but have you checked to make sure Firefox is set to not use a proxy?
For some reason, my issues stemmed from “Use system proxy settings” being checked in Firefox.
Are you trying to use ipv6 or only ipv4? The resolvectl query command you posted limits the test to ipv4 only and it seems quite possible the timeout is in waiting for an ipv6 response before it falls back to ipv4.
Yeah i already checked that. Makes no difference if set to use system settings or set to use no proxy. Also the DNS over HTTPS setting makes no difference if turned on or off.
I followed your instructions but it didn’t worked out.
resolvectl query command still fails. Also not all websites i tested were resolvable.
If i activate the option to ignore auto DNS server detection which is literally what your stated answer does, i have to set a DNS server manually because NetworkManager cannot get the correct one by auto detecting. This should not be the goal to achieve.
I disabled IPv6 test-wise
echo 1 > /proc/sys/net/ipv6/conf/wlp2s0/disable_ipv6
Seems like in firefox now everything is working and the resolving performance is quite faster than before. Though
resolvectl query and
ping still fail. Using
dig works without problems on any website i tested. Stub listener works fine here as the answering DNS server used by dig.
That is what I expected from looking at other similar posts. It seems that the default order for dns queries is to use ipv6 first then fall back to ipv4 and since there are still a great many systems that do not do dns with ipv6 it has a long time out before the fallback occurs.
I hope there is some way to reverse the default order of dns queries.
resolvectl --no-pager status; resolvectl query openwrt.org
What is the output?
@computersavvy but why is a
resolvectl query still failing?
BTW: As i already said querying with resolvectl only works when using the option to only use IPv4. Though if you call without that option it kinda caches the route or something. So if you cancel after a second and recall with the IPv4 option activated again the query resolves and says:
Data from: cache.
Ping is still failing in any case. Even when explicitly use IPv4.
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (wlp2s0)
Current Scopes: DNS LLMNR/IPv4
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
DNS Servers: 192.168.1.1
openwrt.org: 184.108.40.206 -- link: wlp2s0
2a03:b0c0:3:d0::1af1:1 -- link: wlp2s0
-- Information acquired via protocol DNS in 35.0ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
The openwrt domain query ran through instantly
EDIT: Other domains like
github.com for example don’t work. Only some domains work. Ping is also working for those domains.
I guess the problem is what @computersavvy stated here:
As we see in the output of my
resolvectl query the
openwrt.org domain returns also an IPv6 address…
Receiving both IPv4 and IPv6 results is normal.
Does the issue persist if you replace the local resolver with a public one?
Ok seems like that’s the solution. Firefox working.
resolvectl query working.
The problem with this solution is that when changing the DNS server to a public one, your device is directly listed in the logs of the DNS server (e.g. Cloudflare, Google, etc.) or not?
Also you cannot resolve local domains in your network anymore…
By default, Fedora relies on the router that forwards DNS queries upstream to your ISP.
So if there’s a problem, its cause is typically the router itself or the ISP in front of it.
Specifically, incorrect ISP/router DNS configuration or buggy/outdated router firmware.
To proceed with troubleshooting, replace ISP DNS with public DNS on the router.
Then revert Fedora to automatic DNS and try to isolate the issue.
By the way, the ISP can also monitor and log all your unencrypted traffic including DNS.
You should use VPN or Tor if you are really concerned about privacy.
I changed my routers DNS server address to a public one, but it didn’t helped/changed anything. Firmware is up to date btw.
What is the firmware name and version?
Can you run tcpdump on the router?
Actually had this issue recently and this thread helped a lot. It was only happening when my laptop was connected to certain networks. To help folks who stumble upon this like me, you don’t need to disable IPv6 system wide, but can specify the DNS servers to use on a specific network by going to:
Wi-Fi Settings → Cog wheel to edit specific network → disable automatic DNS for IPv4 and IPv6 resolution and specify some public DNS servers to use (I chose the Google one’s located at IPv4 “220.127.116.11” and IPv6 “2001:4860:4860::8888”)
I hope that helps!