DNS Resolver does not start correctly

Ask Fedora
, , , ,
1

Dear community,

I am using Fedora since serveral years absolutely flawless. Great distribution! Since upgrading to Fedora 39 I am facing issues with Wayland (as described in a different thread) and since about a week with the DNS resolver configuration.

After booting the sytsem and logging in and already at the login screen, the Gnome desktop shows an icon, which indicates failure on the network connection, which in my case is Ethernet based.

Bildschirmfoto vom 2023-12-15 16-57-29

Webbrowsers show, that thry cannot resolve names. The local network is working though and I can access ressources through local IP addresses.

Looking up hostnames I get an error message, that the local DNS server is not accessible ā€œconnection refusedā€:

[eth@wlg3060 ~]$ dig discussion.fedoraproject.org
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.18.20 <<>> discussion.fedoraproject.org
;; global options: +cmd
;; no servers could be reached

The funny thing is, that it is good enough to issue the command resolvectl status, which already repairs the DNS lookup. A following call to dig returns the correct IP address.

[eth@wlg3060 ~]$ resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp5s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
       DNS Servers: 192.168.178.9 fd00::1c5a:584f:362f:3ba2
        DNS Domain: fritz.box

Link 3 (wlo1)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
[eth@wlg3060 ~]$ dig discussion.fedoraproject.org

; <<>> DiG 9.18.20 <<>> discussion.fedoraproject.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12925
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;discussion.fedoraproject.org.	IN	A

;; ANSWER SECTION:
discussion.fedoraproject.org. 300 IN	CNAME	fedoraproject.hosted-by-discourse.com.
fedoraproject.hosted-by-discourse.com. 300 IN A	184.105.99.43

;; Query time: 183 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Dec 15 16:58:56 CET 2023
;; MSG SIZE  rcvd: 124

Thus there is an easy work-around available, but it is quite annoying to go to the shell after every boot.

Am I the only person who has this problem on a recently updated Fedora 39 system? Why is the DNS system refusing connections? How to fix this?

I am willing to share more configuration details, but do hard to identify, which configs to share.

The obvious resolve.conf contains:

nameserver 127.0.0.53
options edns0 trust-ad
search fritz.box

Thank you for any hint in advance!
Thomas

1 Like
2

That triggered a memory from long ago from earlier attempts at improving DNS performance and security. And from that, I found this in current systemd, which may be relatedā€¦

3

If resolvectl command fixes your name resolution, I would say you have system configured to use systemd-resolved, but systemd-resolved.service is not enabled and running by default, but by dbus activation it is started. That would get started by any use of resolvectl command like you described.

Check systemctl is-enabled systemd-resolved commands returns enabled. If it does not, you can fix it by systemctl enable --now systemd-resolved. But address 127.0.0.1 suggests it is not set in /etc/resolv.conf file, because it uses address 127.0.0.53 by default.

You can also use alternatives like dnsmasq from Network Manager by using:

# /etc/NetworkManager/conf.d/dns.conf
[main]
dns=dnsmasq

Edit: Seems similar to Systemd-resolved fails on initial load, may just selinux context fixes correct it?

1 Like
4

Thank you and sorry for the delay in my answer, I am quire busy this week.

systemd-resolved is running and is started automatically:

ā— systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             ā””ā”€10-timeout-abort.conf
     Active: active (running) since Thu 2023-12-21 18:37:28 CET; 3min 21s ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 4994 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 57528)
     Memory: 5.2M
        CPU: 110ms
     CGroup: /system.slice/systemd-resolved.service
             ā””ā”€4994 /usr/lib/systemd/systemd-resolved

The directory /etc/NetworkManager/conf.d/ is empty. Thus there is not dns.conf file.

I will try sudo fixfiles onboot, as suggested here: Systemd-resolved fails on initial load - #10 by grumpey and report back.

5

It looks like it had been a SELinux issue.
sudo fixfiles onboot fixed the problem.
Thank you Petr @pemensik!

1 Like
6

Thank you very much, this helped me as well!

7

Just for your information: The same happened again yesterday: Resolvecontrol was not workling after updating Fedora 40 to the latest software.
And again ā€˜sudo fixfiles onbootā€™ fixed the problem again.

8

I had to deal with it again today. ā€˜sudo fixfiles onbootā€™ worked again, but honestly, no matter what distro (Fedora, Zorin, Pop!, Elementary, Rhino) I used so far, it never worked more than two months, until another issue with heavy impact on using computer came up like no internet, no sound, black screen, freezing, booting issue and such without me tinkering on it. I just install updates when offered in the Software app.

9

I havenā€™t heard of fixfiles before, but I wonder how that differs from sudo touch /.autorelabel ?

Changing SELinux States and Modes :: Fedora Docs mentions that fixfiles creates the autorelabel file, but Iā€™m not sure why -F would be required? I used the touch command as-is without -F and it re-labeled on next boot no problem, and Iā€™d figure if that file exists that a relabel would be forced anyway?