Dns problem in fedora server due to resolvectl

Ask Fedora
1

Hi,

At Each reboot from my fedora server 34 the same story occurs since a recent update

I m getting this :

Global
       Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp5s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (bridge0)
Current Scopes: none
     Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
   DNS Servers: 192.168.5.10 192.168.5.2
Failed to get link data for 4: Unknown object '/org/freedesktop/resolve1/link/_34'.
Failed to get link data for 5: Unknown object '/org/freedesktop/resolve1/link/_35'.
Failed to get link data for 6: Unknown object '/org/freedesktop/resolve1/link/_36'.
Failed to get link data for 7: Unknown object '/org/freedesktop/resolve1/link/_37'.
Failed to get link data for 8: Unknown object '/org/freedesktop/resolve1/link/_38'.
Failed to get link data for 9: Unknown object '/org/freedesktop/resolve1/link/_39'.
Failed to get link data for 10: Unknown object '/org/freedesktop/resolve1/link/_310'.
Failed to get link data for 11: Unknown object '/org/freedesktop/resolve1/link/_311'.
Failed to get link data for 12: Unknown object '/org/freedesktop/resolve1/link/_312'.
Failed to get link data for 13: Unknown object '/org/freedesktop/resolve1/link/_313'.
Failed to get link data for 14: Unknown object '/org/freedesktop/resolve1/link/_314'.
Failed to get link data for 15: Unknown object '/org/freedesktop/resolve1/link/_315'.
Failed to get link data for 16: Unknown object '/org/freedesktop/resolve1/link/_316'.
Failed to get link data for 17: Unknown object '/org/freedesktop/resolve1/link/_317'.
Failed to get link data for 18: Unknown object '/org/freedesktop/resolve1/link/_318'.
Failed to get link data for 19: Unknown object '/org/freedesktop/resolve1/link/_319'.
Failed to get link data for 20: Unknown object '/org/freedesktop/resolve1/link/_320'.

While I should get this:

