Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-149149

ipv6.ignore-auto-dns=yes fails to suppress DHCPv6 DNS after reapply

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • rhel-9.6.z
    • NetworkManager
    • None
    • None
    • None
    • rhel-net-mgmt
    • None
    • False
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • Hide

      Definition of Done:

      Please mark each item below with ( / ) if completed or ( x ) if incomplete:

      ( ) The acceptance criteria defined below are met.

      Given a NetworkManager-managed interface eth0 with ipv6.method=auto that has received a DHCPv6 DNS server (e.g., fd00::1) confirmed visible in nmcli device show eth0 | grep IP6.DNS,

      When ipv6.ignore-auto-dns=yes is set via nmcli connection modify and nmcli device reapply eth0 is executed,

      Then IP6.DNS is empty in nmcli device show eth0 output and the DHCPv6-provided DNS server no longer appears in the resolver configuration. Overall, the behavior matches that of ipv4.ignore-auto-dns=yes on reapply without requiring a connection down/up cycle


      ( ) Integration test case is available upstream.


      ( ) Code is reviewed and merged upstream.


      ( ) Preliminary testing is done.


      ( ) Upstream documentation is written in the upstream MR.


      ( ) Release notes text is written in the RHEL issue.


      ( ) A demo is recorded

      Show
      Definition of Done: Please mark each item below with ( / ) if completed or ( x ) if incomplete: ( ) The acceptance criteria defined below are met. Given a NetworkManager-managed interface eth0 with ipv6.method=auto that has received a DHCPv6 DNS server (e.g., fd00::1) confirmed visible in nmcli device show eth0 | grep IP6.DNS, When ipv6.ignore-auto-dns=yes is set via nmcli connection modify and nmcli device reapply eth0 is executed, Then IP6.DNS is empty in nmcli device show eth0 output and the DHCPv6-provided DNS server no longer appears in the resolver configuration. Overall, the behavior matches that of ipv4.ignore-auto-dns=yes on reapply without requiring a connection down/up cycle ( ) Integration test case is available upstream. ( ) Code is reviewed and merged upstream. ( ) Preliminary testing is done. ( ) Upstream documentation is written in the upstream MR. ( ) Release notes text is written in the RHEL issue. ( ) A demo is recorded
    • 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.

       

              nm-team Network Management Team
              ellorent Felix Enrique Llorente Pastora
              Network Management Team Network Management Team
              Vladimir Benes Vladimir Benes
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: