2

I upgraded my internet router today and found that my Linux system running Fedora 36 can no longer perform DNS name resolution. I also have Android devices, Windows 10, Windows 11, and CentOS 7.9 systems on the network which have not had any issue with this upgrade.

On my CentOS machine, /etc/resolv.conf contains:

# Generated by NetworkManager
nameserver 10.0.1.1

On my Fedora 36 machine, it contains:

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

Fedora 36 uses the systemd resolved service for managing DNS name servers, and adding additional entries such as 8.8.8.8 to this file and restarting this service regenerates the file and any changes are lost.

I don't understand what happened that only my Fedora 36 system is now unable to resolve domain names and I have been unable to find a way to fix it. I have tried lots of different Google searches, but there is a lot of conflicting information between distros and older versions of Fedora that a lot of the information is either irrelevant or contain procedures that have not provided any change in behavior.

I have no problem accessing the system over the local network and it can ping IP addresses just fine. But I can't ping any domains.

The error I get is:

$ ping google.com
ping: google.com: Temporary failure in name resolution

I have tried restarting the resolved and dnsmaq services:

systemctl restart systemd-resolved.service
systemctl restart dnsmasq

Making sure that DNS ports are open:

firewall-cmd --permanent --add-port=43/tcp
firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --reload

I tried bringing the ethernet adapter down and then back up again:

nmcli con down id Ethernet
nmcli con up id Ethernet

And I have tried adding 8.8.8.8 as the interface DNS for my ethernet card:

systemd-resolve --interface enp9s0 --set-dns 8.8.8.8

I have also tried flushing my DNS cache:

resolvectl flush-caches
sudo resolvectl flush-caches

This server is headless, so I can only access it via SSH. This means I can't change any settings from a desktop or GUI.

What is the problem, how did it happen, and how can I fix it? I don't understand what the problem is or how to proceed.

Here is some additional information:

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

Link 2 (enp9s0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp8s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
$ systemd-resolve --statistics
DNSSEC supported by current servers: no

Transactions
Current Transactions: 0
  Total Transactions: 0

Cache
  Current Cache Size: 0
          Cache Hits: 0
        Cache Misses: 0

DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0
$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-07-27 16:34:57 EDT; 16min 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: 1992495 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 76912)
     Memory: 4.0M
        CPU: 61ms
     CGroup: /system.slice/systemd-resolved.service
             └─ 1992495 /usr/lib/systemd/systemd-resolved

Jul 27 16:34:57 lserver systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
Jul 27 16:34:57 lserver systemd-resolved[1992495]: Positive Trust Anchors:
Jul 27 16:34:57 lserver systemd-resolved[1992495]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683>
Jul 27 16:34:57 lserver systemd-resolved[1992495]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.>
Jul 27 16:34:57 lserver systemd-resolved[1992495]: Using system hostname 'lserver'.
Jul 27 16:34:57 lserver systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jul 27 16:48:02 lserver systemd-resolved[1992495]: Flushed all caches.
Jul 27 16:48:30 lserver systemd-resolved[1992495]: Flushed all caches.
$ systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
     Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled; vendor preset: disabled)
     Active: active (running) since Wed 2022-07-27 16:49:49 EDT; 50s ago
    Process: 2045570 ExecStart=/usr/sbin/dnsmasq (code=exited, status=0/SUCCESS)
   Main PID: 2045572 (dnsmasq)
      Tasks: 1 (limit: 76912)
     Memory: 600.0K
        CPU: 3ms
     CGroup: /system.slice/dnsmasq.service
             └─ 2045572 /usr/sbin/dnsmasq

Jul 27 16:49:49 lserver systemd[1]: Starting dnsmasq.service - DNS caching server....
Jul 27 16:49:49 lserver dnsmasq[2045572]: started, version 2.86 cachesize 150
Jul 27 16:49:49 lserver dnsmasq[2045572]: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP DHCPv>
Jul 27 16:49:49 lserver dnsmasq[2045572]: reading /etc/resolv.conf
Jul 27 16:49:49 lserver dnsmasq[2045572]: using nameserver 127.0.0.53#53
Jul 27 16:49:49 lserver systemd[1]: Started dnsmasq.service - DNS caching server..
Jul 27 16:49:49 lserver dnsmasq[2045572]: read /etc/hosts - 2 addresses

My previous router was a Linksys WRT3200ACM with OpenWRT. My new router is a Netgear R7000 with FreshTomato. I appears that the router software is configured to act as a local DNS server, and this is reflected by the nameserver entry on my CentOS machine defaulting to 10.0.1.1, which is the default gateway address on the network. However, it seems to be performing its job, according to every other device on the network. And this still doesn't explain why Fedora 36 is the only system that is having a problem with it.

My IP address did NOT change as a result of this upgrade. The default gateway has always been configured as 10.0.1.1 and the IP for this machine has always been static as 10.0.1.21. The only change to the LAN was the router swap. Everything should have "just worked", as I had it already preconfigured with all of the necessary port forwarding.


Additional information as requested from the comments:

$ dig @10.0.1.1 bbc.co.uk

; <<>> DiG 9.16.30-RH <<>> @10.0.1.1 bbc.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16748
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;bbc.co.uk.                     IN      A

