Hi everyone,
Today I got an update via dnfdragora of network manager and since a reboot I have no name resolution anymore. I checked another user’s issue here: https://discussion.fedoraproject.org/t/connected-with-wifi-but-no-internet-after-f37-upgrade/73116
but could not figure out, if this is another issue or a similar one.
I have an ip address and can connect to other computers in the same network and the router by entering the target ip address, but not with a hostname. This behavior prevents me from connecting to the internet.
I tried to enter another DNS address in network settings manually, but it didn’t help.
Also I cannot revert the installation of the update, as dnfdragora seams to need the name resolution to connect to the repo server.
Too bad, it looks like I’m trapped. Is there anybody who can give advise how to fix this issue?
tia
stippi
P.S.
Using: F37 Cinnamon spin
alongside with the network manager update a new Kernel (6.0.17) has been installed as well, therefore the reboot.
I have
stippi@ThinkPadX1Carbon10th:~$ grep hosts /etc/nsswitch.conf
hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
stippi@ThinkPadX1Carbon10th:~$ sudo systemctl status systemd-resolved
[sudo] Passwort für stippi:
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled;>
Active: active (running) since Sun 2023-01-08 21:46:19 CET; 1min 41s ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-> https://www.freedesktop.org/wiki/Software/systemd/writing-resolver>
Main PID: 3404 (systemd-resolve)
Status: “Processing requests…”
Tasks: 1 (limit: 38104)
Memory: 3.9M
CPU: 59ms
CGroup: /system.slice/systemd-resolved.service
└─3404 /usr/lib/systemd/systemd-resolved
Jan 08 21:46:19 ThinkPadX1Carbon10th systemd[1]: Starting systemd-resolved.serv>
Jan 08 21:46:19 ThinkPadX1Carbon10th systemd-resolved[3404]: Positive Trust Anc>
Jan 08 21:46:19 ThinkPadX1Carbon10th systemd-resolved[3404]: . IN DS 20326 8 2 >
Jan 08 21:46:19 ThinkPadX1Carbon10th systemd-resolved[3404]: Negative trust anc>
Jan 08 21:46:19 ThinkPadX1Carbon10th systemd-resolved[3404]: Using system hostn>
Jan 08 21:46:19 ThinkPadX1Carbon10th systemd[1]: Started systemd-resolved.servi>
Jan 08 21:46:19 ThinkPadX1Carbon10th systemd-resolved[3404]: wlp0s20f3: Bus cli>
Jan 08 21:46:19 ThinkPadX1Carbon10th systemd-resolved[3404]: wlp0s20f3: Bus cli>
stippi@ThinkPadX1Carbon10th:~$ sudo resolvectl status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (wlp0s20f3)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 5.1.66.255
DNS Servers: 5.1.66.255 185.150.99.255 2001:678:e68:f000::
2001:678:ed0:f000::
But now I have internet again. I set the network settings regarding DNS back to ‘automatic’. Looks like it is working again, but I don’t figure out why. Except for the name of the router and hostnames within my local network it is working for the connection to the internet, now.
After another reboot the same issue. After ‘sudo systemctl restart systemd-resolved’ it worked again, but not for the local network (hostnames).
stippi@ThinkPadX1Carbon10th:~$ sudo resolvectl status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (wlp0s20f3)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 5.1.66.255
DNS Servers: 5.1.66.255 185.150.99.255 192.168.156.1 2001:678:e68:f000:: 2001:678:ed0:f000:: fd00::cece:1eff:feb9:2bd0
DNS Domain: fritz.box
stippi@ThinkPadX1Carbon10th:~$ sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Active: active (running) since Mon 2023-01-09 06:25:35 CET; 3min 34s ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5) writing-network-configuration-managers writing-resolver-clients
Main PID: 5986 (systemd-resolve)
Status: “Processing requests…”
Tasks: 1 (limit: 38104)
Memory: 3.9M
CPU: 88ms
CGroup: /system.slice/systemd-resolved.service
└─5986 /usr/lib/systemd/systemd-resolved
Jan 09 06:25:35 ThinkPadX1Carbon10th systemd[1]: Starting systemd-resolved.service - Network Name Resolution…
Jan 09 06:25:35 ThinkPadX1Carbon10th systemd-resolved[5986]: Positive Trust Anchors:
Jan 09 06:25:35 ThinkPadX1Carbon10th systemd-resolved[5986]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jan 09 06:25:35 ThinkPadX1Carbon10th systemd-resolved[5986]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172>
Jan 09 06:25:35 ThinkPadX1Carbon10th systemd-resolved[5986]: Using system hostname ‘ThinkPadX1Carbon10th’.
Jan 09 06:25:35 ThinkPadX1Carbon10th systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Your current DNS server is 5.1.66.255, which has no knowledge about internal systems. You switched DNS back to automatic, but then the question arises: what was it before?
You can try to switch in nm-connection-editor the wireless to IPv4 “DHCP addresses only” and specify 192.168.156.1 as DNS server. This forces use of Fritzbox DNS relay, which probably refers to the other ones but knows the internal addresses too. Search domain is fritz.box.
thank you for your advise. As far as I remember there was nothing specified in DNS except the automatic setting in the beginning. Then I switched to manual settings and inserted these IP’s manually. At the end I turned it back to automatic again and the manual settings kept in the nm-connection-editor. Now I inserted the IP’s (v4 + v6) in nm-connection-editor, but kept the automatic setting as well. This works for me and I can connect to local network by hostnames again.
The remaining question is still, what lead to this issue and how can I achieve that the system keeps the settings permanently, so that I don’t need to restart the resolve service after a reboot manually.
Now I have:
stippi@ThinkPadX1Carbon10th:~$ sudo resolvectl status
[sudo] Passwort für stippi:
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (wlp0s20f3)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.156.1
DNS Servers: 192.168.156.1
DNS Domain: fritz.box
stippi@ThinkPadX1Carbon10th:~$ sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Active: active (running) since Mon 2023-01-09 16:51:07 CET; 47min ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5) writing-network-configuration-managers writing-resolver-clients
Main PID: 9164 (systemd-resolve)
Status: “Processing requests…”
Tasks: 1 (limit: 38104)
Memory: 3.9M
CPU: 218ms
CGroup: /system.slice/systemd-resolved.service
└─9164 /usr/lib/systemd/systemd-resolved
Jan 09 16:51:07 ThinkPadX1Carbon10th systemd-resolved[9164]: Using system hostname ‘ThinkPadX1Carbon10th’.
Jan 09 16:51:07 ThinkPadX1Carbon10th systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jan 09 16:56:30 ThinkPadX1Carbon10th systemd-resolved[9164]: wlp0s20f3: Bus client reset search domain list.
Jan 09 16:56:30 ThinkPadX1Carbon10th systemd-resolved[9164]: wlp0s20f3: Bus client set default route setting: no
Jan 09 16:56:30 ThinkPadX1Carbon10th systemd-resolved[9164]: wlp0s20f3: Bus client reset DNS server list.
Jan 09 16:56:30 ThinkPadX1Carbon10th systemd-resolved[9164]: wlp0s20f3: Bus client set default route setting: yes
Jan 09 16:56:30 ThinkPadX1Carbon10th systemd-resolved[9164]: wlp0s20f3: Bus client set DNS server list to: 192.168.156.1, fd00::cece:1eff:feb9:2bd0
Jan 09 16:56:30 ThinkPadX1Carbon10th systemd-resolved[9164]: wlp0s20f3: Bus client set search domain list to: fritz.box
Jan 09 16:56:30 ThinkPadX1Carbon10th systemd-resolved[9164]: wlp0s20f3: Bus client set DNS server list to: 192.168.156.1
Jan 09 16:56:41 ThinkPadX1Carbon10th systemd-resolved[9164]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.156.1.
stippi@ThinkPadX1Carbon10th:~$ grep hosts /etc/nsswitch.conf
hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
I do not see a problem, systemd-resolved is enabled, settings are stored in NetworkManager and transferred by dbus to systemd-resolved, so everything looks fine.
The only thing I see are the IPv6 nameservers, have you checked on “https://ipv6-test.com” that you have a working IPv6 connection? The two starting with 2001: are working DNS servers. The one starting with fd00: is somewhat strange, because this is a local address. It’s possible that the fritx box issues them, but then it has to perform IPv6 nat, and the nice thing of IPv6 is that you do not need NAT anymore. In case of failure, look with resolvectl status to the Current DNS server and check with dig whether it works.
Yes, it’s the one from the FritzBox. From the current prospective it looks fine, yes. The question still unanswered is: why does it not keep this over a reboot? Why have I to restart resolved.service manually after a reboot to connect to the internet? And last but not least, why does this appear after nm update?
I tend to mark this issue as solved although it might be fixed only with the workaround of manually restarting resolved.service because I know how to fix it, now.
If you have no problem with the workaround, it’s fine of course. But normally it should not be necessary. But difficult to debug by forum. I’m not aware of changes is NetworkManager causing this problem when using a quit similar configuration.
Not really true.
IPv6 provides enough addresses that NAT is not required to support the number of machines in use and in that sense NAT is no longer required if you simply look at the number of addresses available. However, NAT provides more than just an ability to separate the private subnets for site use from the internet addresses and add those host numbers multiple times to the public address pool. It additionally hides the systems behind your home router from the internet with non-routable addresses.
If your system was to be behind a router that passed through the IPv6 addresses without using NAT then your system would essentially be directly connected to the internet. That would present a security nightmare to most home (and business) users since every machine (and IoT device) would be exposed for direct attack. Using NAT and private non-routable subnets the direct attack is stopped at the router/firewall/gateway device.
I agree, using NAT to a non-routable network creates additional security. Apparently the Fritzbox implements IPv6 in that way. The customer-grade routers provided by my Internet provider just pass the global address, but every port to every address is closed by default, same for the Fedora firewall. If you want to run a server, you have to open an address/port combination, just like IPv4/NAT, but you can run a firmware-limited number of servers on their default port.
If the Fritzbox implements “Network Prefix Translation”, as it is called in PfSense firewall, e.g. localaddress::/48 to globaladdress::/48, is this providing significant more security?
I cannot answer in detail security related questions. I am far from an expert in that area. I only know what many years of experience as a sysadmin have taught me, and that does not delve deep into the theoretical security issues nor the in depth workings of IPv6 routing.
Thanks, no problem. RIPE provides an extensive IPv6 security training course, which shows all caveats when using IPv6. 192 slides, so I will need some time to study…
Having global addresses is not a problem, but you definitely have to filter. For my connection, the providers router takes care of it. (tested).
