[kwlug-disc] Systemd resolv issue ...

Chris Irwin chris at chrisirwin.ca
Tue Feb 10 21:16:12 EST 2026


On Tue, Feb 10, 2026 at 08:33:55PM -0500, Khalid Baheyeldin wrote:
>And when checking who is listening on port 53
>
>sudo netstat -ltunp | grep -w 53 | grep -v 54
>tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 2056751/systemd-res
>udp 0 0 127.0.0.53:53 0.0.0.0:*        2056751/systemd-res
>
>Note that systemd-resolved shows "LISTEN" on the tcp port, but not the udp
>one.

I think that's normal.

I'm fairly positive (and a quick search appears to confirm) that only 
TCP ports will show a LISTEN state due to the connection-oriented nature 
of TCP. UDP ports just show as open ports.

This is my working systemd-resolved on my laptop. Note the lack of 
LISTEN on udp sockets:

     $ sudo netstat -ltunp | grep -w 53
     tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      65599/systemd-resol
     tcp        0      0 127.0.0.54:53           0.0.0.0:*               LISTEN      65599/systemd-resol
     udp        0      0 127.0.0.54:53           0.0.0.0:*                           65599/systemd-resol
     udp        0      0 127.0.0.53:53           0.0.0.0:*                           65599/systemd-resol

>So my questions are:
>Why would the above happen?
>And how to prevent it from happening again?

1. Is your resolv.conf pointing to systemd-resolved?

     I'm going to assume 'yes', based on your dig output.

     However, is it an appropriate symlink? I believe systemd-resolved 
     keys off the symlink to determine if it's operating in client or 
     server mode.

     If it's operating in client mode, and /etc/resolv.conf points to 
     systemd-resolved again, then it might loop and time out.

     Mine looks like this:

     $ ls -l /etc/resolv.conf
     lrwxrwxrwx. 1 root root 39 2022-09-21 23:58 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

2. Is systemd-resolved able to query hostnames directly?

     Eliminate a step from the test.

     $ resolvectl query google.com
     google.com: 2607:f8b0:4023:1807::8b            -- link: wlp1s0
                 2607:f8b0:4023:1807::71            -- link: wlp1s0
                 2607:f8b0:4023:1807::64            -- link: wlp1s0
                 2607:f8b0:4023:1807::65            -- link: wlp1s0
                 192.178.192.100                    -- link: wlp1s0
                 192.178.192.138                    -- link: wlp1s0
                 192.178.192.102                    -- link: wlp1s0
                 192.178.192.113                    -- link: wlp1s0
                 192.178.192.139                    -- link: wlp1s0
                 192.178.192.101                    -- link: wlp1s0

     -- Information acquired via protocol DNS in 131.5ms.
     -- Data is authenticated: no; Data was acquired via local or encrypted transport: no
     -- Data from: network

3. What does systemd think your upstream DNS servers are?

     If you have multiple active NICs, you'll have multiple "Current" DNS 
     servers (they're per-interface), and will probably want to review 
     this without 'grep'.

     $ resolvectl | grep "DNS Server"
     Fallback DNS Servers: 149.112.121.20 149.112.122.20 2620:10a:80bb::20
     Current DNS Server: 10.10.10.1
            DNS Servers: 10.10.10.1 2607:f2c0:e798:500::1


     If you don't have any (or incorrect) DNS server, your interface 
     config might be missing information.

4. Any errors in the logs?

     $ journalctl -u systemd-resolved

-- 
Chris Irwin

email:   chris at chrisirwin.ca
   web: https://chrisirwin.ca


More information about the kwlug-disc mailing list