ddns-fwd-name using the wrong name

[Rob Moser]

Simon Hobson <dhcp1 at thehobsons.co.uk> wrote:
> Rob Moser <Rob.Moser at nau.edu> wrote:
> 
> > In most cases our DDNS setup works fine, but an issue has come up where for some of our hosts the DHCP server seems to pick the wrong ddns-fwd-name to send in the updates to DNS. How does dhcpd determine what name to use?
> ...
> > Any ideas where dhcpd might be getting this old out-of-date value for ddns-fwd-name? Thanks for any help,
> 
> My guess is that it's persisting with the one in the leases file rather than re-evaluating the value every time it deals with the client.
> Simple test for that is to configure a client, change it's hostname, see if it does the same - then stop the DHCP server and delete the ddns-forward-hostname entry in it's lease (only the last entry in the file matters) before restarting the DHCP server.

I think you're right, and I think I know why.

As often seems to be the case, the act of writing my problem up sparked another few ideas for me to try.  Because I came at this from an original DNS problem, I was focussed on the name, but since I've now worked out the name is coming from DHCP, I really should be tracking things by MAC address...

Sure enough, there is another entry in my dhcp.leases file for the MAC in question, and it looks like:

host MATH222-20.math.our.domain-dynamic {
  dynamic;
  hardware ethernet 18:03:73:41:33:5b;
        supersede server.ddns-hostname = "MATH222-20";
        supersede server.ddns-domainname = "math.our.domain";
        supersede host-name = "";
        supersede domain-name = "math.our.domain";
}

So clearly _that_ is where the obsolete name comes from.  But that just kicks the can down the road a ways; where did that entry in my leases file come from, if there are no equivalent entries in my dhcpd.conf files?  Could the old value still be coming from the client somehow?  (The only definition I could find for the "supersede" clause was in the dhclient.conf man pages....)  Or have come from the client back when it legitimately had the old name, and is not getting overwritten by the new one for some reason?  I grabbed a tcpdump of traffic from the system during a renew, and I can't see any sign of the hostname (but I wasn't able to force a release first, so it wasn't a full discover-cycle.)

Thanks for the help,

     - rob.