Bug 1269093

Proper DUID management is necessary for IPv4 and IPv6 automatic configuration.

I can confirm that this causes complete DNS corruption on my system
This must be a serious problem!
NetworkManager-1.0.10-2.fc23.x86_64
dhcp-client-4.3.3-8.P1.fc23.x86_64
paxos 4.3.3-301.fc23.x86_64

It does NOT occur on a NON updated F23 system
NetworkManager-1.0.6-8.fc23.x86_64
dhcp-client-4.3.3-7.fc23.x86_64
naxos 4.2.8-300.fc23.x86_64

From a "clean" start of dhcp/ddns on a Centos6.7 server the first boot
of a F23 client machine (presumably the first use of NetworkManager)
obtains an IP address and updates the DNS as expected.

Subsequent "systemctl restart NetworkManager.service" on the client,
or "reboots" of the client
or "natural" requests for lease renewal from the client
obtains a new IP address but does not/cannot update the DNS RRs

Should DHCPDISCOVER be issued for a lease renewal request ????

First boot
Jan 25 15:05:02 maui dhcpd: DHCPDISCOVER from 78:24:af:3a:7e:3a via eth0
Jan 25 15:05:03 maui dhcpd: DHCPOFFER on 148.197.29.129 to 78:24:af:3a:7e:3a (paxos) via eth0
Jan 25 15:05:03 maui named[2188]: client 148.197.29.5#44594: updating zone 'jaa.org.uk/IN': adding an RR at 'paxos.jaa.org.uk' A
Jan 25 15:05:03 maui named[2188]: client 148.197.29.5#44594: updating zone 'jaa.org.uk/IN': adding an RR at 'paxos.jaa.org.uk' TXT
Jan 25 15:05:03 maui dhcpd: Added new forward map from paxos.jaa.org.uk to 148.197.29.129
Jan 25 15:05:03 maui named[2188]: client 148.197.29.5#43414: updating zone '29.197.148.in-addr.arpa/IN': deleting rrset at '129.29.197.148.in-addr.arpa' PTR
Jan 25 15:05:03 maui named[2188]: client 148.197.29.5#43414: updating zone '29.197.148.in-addr.arpa/IN': adding an RR at '129.29.197.148.in-addr.arpa' PTR
Jan 25 15:05:03 maui dhcpd: added reverse map from 129.29.197.148.in-addr.arpa. to paxos.jaa.org.uk
Jan 25 15:05:03 maui dhcpd: DHCPREQUEST for 148.197.29.129 (148.197.29.5) from 78:24:af:3a:7e:3a (paxos) via eth0
Jan 25 15:05:03 maui dhcpd: DHCPACK on 148.197.29.129 to 78:24:af:3a:7e:3a (paxos) via eth0

Subsequent use of "systemctl restart NetworkManager.service", reboot, ...
 
Jan 25 15:42:32 maui dhcpd: DHCPDISCOVER from 78:24:af:3a:7e:3a via eth0
Jan 25 15:42:33 maui dhcpd: DHCPOFFER on 148.197.29.130 to 78:24:af:3a:7e:3a (paxos) via eth0
Jan 25 15:42:33 maui named[2188]: client 148.197.29.5#44704: updating zone 'jaa.org.uk/IN': update unsuccessful: paxos.jaa.org.uk: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Jan 25 15:42:33 maui named[2188]: client 148.197.29.5#42468: updating zone 'jaa.org.uk/IN': update unsuccessful: paxos.jaa.org.uk/TXT: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Jan 25 15:42:33 maui dhcpd: Forward map from paxos.jaa.org.uk to 148.197.29.130 FAILED: Has an address record but no DHCID, not mine.
Jan 25 15:42:33 maui dhcpd: DHCPREQUEST for 148.197.29.130 (148.197.29.5) from 78:24:af:3a:7e:3a (paxos) via eth0
Jan 25 15:42:33 maui dhcpd: DHCPACK on 148.197.29.130 to 78:24:af:3a:7e:3a (paxos) via eth0

