-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
rhel-9.6.z
-
None
-
None
-
None
-
rhel-net-mgmt
-
None
-
False
-
False
-
-
None
-
None
-
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
None
What were you trying to do that didn't work?
Setting ipv6.ignore-auto-dns=yes on an active connection and running nmcli device reapply to suppress DHCPv6-provided DNS servers. The IPv4 equivalent (ipv4.ignore-auto-dns=yes) works correctly on reapply, but
the IPv6 DNS from the cached DHCPv6 lease persists in the resolver configuration.
What is the impact of this issue to you?
In kubevirtci environments, nodes receive a DHCPv6 DNS server (fd00::1 via dnsmasq --dhcp-option=option6:dns-server,[fd00::1]) at initial boot. When workloads later need to override DNS configuration by
setting ipv6.ignore-auto-dns=yes and reapplying, the stale DHCPv6 DNS server remains active, causing DNS resolution to go to an unintended resolver. This cannot be worked around without fully cycling the
connection (down/up), which causes network disruption. The same issue also affects ipv6.ignore-auto-routes and ipv6.never-default on reapply, since they share the same merge flags mechanism.
Please provide the package NVR for which the bug is seen: 1.54.3-2.el9
How reproducible is this bug?: Always
Steps to reproduce
1. Have NetworkManager manage an interface with ipv6.method=auto where a DHCPv6 server provides DNS (e.g., dnsmasq with --dhcp-option=option6:dns-server,[fd00::1]).
2. Confirm DHCPv6 DNS is active:
nmcli device show eth0 | grep IP6.DNS
2. Output shows: IP6.DNS[1]: fd00::1
3. Set ignore-auto-dns and reapply:
nmcli connection modify <connection-name> ipv6.ignore-auto-dns yes
nmcli device reapply eth0
4. Check DNS again:
nmcli device show eth0 | grep IP6.DNS
Expected results
After reapply, IP6.DNS should be empty — no DHCPv6-provided DNS servers should appear, matching the behavior of ipv4.ignore-auto-dns=yes on reapply.
Actual results
IP6.DNS[1]: fd00::1 still appears. The DHCPv6 DNS server from the cached lease persists despite ipv6.ignore-auto-dns=yes.
Comments
The root cause is in src/core/devices/nm-device.c: during reapply, check_and_reapply_connection() invalidates the device-side merge flags cache (l3config_merge_flags_has = FALSE at line 14606) but does not
re-register existing l3cds in l3cfg with the updated flags. The DHCPv6 L3ConfigData entry retains its old merge flags (without NM_L3_CONFIG_MERGE_FLAGS_NO_DNS). Compounding this, the preserved DHCPv6 mode
(priv->ipdhcp_data_6.v6.mode, not reset because full_cleanup=FALSE) causes _dev_ipdhcp6_set_dhcp_level() to early-return at line 12039 when NDisc reports the same DHCP level from the RA, so the DHCPv6 client
is never recreated and the stale l3cd with DNS data persists permanently. IPv4 is unaffected because DHCPv4 is restarted directly from stage3 and passes .previous_lease to the client config, which triggers the
merge flags refresh path.
Also this happens just on reapply, cycling the connections with up and down has no issue.