In one of the next commits we'd like to introduce a concept of
optionally hashing the hostname from the machine ID. For that we we need
to optionally back gethostname_full() by code involving sd-id128, hence
let's move it from src/basic/ to src/shared/, since only there we are
allowed to use our public APIs.
Commit 1be9b30a3b ("dhcp6: use dns_name_from_wire_format") introduced a
stricter validation of domains received via DHCPv6, by using function
dns_name_from_wire_format() which rejects the domain when it is missing the
terminating zero label. According to RFC 4704 § 4.2, DHCPv6 servers should
always add the zero label:
To send a fully qualified domain name, the Domain Name field is set
to the DNS-encoded domain name including the terminating zero-length
label. To send a partial name, the Domain Name field is set to the
DNS-encoded domain name without the terminating zero-length label.
[...]
Servers SHOULD send the complete fully qualified domain name in
Client FQDN options.
In practice, there is at least on common DHCPv6 server implementation (dnsmasq)
that sends the FQDN option without the ending zero-length label; after
upgrading to the new systemd, the client cannot parse the option and therefore
the machine doesn't get the hostname provided by dnsmasq.
This commit restores the old behavior that considers a domain valid even when
it's missing the terminating zero label.
Here's a quick reproducer:
--8<--
ip link add veth0 type veth peer name veth1
ip netns add ns1
ip link set veth1 netns ns1
ip link set veth0 address 00:11:22:33:44:55
ip link set veth0 up
ip -n ns1 link set veth1 up
ip -n ns1 address add dev veth1 fd01::1/64
ip netns exec ns1 dnsmasq \
--pid-file=/tmp/dnsmasq.pid --no-hosts \
--bind-interfaces --interface veth1 --except-interface lo \
--dhcp-range=fd01::100,fd01::200 --enable-ra \
--dhcp-host 00:11:22:33:44:55,foobar &
cat <<EOF > /etc/systemd/network/veth0.network
[Match]
Name=veth0
[Network]
DHCP=ipv6
EOF
networkctl reload
networkctl up veth0
sleep 5
hostname
--8<--
Without this change, systemd-networkd prints the following message and doesn't
set the hostname from DHCP:
veth0: DHCPv6 client: Failed to parse FQDN option, ignoring: Bad message
Not all possible DNS names will survive serialization. Restrict the set
of valid dns names to LDH encoded names.
Fixes: 25c33e3500 (network: parse RFC9463 DHCPv4 DNR option, 2024-01-16)
Fixes: a07e83cc58 (network: Parse RFC9463 DHCPv6 DNR option, 2024-01-17)
Fixes: 0c90d1d2f2 (ndisc: Parse RFC9463 encrypted DNS (DNR) option, 2024-01-19)
This reverts the following commits:
- 180cc5421d
"sd-dhcp6-client: allow to request IA_PD on information requesting mode"
- cf7a403e47
"sd-dhcp6-lease: adjust information refresh time with lifetime of IA_PD"
- 1918eda30d
"network/dhcp6: process hostname and IA_PD on information requesting mode"
As per discussion in #34299,
https://github.com/systemd/systemd/issues/34299#issuecomment-2425153221
the offending commits violate RFC 8415 section 18.2.6:
> The client uses an Information-request message to obtain
> configuration information without having addresses and/or delegated
> prefixes assigned to it.
Implement serialization/deserialization for DNR servers. This re-uses
the string format in place for user configuration of DoT servers, and as
a consequence non-DoT servers are discarded when recording the link
configuration, for correctness.
This also enables sd-resolved to use these servers as it would other DNS
servers.
This option is another way for DHCP servers to indicate preferred DNS
servers for the network, but includes more detailed info like the server
name, transport (DoT/DoH/DoQ etc.), and port.
Allow our DHCPv4 client to parse this option.
We can easily hit the assertions without checking the internal states of
the DHCP client before calling these functions. That's annoying.
Let's do more gracefully.
When an interface enters the failed state, even if the DHCP client is
stopped, the acquired DHCP lease is not unreferenced, as the callback
dhcp4_handler() do nothing in that case. When the failed interface is
being reconfigured after that, the DHCP client is stopped again
(though it is already stopped), and SD_DHCP_CLIENT_EVENT_STOP event is
triggered and sd_dhcp_client_send_release() is called, and the
assertion in the function is triggered.
E.g.
===
systemd-networkd[98588]: wlp59s0: DHCPv4 address 192.168.86.250/24, gateway 192.168.86.1 acquired from 192.168.86.1
systemd-networkd[98588]: wlp59s0: Could not set DHCPv4 route: Nexthop has invalid gateway. Network is unreachable
systemd-networkd[98588]: wlp59s0: Failed
systemd-networkd[98588]: wlp59s0: State changed: configuring -> failed
systemd-networkd[98588]: wlp59s0: The interface entered the failed state frequently, refusing to reconfigure it automatically.
systemd-networkd[98588]: wlp59s0: DHCPv4 client: STOPPED
systemd-networkd[98588]: wlp59s0: DHCPv4 client: State changed: bound -> stopped
systemd-networkd[98588]: Got message type=method_call sender=:1.449 destination=org.freedesktop.network1 path=/org/freedesktop/network1 interface=org.freedesktop.network1.Manager member=ReconfigureLink ...
systemd-networkd[98588]: wlp59s0: State changed: failed -> initialized
systemd-networkd[98588]: wlp59s0: found matching network '/etc/systemd/network/50-wifi.network'.
systemd-networkd[98588]: wlp59s0: Configuring with /etc/systemd/network/50-wifi.network.
systemd-networkd[98588]: wlp59s0: DHCPv4 client: STOPPED
systemd-networkd[98588]: Assertion 'sd_dhcp_client_is_running(client)' failed at src/libsystemd-network/sd-dhcp-client.c:2197, function sd_dhcp_client_send_release(). Aborting.
===