and again
Jan 25 15:43:33 maui dhcpd: DHCPDISCOVER from 78:24:af:3a:7e:3a via eth0
Jan 25 15:43:34 maui dhcpd: DHCPOFFER on 148.197.29.131 to 78:24:af:3a:7e:3a (paxos) via eth0
Jan 25 15:43:34 maui named[2188]: client 148.197.29.5#44059: updating zone 'jaa.org.uk/IN': update unsuccessful: paxos.jaa.org.uk: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Jan 25 15:43:34 maui named[2188]: client 148.197.29.5#33780: updating zone 'jaa.org.uk/IN': update unsuccessful: paxos.jaa.org.uk/TXT: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Jan 25 15:43:34 maui dhcpd: Forward map from paxos.jaa.org.uk to 148.197.29.131 FAILED: Has an address record but no DHCID, not mine.
Jan 25 15:43:34 maui dhcpd: DHCPREQUEST for 148.197.29.131 (148.197.29.5) from 78:24:af:3a:7e:3a (paxos) via eth0
Jan 25 15:43:34 maui dhcpd: DHCPACK on 148.197.29.131 to 78:24:af:3a:7e:3a (paxos) via eth0

Investigation shows that dhclient is using a different lease file with a different value for default-duid when NetworkManager has been restarted,
First boot
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-eno1.pid \
-lf /var/lib/NetworkManager/dhclient-37107b25-12bf-4de0-935e-12b9b6062fb4-eno1.lease \
-cf /var/lib/NetworkManager/dhclient-eno1.conf eno1
...
default-duid "\000\001\000\001\0368\255;x$\257:~:";

Subsequent update, reboot, ...
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-eno1.pid -lf \
/var/lib/NetworkManager/dhclient-81ded380-936a-405c-83f2-bfd5b980f69d-eno1.lease \
-cf /var/lib/NetworkManager/dhclient-eno1.conf eno1
...
default-duid "\000\001\000\001\0368\264\335x$\257:~:";

The root cause of the issue here is that there is no permanent connection profile for the interface, and therefore all information (including the DHCP lease) is thrown away each time NM restarts.  If there was a permanent connection profile, this would not occur since the existing lease would be save and thus available for renewal when NM starts again.

Something like:

nmcli con mod eno1 connection.autoconnect no
nmcli con mod eno1 connection.autoconnect yes

will cause NM to write the connection out to disk as it has been explicitly modified by the user.

The DUID is only used for DHCPv6 and thus isn't relevant to the problem here, but it shouldn't be changing as long as /etc/machine-id or /var/lib/dbus/machine-id is present.

DUID is used also with IPv4. It is an optional field and when it is present it typically superseedes MAC address, so this is very much relevant for IPv4 and is actually causing operational problems.

Many thanks for the prompt feedback

I have tested out the use of the two commands
nmcli con mod eno1 connection.autoconnect no
nmcli con mod eno1 connection.autoconnect yes
and by magic the client no longer issues DHCPDISCOVER
every time NetworkManager is restarted and hence does not
request and obtain a new IP address.

I also checked what happened when the leases ran out naturally by
setting "default-lease-time  300;" in
dhcpd.conf on the server

Again all was well

I have not yet worked out how often the magic incantation
is required - once after a new installation or once
before the lease runs out or ... ??????????????????????

Should NetworkManager default to creating a "permanent connection profile"?

Aside:
I suspect that originally the client may not have been
deleting the old IP address from the interface but was adding
the new IP as a "secondary".
At one stage during testing "ip a s" gave multiple entries
of the form
inet 148.197.29.133/24 brd 148.197.29.255 scope global dynamic eno1             


This might explain my original symptoms - after several days the client
and server would both freeze with the network busily flashing away.
The only way out was to press the button on all machines.
I originally thought it was a hardware problem but now suspect
that NetworkManager may have been the cause of the crashes.
At least my machines, router, switches, cables, ...
have all been cleaned and dusted!

The problem is affecting me, too. My Fedora VMs don't retain their IPv4 addresses.

Have you by any chanced "cloned" your virtual machines?

I now think that maybe my problems were to do with the way I cloned my particular client (hardware) machines.

I used a variation of
Create a valid F23 master machine/SSD and dump it whilst unmounted
...
dump 0f /mnt/zip/F22_dump_2015_06_22 /dev/sdb5
...
Restore to the disk/SSD of another machine
restore -rf /mnt/zip/F22_dump_2015_06_22
(This took less than 120s)
...
mount /dev/sda6 /mnt/zip
mount -o bind /dev  /mnt/zip/dev
mount -o bind /proc /mnt/zip/proc
mount -o bind /sys  /mnt/zip/sys
chroot /mnt/zip
gedit /etc/fstab
gedit /etc/hostname
Sort out grub2

I used to
gedit /etc/sysconfig/network-scripts/ifcfg-eno1
but recently I have been lazy and let
NM "sort it out" - for F23 I think it/I didn't get it quite right!

Adding an extra "mount -o bind /run /mnt/zip/run" to the list above
lets me use nmcli in the chroot environment but it is not quite
clear to me exactly what to do at that stage!

I was hit by this bug as well.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.