Unexpected DDNS name removal.

[Gregory Sloop]

I've got a pretty weird situation here.

I have some Canon MFC's (MF1643i, if it matters)

We have a half a dozen or so.
They have a pretty odd relationship with the DHCP servers.

They'll get an IP fine, and stay up for days, but then suddenly they'll simply fail to renew the IP and get a 169 address. There's a setting in the network control panel to turn off "Auto IP" which appears to be a "feature" that might do this.

I've turned it off on a few, but I can't tell if that's fixed anything - since it only happens occasionally.
 
But that's not the real question. I only mention this because it might have bearing on another issue.

Along with the DHCP reservation (via a class statement that puts these printers in a specific pool/address-space) - I also have dhcpd creating DDNS records for them. We point print clients at the FQDN of the printer. 

(I won't get into why we like having the printers on DHCP, but there are some nice advantages.)

However, what I'm seeing now is that the printer will renew the lease at the 50% mark, and in the logs I see it request and ACK the lease renewal, but then there's an immediate DDNS forward map removal.

Here's some lightly sanitized logs. (The logs are from the syslog server, so you're seeing logs from both DHCP servers, not just one; we run a failover/balance DHCP pair.)

You can see the "start" of one of these events. The forward map is removed. 
(And obviously, if we're printing to this printer with the FQDN this because a big problem.)
 
I have a monitor on this printer currently, so I notice it went down, and can't do name resolution.
It's still got an IP and I can still talk to it via the IP.
So, I simply force the printer to re-start.
AFAICT, DHCP still thinks it's got an active lease. (Born out my the reuse_lease message.)

It goes about doing a discovery gets an offer ACKS the lease, and re-creates the forward map for my FQDN.
The lease is 8H, BTW.

So, at 4H it renews, but then for some reason DHCPD removes the forward again. (Though DHCP shouldn't remove the forward until the client explicitly releases the lease, or fails to renew in 8H.)

Jun 24 13:46:27 my-dns-dhcp-2 dhcpd[721]: Removed forward map from my-scanner-scan.mydom.local to 10.8.28.83
Jun 24 13:57:56 my-dns-dhcp-1 dhcpd[13147]: DHCPDISCOVER from 74:bf:c0:11:22:33 (my-scanner-scan) via 10.8.28.1: load balance to peer dhcp-failover
Jun 24 13:57:56 my-dns-dhcp-2 dhcpd[721]: reuse_lease: lease age 689 (secs) under 25% threshold, reply with unaltered, existing lease for 10.8.28.83
Jun 24 13:57:56 my-dns-dhcp-2 dhcpd[721]: DHCPDISCOVER from 74:bf:c0:11:22:33 via 10.8.28.1
Jun 24 13:57:57 my-dns-dhcp-2 dhcpd[721]: DHCPOFFER on 10.8.28.83 to 74:bf:c0:11:22:33 via 10.8.28.1
Jun 24 13:57:57 my-dns-dhcp-1 dhcpd[13147]: DHCPREQUEST for 10.8.28.83 (10.8.20.6) from 74:bf:c0:11:22:33 (my-scanner-scan) via 10.8.28.1
Jun 24 13:57:57 my-dns-dhcp-1 dhcpd[13147]: DHCPACK on 10.8.28.83 to 74:bf:c0:11:22:33 (my-scanner-scan) via 10.8.28.1
Jun 24 13:57:57 my-dns-dhcp-2 dhcpd[721]: DHCPREQUEST for 10.8.28.83 (10.8.20.6) from 74:bf:c0:11:22:33 via 10.8.28.1
Jun 24 13:57:57 my-dns-dhcp-2 dhcpd[721]: DHCPACK on 10.8.28.83 to 74:bf:c0:11:22:33 (my-scanner-scan) via 10.8.28.1
Jun 24 13:57:57 my-dns-dhcp-2 dhcpd[721]: bind update on 10.8.28.83 from dhcp-failover rejected: incoming update is less critical than outgoing update
Jun 24 13:57:57 my-dns-dhcp-1 dhcpd[13147]: Added new forward map from my-scanner-scan.mydom.local to 10.8.28.83
Jun 24 13:57:57 my-dns-dhcp-2 dhcpd[721]: Added new forward map from my-scanner-scan.mydom.local to 10.8.28.83
Jun 24 17:57:57 my-dns-dhcp-2 dhcpd[721]: DHCPREQUEST for 10.8.28.83 from 74:bf:c0:11:22:33 (my-scanner-scan) via eth1
Jun 24 17:57:57 my-dns-dhcp-2 dhcpd[721]: DHCPACK on 10.8.28.83 to 74:bf:c0:11:22:33 via eth1
Jun 24 17:57:57 my-dns-dhcp-2 dhcpd[721]: Removed forward map from my-scanner-scan.mydom.local to 10.8.28.83

---
Since this isn't happening for any other clients in the network, and no other make/model of printers, I assume the printer must be doing something that provokes it. But I have no idea how to stop it, what's wrong etc.

And it doesn't happen all the time for all these Canon printers. Just some, some of the time.
Gak!

Yeah, probably packet caps are the best option, but when it's sporadic, that's kind of hard to do.
I guess I'm here asking "Has anyone seen anything like this, before? And if so, what kinds of things might be the culprit."

[Hey, at least it accepts a lease < 1Y, eh Simon!?! :) ]
 
TIA
-Greg
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220624/ac31f6f5/attachment.htm>