DHCP Issue ------------------ Jay: Advise on how client may or may not request updates to DDNS. Xander: Report on status of current changes (fix applied today) ---------- Note from Jay: The dhclient/dns information I said I would forward during the call this morning. dhclient.conf can be configured to send: dhcp-lease-time - allow the client to request a lease time for the IP address As for the dynamic updates stuff, it appears that you'll need to include something like the following as well: send fqdn.fqdn "grosse.fugue.com."; send fqdn.encoded on; send fqdn.server-update on; Of course, substituting where appropriate. Give that a whirl and see if things work out a little better for you. - jkt ------------------------------------- From Xander: Jay, We had something similar to that in our previous setup and it didn't work. Now we're using a simple: send host-name "rijkes-n-d00010"; in the configuration file. We're still waiting for the scavenging to kick in for this host. I'll let you know if anything changes. We've had conflicting advice regarding the client doing updates or registering itself. One thing we have not tried so far is letting the DHCP server register the client and having the client doing the updates. One problem with the fqdn is that we don't know it when the machine starts. The fqdn is very much dependant on the site the computer is in. Sometimes it could be rijvol.europe.shell.com, sometimes europe.shell.com or even hou-btc.americas.shell.com. How would I use the fqdn.fqdn parameter then? Gr, Xander --------------------------------- From Xander... A little update on this. The host in question has refused to drop out of DNS, despite it being more than 2 days since the initial registering. The client's config consists of a mere: send host-name "rijkes-n-d000010" So either the scavenging is selective or it's only once a day. Will keep you posted. Gr, Xander
Waiting on customer to determine if configuration changes clear up the premature aging problems. Red Hat believes this is fixed.
Prior to initscripts-7.67, dhclient will only use the per-interface /etc/dhclient-${interface}.conf (eg dhclient-eth0.conf) not /etc/dhclient.conf. The 'send host-name "rijkes-n-d000010"' will result in a server DDNS update only if the deprecated 'ddns-update-style ad hoc' (not the default 'ddns-update-style interim') option is defined in the server's /etc/dhcpd.conf. The 'send fqdn.server-update on;' will disable ddns client update. DHCP client DDNS update may be disabled in DHCP releases between 3.0pl2 and 3.0.1rc14 due to a dhclient bug that was fixed in dhcp-3.0.1-7 (bug 129646) : I have got DDNS update working with a dhcp-3.0pl2 server and client. In the server, I use options: -- ddns-update-style interim; ... option domain-name-servers xxx.xxx.xxx.xxx; send fqdn.server-update off; send fqdn.no-client-update off; -- In the client /etc/dhclient-${IF}.conf, I use only options: -- send fqdn.fqdn "myhost.mydomain."; send fqdn.server-update off; -- DDNS entries are removed only after the lease expires and the client does not renew or the lease is abandoned.
I should have added that the DDNS entries are removed only if 'ddns-update-style interim' - the fact that they are sending only 'send host-name "rijkes-n-d000010"' means they must be using 'ddns-update-style ad-hoc', which does not remove the DDNS entries on expiry. Also all dhcp releases from dhcp-3.0.1rc9 (release candidate) to dhcp-3.0.1 (released) had the ddns client update disabled. What is the status of this bug ? It seems to be a misconfiguration problem. Will close as 'NOTABUG' if more information is not forthcoming.