ddns-fwd-name using the wrong name

[Rob Moser]

Hi All,

Short Version:

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?

More Details:

I can see the DHCP server making updates in it's logs, and see the updates taking place successfully in the named logs on the other end. It's updating, it's just using the wrong name. From our dhcpd.leases file on one of the DHCP servers:

lease <ip address> {  
  starts 5 2018/02/02 18:54:43;
  ends 6 2018/02/03 02:54:43;
  tstp 6 2018/02/03 06:54:43;
  tsfp 6 2018/02/03 06:54:43;
  atsfp 6 2018/02/03 06:54:43;
  cltt 5 2018/02/02 18:54:43;
  binding state active;
  next binding state expired;
  hardware ethernet 18:03:73:41:33:5b;
  uid "\001\030\003sA3[";
  set ddns-fwd-name = "MATH222-20.math.our.domain";
  set ddns-txt = "REDACTED";
  set ddns-rev-name = "<reverse ip>.in-addr.arpa.";
  client-hostname "math133-01";
}

You can see that the client hostname is correctly identified as math133-01, but ddns-fwd-name gets set to "MATH222-20.math.our.domain". Apparently this machine did have that hostname at some point in the past, before being re-imaged and re-named, so I got them to do a release and renew, just in case it was somehow still carrying an old lease, and I observed in the logs that it went through the full RELEASE/DISCOVER cycle. No change.

The MATH222-20 host does not have a host entry in our dhcpd configs. The math133-01 has the following entry:

host math133-01.math.our.domain-dynamic {
     hardware ethernet 18:03:73:41:33:5b;
     ddns-hostname "math133-01";
     ddns-domainname "math.our.domain";
     option host-name "math133-01";
     option domain-name "math.our.domain";
}

The zone config for math.our.domain has nothing but the (correct) ip of the DNS server, and the key. I've grepped our entire DHCP config tree for any specific mention of MATH220-20, and found nothing.

Any ideas where dhcpd might be getting this old out-of-date value for ddns-fwd-name? Thanks for any help,

 - rob.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Rob Moser <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Rob Moser]

Simon Hobson <[hidden email]> wrote:
> Rob Moser <[hidden email]> 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.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Rob Moser <[hidden email]> wrote:

> 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?

Does one have a client-id and the other not have one ? If so, then they would be considered different clients (did they get different addresses) and the old lease could stay around for a long time. But then the DHCP server should not be applying that lease to the host in question.

But then, that lease entry doesn't look like anything I've seen, so rather a case of "I dunno" - sorry.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[glenn.satchell]

On Fri, February 9, 2018 7:31 am, Simon Hobson wrote:

> Rob Moser <[hidden email]> wrote:
>
>> 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?
>
> Does one have a client-id and the other not have one ? If so, then they
> would be considered different clients (did they get different addresses)
> and the old lease could stay around for a long time. But then the DHCP
> server should not be applying that lease to the host in question.
>
> But then, that lease entry doesn't look like anything I've seen, so rather
> a case of "I dunno" - sorry.
>

The "dynamic;" entry marks it as something added using OMAPI, ie by
omshell. Is is possible that this was done sometime in the past?

regards,
-glenn


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users