Ethernet Not Working Without Setting 8.8.8.8 as DNS4

As per title, if I were to set my ethernet connection to use my router’s DNS (192.168.100.1), there would be no incoming internet, but I can access my router.

If I change the DNS4 to Google’s DNS, 8.8.8.8, it works.

Everything works fine in Windows 11.

Any thoughts on this?

image
image

When the issue happens, collect the output:

nslookup example.org 192.168.100.1
nslookup example.org fe80::1
resolvectl query example.org
resolvectl status --no-pager
systemctl status systemd-resolved.service
journalctl --no-pager -b -u systemd-resolved.service

$ nslookup example.org 192.168.100.1
Server: 192.168.100.1
Address: 192.168.100.1#53

Non-authoritative answer:
Name: example.org
Address: 93.184.216.34
Name: example.org
Address: 2606:2800:220:1:248:1893:25c8:1946

$ nslookup example.org fe80::1
;; UDP setup with fe80::1#53(fe80::1) for example.org failed: invalid file.
;; UDP setup with fe80::1#53(fe80::1) for example.org failed: invalid file.
;; UDP setup with fe80::1#53(fe80::1) for example.org failed: invalid file.

$ resolvectl query example.org
example.org: resolve call failed: Could not resolve ‘example.org’, server or network returned error REFUSED

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

Link 2 (enp38s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::1
DNS Servers: fe80::1

Link 3 (wlo1)
Current Scopes: none
Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported

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

$ systemctl status systemd-resolved.service
● 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-04-20 23:49:17 +08; 7min ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
writing-network-configuration-managers
writing-resolver-clients
Main PID: 1658 (systemd-resolve)
Status: “Processing requests…”
Tasks: 1 (limit: 77001)
Memory: 6.3M
CPU: 138ms
CGroup: /system.slice/systemd-resolved.service
└─1658 /usr/lib/systemd/systemd-resolved

Apr 20 23:49:17 x570-fedora-amac systemd-resolved[1658]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc>
Apr 20 23:49:17 x570-fedora-amac systemd-resolved[1658]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-ad>
Apr 20 23:49:17 x570-fedora-amac systemd-resolved[1658]: Using system hostname ‘x570-fedora-amac’.
Apr 20 23:49:17 x570-fedora-amac systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Apr 20 23:49:21 x570-fedora-amac systemd-resolved[1658]: enp38s0: Bus client set default route setting: yes
Apr 20 23:49:21 x570-fedora-amac systemd-resolved[1658]: enp38s0: Bus client set DNS server list to: 8.8.8.8
Apr 20 23:49:22 x570-fedora-amac systemd-resolved[1658]: enp38s0: Bus client set DNS server list to: 8.8.8.8, fe80::1
Apr 20 23:49:28 x570-fedora-amac systemd-resolved[1658]: Clock change detected. Flushing caches.
Apr 20 23:52:05 x570-fedora-amac systemd-resolved[1658]: enp38s0: Bus client set DNS server list to: fe80::1
Apr 20 23:52:07 x570-fedora-amac systemd-resolved[1658]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS se>
lines 1-27/27 (END)

$ journalctl --no-pager -b -u systemd-resolved.service
Apr 20 23:49:17 x570-fedora-amac systemd[1]: Starting systemd-resolved.service - Network Name Resolution…
Apr 20 23:49:17 x570-fedora-amac systemd-resolved[1658]: Positive Trust Anchors:
Apr 20 23:49:17 x570-fedora-amac systemd-resolved[1658]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Apr 20 23:49:17 x570-fedora-amac systemd-resolved[1658]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
Apr 20 23:49:17 x570-fedora-amac systemd-resolved[1658]: Using system hostname ‘x570-fedora-amac’.
Apr 20 23:49:17 x570-fedora-amac systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Apr 20 23:49:21 x570-fedora-amac systemd-resolved[1658]: enp38s0: Bus client set default route setting: yes
Apr 20 23:49:21 x570-fedora-amac systemd-resolved[1658]: enp38s0: Bus client set DNS server list to: 8.8.8.8
Apr 20 23:49:22 x570-fedora-amac systemd-resolved[1658]: enp38s0: Bus client set DNS server list to: 8.8.8.8, fe80::1
Apr 20 23:49:28 x570-fedora-amac systemd-resolved[1658]: Clock change detected. Flushing caches.
Apr 20 23:52:05 x570-fedora-amac systemd-resolved[1658]: enp38s0: Bus client set DNS server list to: fe80::1
Apr 20 23:52:07 x570-fedora-amac systemd-resolved[1658]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server fe80::1%2.

1 Like

Had to re-enable DNS4 8.8.8.8 for internet to work again and post the output of these commands that you requested.

Looks like your router announces IPv6 DNS, but it does not reply to IPv6 queries.

You have the following options:

  • Fix the router to properly reply to IPv6 DNS queries.
  • Stop announcing IPv6 DNS on the router.
  • Disable IPv6 DNS in the NetworkManager connection settings.
1 Like

Disabling IPv6 and putting 192.168.100.1 DNS4 works now. If DN4 is on automatic, it’s not working.

image

As for disabling IPv6 on GPON ONT / router, it is locked by my ISP so I don’t have that option to do so. I do run switches to connect all my PC/NAS/CCTV/Mesh WiFi stuff.

I think this is considered a solution, let me know so I can mark it as a solution (going to bed now and will check this in around 8 hours time).

Great, although it’s weird that IPv4 DNS is not registered automatically.
You can try to capture DHCP messages with tcpdump to identify the reason.