I went to do an update after installation with “sudo dnf clean all” and “sudo dnf --allowerasing distro-sync” and it timed out with:
OpenMandriva Rolling - x86_64 0.0 B/s | 0 B 06:00
Errors during downloading metadata for repository 'rolling-x86_64':
- Curl error (28): Timeout was reached for http://mirror.openmandriva.org/rolling/repository/x86_64/main/release/repodata/repomd.xml [Resolving timed out after 30001 milliseconds]
- Curl error (28): Timeout was reached for http://abf-downloads.openmandriva.org/rolling/repository/x86_64/main/release/repodata/repomd.xml [Resolving timed out after 30001 milliseconds]
Error: Failed to download metadata for repo 'rolling-x86_64': Librepo was interrupted by a signal
Ignoring repositories: rolling-x86_64
So, a DNS resolution problem. Odd …
So I tried pulling those XML file in the browser. They eventually pulled but it took a while.
Ok, so I backed up and tried nslookup on one of the hostnames and got:
nslookup mirror.openmandriva.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: mirror.openmandriva.org
Address: 140.211.11.99
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; no servers could be reached
Then I found where OM is using systemd-resolved which runs a “stub” server at 127.0.0.53 and does its DNS management from there. Ok … odd but fine. I’m sure there’s a good reason.
I temporarily commented out 127.0.0.53 in /etc/resolv.conf and put in 8.8.8.8 for the nameserver and nslookups did fine then. The browser lookups were still extremely slow but browsers cache name resolution settings themselves often. I put the default settings back in /etc/resolv.conf and still have the same behavior.
Any ideas on why it would be giving an answer to the IP address query then start timing out in the same request?
Did you manually modify the reolv.conf file by chance? If not, check that it is properly linked to /run/systemd/resolve/stub-resolv.conf. You can check it with
It does seem to be properly linked to /run/systemd/resolve/stub-resolv.conf
I edited with ‘nano /etc/resolv.conf’ which I would assume edited the linked file. That was just to test what using 8.8.8.8 would do then I put it back the way it was.
I was never a fan of systemd-resolved for the same reason as the topic of this post, but also I prefer to have my hosts connect directly to an instance of Pihole + Unbound running on my various vlans.
As an alternative, instead of disabling systemd-resolved, you can bypass it by doing this:
Edit /etc/systemd/resolved.conf
Change the line
#DNSStubListener=yes
to
DNSStubListener=no
(make sure to remove the “#”)
Save and close the file
systemctl stop systemd-resolved
systemctl status systemd-resolved (make sure the service is now inactive)
rm /etc/resolv.conf
Reboot
resolvectl status (to check your work)
If you’re using DHCP, you should now see those DHCP assigned servers listed in the results of the command above, along with the fallback servers specified in the /etc/systemd/resolved.conf file that you edited in step 1. Also, your /etc/resolv.conf file should now show the “nameserver 127.0.0.53” line has been removed.