systemd-resolved uses malformed link-local IPv6 forwarder

[geppi]

In a network with a local nameserver that has IPv4-address 10.1.0.1 and link-local IPv6-address fe80::2a0:57ff:fe24:b041%2 'resolvectl' returns:

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

Link 2 (ens33)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::2a0:57ff:fe24:b041
       DNS Servers: 10.1.0.1 fe80::2a0:57ff:fe24:b041%21905
        DNS Domain: < edited >

Name resolution fails because the indicated 'Current DNS Server' IPv6-address is an incomplete link-local address. Also the link-local IPv6-address indicated in the second position of the 'DNS Servers' line is malformed. Issuing consecutive 'resolvectl' calls have the last 4 digits in this line changing, i.e. they all show 'fe80::2a0:57ff:fe24:b041%2', which would be the correct link-local IPv6-address including the interface specification, but then 4 digits that are not constant.

Workaround:

Take systemd-resoved out of stub-mode with:

(cd /etc && sudo rm -f resolv.conf && sudo ln -s /run/systemd/resolve/resolv.conf resolv.conf)

The auto generate file '/run/systemd/resolve/resolv.conf' has the proper specification of the name servers link-local IPv6-address:

nameserver 10.1.0.1
nameserver fe80::2a0:57ff:fe24:b041%2
search < edited >

The broken stub mode is configured with:

(cd /etc && rm -f resolv.conf && ln -s /run/systemd/resolve/stub-resolv.conf resolv.conf)

[Nick Rosbrook (enr0n)]

Since this is link-specific DNS, isn't the scope ID implied?

I do see the odd formatting issue in the 'DNS Servers' list:

$ resolvectl status wlp0s20f3
Link 4 (wlp0s20f3)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::dea6:32ff:febe:f88d
       DNS Servers: fe80::dea6:32ff:febe:f88d%21943
        DNS Domain: lan

but that should be harmless, and is fixed upstream by [1] (though it is not yet in any of Ubuntu's systemd releases).

I am currently running Kinetic, and with this setting my DNS seems to be working correctly. What release of Ubuntu are you on?

[1] https://github.com/systemd/systemd/commit/a5e6c8498ca

[geppi (tgeppert-digitx)]

I'm on Ubuntu 22.04 LTS. I always need to provide the interface specification when using link-local IPv6-addresses, e.g. a simple 'ping fe80::2a0:57ff:fe24' doesn't work but 'ping fe80::2a0:57ff:fe24%2' does the trick. I couldn't figure out why this is required on my desktop Ubuntu system. In contrary on a Debian bullseye server the IPv6-addresss without the interface specifier is sufficient. Any idea?

However, since it is required on my Ubuntu system the systemd-resolved stub doesn't work and I have to employ the workaround mentioned in my initial post. The '/run/systemd/resolve/resolv.conf' file contains the proper link-local IPv6-address of my name server including the interface specifier.

[Nick Rosbrook (enr0n)]

Right, I understand why it would be needed in a ping. But since the DNS server config in systemd-resolved applies to a specific link, the scope ID is implied.

As far as your desktop vs server systems, maybe it's the difference between the interfaces available on each system? If you only have one non-lo interface on the server, the scope ID shouldn't be necessary. But if your desktop has e.g. both wlan0 and eth0, then I would expect you need to specify the scope ID in a ping.

My system is working with systemd-resolved in stub mode, using my DNS server's IPv6 link-local address. So maybe there is something else on your system causing the problem.

Is there anything else odd about your network configuration? Can you share the output of `systemd-analyze cat-config systemd/resolved.conf`? Also when you are in stub mode, what does `SYSTEMD_LOG_LEVEL=debug resolvectl query google.com` show? It may be a good idea to run `resolvectl flush-caches` after switching back to stub mode.

[Launchpad Janitor (janitor)]

[Expired for systemd (Ubuntu) because there has been no activity for 60 days.]