Global
       Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp5s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (bridge0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
     Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
   DNS Servers: 192.168.5.10 192.168.5.2

Link 4 (virbr7)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (virbr3)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (virbr1)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 7 (virbr8)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 8 (virbr4)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 9 (virbr6)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 10 (virbr0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 11 (virbr2)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 12 (vnet0)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 13 (vnet1)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 14 (vnet2)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 15 (vnet3)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 16 (vnet4)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 17 (vnet5)
Current Scopes: LLMNR/IPv6

Which is what I get when I m restarting the service but it’s still annoying.
Especially since I can’t set any global dns server since there is not /etc/resolvconf folder.
But anyway since the configuration didn’t change, it must be a wrong startup booting sequence for resolvectl

2 Likes
2

I think I’m experiencing the same issue, but I’m using Fedora workstation. I, too, installed an update recently that seems to have broken DNS. I have a pretty generic setup, HP Pavilion laptop, no VPN, home router with DHCP. I took some (possibly bad) advice from the internet and modified /etc/systemd/resolved.conf, adding my local router as DNS and Google DNS as fallback. Nothing changed when I did this, but after I issue the command sudo systemctl restart systemd-resolved.service it begins to work again, until the next reboot.

4

Perhaps you can start collecting diagnostics:

nmcli general status; nmcli connection show; \
networkctl --no-pager status; networkctl --no-pager list
5

At which stage ? When it fils or even after the restart of the process?

That’s the stage after having the service restarted and when it is working. Network manager is activated. Systemd-networkd is not loaded.

â—‹ systemd-networkd.service - Network Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: â—‹ systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)

$ sudo networkctl --no-pager list
WARNING: systemd-networkd is not running, output will be incomplete.

IDX LINK    TYPE     OPERATIONAL SETUP    
  1 lo      loopback n/a         unmanaged
  2 enp5s0  ether    n/a         unmanaged
  3 bridge0 bridge   n/a         unmanaged
  4 virbr0  bridge   n/a         unmanaged
  5 virbr1  bridge   n/a         unmanaged
  6 virbr7  bridge   n/a         unmanaged
  7 virbr4  bridge   n/a         unmanaged
  8 virbr8  bridge   n/a         unmanaged
  9 virbr3  bridge   n/a         unmanaged
 10 virbr6  bridge   n/a         unmanaged
 11 virbr2  bridge   n/a         unmanaged
 12 vnet0   ether    n/a         unmanaged
 13 vnet1   ether    n/a         unmanaged
 14 vnet2   ether    n/a         unmanaged
 15 vnet3   ether    n/a         unmanaged
 16 vnet4   ether    n/a         unmanaged
 17 vnet5   ether    n/a         unmanaged
 18 vnet6   ether    n/a         unmanaged
 19 vnet7   ether    n/a         unmanaged
 20 vnet8   ether    n/a         unmanaged
 21 vnet9   ether    n/a         unmanaged
 22 vnet10  ether    n/a         unmanaged
 23 vnet11  ether    n/a         unmanaged

23 links listed.

$ sudo networkctl --no-pager status
WARNING: systemd-networkd is not running, output will be incomplete.

â—Ź   State: n/a
  Address: 192.168.5.101 on bridge0
           192.168.122.1 on virbr0
           fe80::84e4:e6bb:9dc5:134f on bridge0
           fe80::fc54:ff:fe23:9b4d on vnet0
           fe80::fc54:ff:fe2e:d075 on vnet1
           fe80::fc54:ff:fe17:f55c on vnet2
           fe80::fc54:ff:feb1:d287 on vnet3
           fe80::fc54:ff:fe82:b7cf on vnet4
           fe80::fc54:ff:fea7:daa0 on vnet5
           fe80::fc54:ff:fe58:416b on vnet6
           fe80::fc54:ff:fec7:b2e2 on vnet7
           fe80::fc54:ff:fe05:f438 on vnet8
           fe80::fc54:ff:fe41:af41 on vnet9
           fe80::fc54:ff:fea7:84e2 on vnet10
           fe80::d456:eff:fe16:bc54 on vnet11
  Gateway: 192.168.5.1 (Ubiquiti Networks Inc.) on bridge0

$ sudo nmcli con show
NAME     UUID                                  TYPE      DEVICE  
bridge0  36622bee-e5e3-472f-aa09-1cbfc7ae570c  bridge    bridge0 
virbr0   98c3ea89-54da-46aa-887f-88da66c3e6b5  bridge    virbr0  
enp5s0   74076075-2962-4629-9711-b85aeed8fd46  ethernet  enp5s0  
virbr1   347ef7f3-244d-448e-b61f-436ae495bf78  bridge    virbr1  
virbr2   3a3f4858-cdd0-455d-bb98-2b6890f41aa1  bridge    virbr2  
virbr3   992c7f68-eff2-47b4-8ee3-67a2962273b9  bridge    virbr3  
virbr4   1f715b68-a8f3-4163-872a-d70b330d9fad  bridge    virbr4  
virbr6   d838645c-615d-46f8-b0e0-6c6263b08082  bridge    virbr6  
virbr7   166da787-14e8-4fd1-b16f-8fe02e7454c5  bridge    virbr7  
virbr8   3474b495-3f16-486e-8748-8a0b19abc9b5  bridge    virbr8  
vnet0    fec605af-bfe6-4086-a428-7e4a1b087926  tun       vnet0   
vnet1    50ee1a35-dbad-4da4-bb37-5db1a3c1596a  tun       vnet1   
vnet10   c4685c9f-91d1-4fdd-b6af-ada6542ccfdc  tun       vnet10  
vnet11   e4c78a16-ef08-4d21-afcf-34e5ae6ffe6f  tun       vnet11  
vnet2    79ea5e65-fb24-4670-9f1d-14d7467451ca  tun       vnet2   
vnet3    259bdfae-4ca1-48fe-b20b-6448dbb20e7e  tun       vnet3   
vnet4    3f2fd9b5-d510-4ba7-a2e1-3bfd7d18ff47  tun       vnet4   
vnet5    a22cafb8-4514-4a20-b07f-caefeb352df4  tun       vnet5   
vnet6    94f340ac-ea1d-4eee-a7d3-098df721bd20  tun       vnet6   
vnet7    6e73ddf7-5842-4112-aade-e1002fc29ded  tun       vnet7   
vnet8    bcc57fc9-90cd-47ba-bac0-728d45587093  tun       vnet8   
vnet9    f492cfef-bc86-49c8-a407-1f60ae46e766  tun       vnet9

$ sudo nmcli 
bridge0: connected to bridge0
        "bridge0"
        bridge, A2:10:A5:5D:A2:A7, sw, mtu 1500
        ip4 default
        inet4 192.168.5.101/25
        route4 192.168.5.0/25
        route4 0.0.0.0/0
        inet6 fe80::84e4:e6bb:9dc5:134f/64
        route6 fe80::/64

virbr0: connected (externally) to virbr0
        "virbr0"
        bridge, 52:54:00:53:49:17, sw, mtu 1500
        inet4 192.168.122.1/24
        route4 192.168.122.0/24

virbr1: connected (externally) to virbr1
        "virbr1"
        bridge, 52:54:00:36:F5:7C, sw, mtu 1500

virbr2: connected (externally) to virbr2
        "virbr2"
        bridge, 52:54:00:8E:4C:9A, sw, mtu 1500

virbr3: connected (externally) to virbr3
        "virbr3"
        bridge, 52:54:00:E1:38:BA, sw, mtu 1500

virbr4: connected (externally) to virbr4
        "virbr4"
        bridge, 52:54:00:AB:3C:5D, sw, mtu 1500

virbr6: connected (externally) to virbr6
        "virbr6"
        bridge, 52:54:00:D9:41:9E, sw, mtu 1500

virbr7: connected (externally) to virbr7
        "virbr7"
        bridge, 52:54:00:0C:64:82, sw, mtu 1500

virbr8: connected (externally) to virbr8
        "virbr8"
        bridge, 52:54:00:99:B4:E1, sw, mtu 1500

enp5s0: connected to enp5s0
        "Qualcomm Atheros Killer E2400"
        ethernet (alx), D0:50:99:82:2E:5B, hw, mtu 1500
        master bridge0

vnet0: connected (externally) to vnet0
        "vnet0"
        tun, 3E:9B:9D:6D:F2:BA, sw, mtu 1500
        master virbr8

vnet1: connected (externally) to vnet1
        "vnet1"
        tun, FE:54:00:2E:D0:75, sw, mtu 1500
        master virbr4

vnet10: connected (externally) to vnet10
        "vnet10"
        tun, FE:54:00:A7:84:E2, sw, mtu 1500
        master virbr7

vnet11: connected (externally) to vnet11
        "vnet11"
        tun, D6:56:0E:16:BC:54, sw, mtu 1500
1 Like
6

Your issue might be related to the following:
1840790 – systemd-resolved preserves DNS for inactive wired connections
A possible workaround is replacing NetworkManager with systemd-networkd.

7

What would you recommend on a server?

8

Yep, this is how I set up the networking on my servers:
https://wiki.archlinux.org/title/Systemd-networkd#Bridge_interface

9

Okey I will give it a go then

1 Like
10

Hi, this is happening to me too in Fedora 34 Workstation.

I’ve opened this bug report: 1977661 – systemd-resolved not working after boot

11

Did you reference this forum thread just for the sake of the argument ?

12

Now yes :wink:

13

@jorti @vgaetera the problem has been resolved in the new kernel update 12.13
Still going to configure with systems-network but it’s nice that it has been resolved

But just FYI, there is now a little bug (if we can call it that). A stall in the startup process at the next step after reach boot partition or root partition? After having accepted the password for encrypted partition

14

I remember why I didn’t use it. It is not compatible with cockpit correct ?

15

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.