;; ANSWER SECTION:
bbc.co.uk.              177     IN      A       151.101.64.81
bbc.co.uk.              177     IN      A       151.101.128.81
bbc.co.uk.              177     IN      A       151.101.192.81
bbc.co.uk.              177     IN      A       151.101.0.81

;; Query time: 9 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Wed Jul 27 17:21:01 EDT 2022
;; MSG SIZE  rcvd: 102
$ dig @127.0.0.53 bbc.co.uk

; <<>> DiG 9.16.30-RH <<>> @127.0.0.53 bbc.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58582
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bbc.co.uk.                     IN      A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Jul 27 17:21:26 EDT 2022
;; MSG SIZE  rcvd: 38
$ dig @8.8.8.8

; <<>> DiG 9.16.30-RH <<>> @8.8.8.8
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32553
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       615     IN      NS      m.root-servers.net.
.                       615     IN      NS      b.root-servers.net.
.                       615     IN      NS      c.root-servers.net.
.                       615     IN      NS      d.root-servers.net.
.                       615     IN      NS      e.root-servers.net.
.                       615     IN      NS      f.root-servers.net.
.                       615     IN      NS      g.root-servers.net.
.                       615     IN      NS      h.root-servers.net.
.                       615     IN      NS      a.root-servers.net.
.                       615     IN      NS      i.root-servers.net.
.                       615     IN      NS      j.root-servers.net.
.                       615     IN      NS      k.root-servers.net.
.                       615     IN      NS      l.root-servers.net.

;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jul 27 17:21:32 EDT 2022
;; MSG SIZE  rcvd: 239
$ journalctl _SYSTEMD_UNIT=systemd-resolved.service
...
-- Boot 66eaabbbfb7e4f7b9f34c9b3316f1e07 --
Jul 15 08:06:43 lserver systemd-resolved[1456]: Positive Trust Anchors:
Jul 15 08:06:43 lserver systemd-resolved[1456]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jul 15 08:06:43 lserver systemd-resolved[1456]: 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.>
Jul 15 08:06:43 lserver systemd-resolved[1456]: Using system hostname 'lserver'.
Jul 15 08:06:48 lserver systemd-resolved[1456]: enp9s0: Bus client set default route setting: yes
Jul 15 08:06:48 lserver systemd-resolved[1456]: enp9s0: Bus client set DNS server list to: fdf5:328d:f2ee::1
Jul 27 12:35:17 lserver systemd-resolved[1456]: enp9s0: Bus client set default route setting: no
Jul 27 12:35:17 lserver systemd-resolved[1456]: enp9s0: Bus client reset DNS server list.
Jul 27 14:55:04 lserver systemd-resolved[1456]: Flushed all caches.
Jul 27 14:55:08 lserver systemd-resolved[1456]: Flushed all caches.
Jul 27 14:55:42 lserver systemd-resolved[1456]: Flushed all caches.
Jul 27 14:55:47 lserver systemd-resolved[1456]: [Scope protocol=llmnr interface=enp9s0 family=AF_INET6]
Jul 27 14:55:47 lserver systemd-resolved[1456]: [Scope protocol=llmnr interface=enp9s0 family=AF_INET]
Jul 27 14:55:47 lserver systemd-resolved[1456]: [Scope protocol=dns]
Jul 27 14:57:58 lserver systemd-resolved[1620611]: Positive Trust Anchors:
10
  • What do you get when you run resolvectl status as the file suggested?
    – stark
    Jul 27, 2022 at 21:06
  • 1. I'm a little puzzled why you are running dnsmasq as well as systemd-resolved Jul 27, 2022 at 21:08
  • 2. Those firewall rules. You should have port 53 open outbound for UDP and TCP. I don't see the relevance of port 43. Jul 27, 2022 at 21:12
  • 3. On Fedora, does dig @10.0.1.1 bbc.co.uk return a set of IP addresses? What about dig @127.0.0.53 bbc.co.uk? Finally, what about dig @8.8.8.8 bbc.co.uk? If none of those works please switch off the Fedora firewall completely and repeat the tests. Any change? Jul 27, 2022 at 21:14
  • @stark I've added this information as requested.
    – Zhro
    Jul 27, 2022 at 21:19

1 Answer 1

0

I'm answering my own question to share the workaround I ended up using, but I'm not inclined to accept it, because I think that the operating system should be capable of configuring the DNS server automatically. I'm still not confident as to why this problem exists, why it only occurred after I swapped out the router, and ONLY on my Fedora 36 system.

To work around this issue, I ended up copying the behavior of my CentOS machine where the DNS server was set to the default gateway, which is my router's address of 10.0.1.1. For systemd-resolved, this is done by editing the /etc/systemd/resolved.conf file and adding an entry to the DNS= line.

[Resolve]
DNS=10.0.1.1

It also works fine with other known DNS hosts such as 8.8.8.8, 1.1.1.1, etc. But it makes sense to use my router as it is also performing DNS lookups there and has its own cache.

I don't understand why this is an issue, either with Fedora 36 or for my environment specifically, but I feel like this is a problem that I shouldn't have had to deal with.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .