Hi there,
currently I try to debug an resolved-networkd issues, which is hard to
detect for myself.
Some technical facts:
- systemd 247 (247.3-7)
- 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 (2022-03-07) x86_64 GNU/Linux
within a LXC container
Description: I have setup an IPv6 only network with DHCPv6 to exchange
IP/Hostname relations. When the container boots up, it queries for an
IPv6 address via DHCPv6 (Rapid commit)...
# cat /etc/systemd/network/eth0.network
[Match]
Name=eth0
[Network]
DHCP=ipv6
This works as expected (checked with wireshark). After the DHCPv6
response, `networkctl` shows me the received DNS server...
# networkctl status eth0 | grep DNS
DNS: fdxy:abcd:abcd:abcd::1
but `resolved` did not get this DNS server...
# resolvectl status eth0
Link 2 (eth0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
and therefore `/etc/resolv.conf` is "empty". If I restart
`systemd-resolved` (`# systemctl restart systemd-resolved`) everything
works as expected, afterwards.
# resolvectl status eth0
Link 2 (eth0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
DNS Servers: fdxy:abcd:abcd:abcd::1
During some debugging, resolved-networkd has worked properly, if I
edited the systemd-service units, adding
'Environment=SYSTEMD_LOG_LEVEL=debug'. Every time restarting the
container, the DHCPv6-DNS nameserver exchange worked. When I removed all
additional systemd-unit edits, it 'failed' to set the DNS nameserver again.
My first guess is, that resolved misses somehow the networkd DNS
nameserver information. If I wait a second starting resolved (adding
'ExecStartPre=/bin/sleep 1' to the systemd-resolved-unit) it works as
expected.
Does someone has an idea, how I can debug this a little bit more and
maybe even fix it, without some strange workarounds like enabling debug
logging mode or slow down the startup process of resolved?
thx a lot, javud
some further information:
My system will not have an separate IPv6 route set, after the successful
DHCP response, but this should not matter anyway, cause the DNS server
adresse is reachable via the default route.
# ip -6 r
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::abcd:abff:fecd:abcd dev eth0 proto ra metric 1024 expires 1599sec mtu 1500 pref medium
