Bug 147007 - dhclient - send host-name - no longer updates dns
dhclient - send host-name - no longer updates dns
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dhcp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Depends On:
  Show dependency treegraph
Reported: 2005-02-03 12:01 EST by Rod Rioux
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-03 14:50:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
log with the old version (5.00 KB, text/plain)
2005-02-03 16:10 EST, Rod Rioux
no flags Details
new package log (5.00 KB, text/plain)
2005-02-03 16:11 EST, Rod Rioux
no flags Details

  None (edit)
Description Rod Rioux 2005-02-03 12:01:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; 
Q312461; .NET CLR 1.0.3705; .NET CLR 1.1.4322)

Description of problem:
a simple conf file that I have been using in all versions of AS3 and 
AS3UPDATEX to update dns now does not work with update 4.

send host-name "servername.my.domain.com";

All other verions this works beautifully...

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install update 4
2.add send host-name "servername.my.domain.com"; to /etc/dhclient-
3. /etc/init.d/network restart

Actual Results:  Dns doesnt get updated.

Expected Results:  Dns should get updated.

Additional info:

So to check to make sure i wasnt on crack i:
rpm -e dhclient
rpm -ivh dhclient-3.0pl2-6.14.i386.rpm (from AS3 iso - no updates)
/etc/init.d/network restart

and by the time i could time ping "hostname.domain.com" it had 
updated dns and works perfectly.
Comment 1 Jason Vas Dias 2005-02-03 14:50:31 EST
I have now tested this and verified that the behaviour of 
dhclient-3.0.1-10_EL3 is actually IDENTICAL to that of 
dhclient-3.0pl2-6.14 in this regard - both versions
generate identical DHCP packets , as can be seen by doing
a tcpdump:
  # tcpdump -nl -vvv -i eth0 -s 2048 port bootpc or port bootps 2>&1 |
tee /tmp/tcpdump.log

The  "ddns-update-style ad-hoc;" that your DHCP server is using
is broken, deprecated and unlikely to be supported in future 
DHCP releases, as is stated in the dhcpd.conf(5) man page - 
read the sections on DDNS .

The behaviour of the "ad-hoc" update style can be very confusing:
ONLY if the lease has expired, and the client does not send a 
"requested IP address" option in the DHCPREQUEST packet, does 
the server generate a DNS update in ad-hoc mode .

Thus, with both dhclient versions, if the
/var/lib/dhcp/dhclient-eth0.leases file contains an unexpired lease,
and the client renews the lease by sending a requested IP in the
DHCPREQUEST, the server will generate no DNS update. 

If you get the client to release any unexpired leases with the 
   # dhclient -r -pf /var/run/dhclient-eth0.pid -lf \   
and THEN do:
   # ifdown; ifup
OR # dhclient  -pf /var/run/dhclient-eth0.pid -lf \   
        /var/lib/dhcp/dhclient-eth0.leases eth0
then the server will generate the DNS updates with either 
version of dhclient - both 3.0.1-10_EL3 and 3.0pl2-6.14 .

So this seemed like a problem because you must have updated DHCP
before the lease has expired and the server did not generate any

The best way to remedy this situation is to use the 
  'ddns-update-style interim;'
in the server, and change dhclient.conf to contain:
  'send option fqdn.fqdn "servername.my.domain.com";'
Then the server will update DNS much more intelligently: on every
postive DHCPACK, the server will check if the 'A' and 'PTR' 
records exist and create them if necessary. The 'interim' method
is compliant with all current DDNS RFCs and standards, and will 
be fully supported in future DHCP versions. Also, with this method
you can tell the client to do the forward DNS update. 

If you have further problems with this please run the tcpdump command
above while reproducing the problem and append the /tmp/tcpdump.log
to this bug - please also include information on what version of the
DHCP server and the dhcpd.conf you are using - thank you.

Comment 2 Rod Rioux 2005-02-03 16:10:39 EST
Created attachment 110623 [details]
log with the old version
Comment 3 Rod Rioux 2005-02-03 16:11:15 EST
Created attachment 110624 [details]
new package log
Comment 4 Rod Rioux 2005-02-03 16:12:51 EST
The dhcp server is a windows machine.
I have tried the release and renew as you specified above with no 
luck... but again the older package works immediately.
Comment 5 Jason Vas Dias 2005-02-03 18:24:33 EST
This is very strange. 

The logs show that both dhclient versions are sending IDENTICAL
packets (except for timestamps / transaction IDs).

The two packet traces differ only in that in the new version trace,
DHCP server .2 makes an OFFER before .3, while in the old version
trace, DHCP server .3 makes an OFFER before .2 - the two dhclient
versions may have slightly different timing characterstics, but 
their behaviour and generated packets are the same.

Verify that the DNS server allows updates from either DHCP server .

What DNS server are you using ? It would be interesting to see the
DNS server event logs during the times these traces were taken .

Can you duplicate the problem when only one DHCP server is responding?

Comment 6 Rod Rioux 2005-02-07 16:31:08 EST
we have 2 identical windows machines for redundancy.. the only thing 
else that i can think of is that we also use cisco ip-helper to 
forward the requests to the dhcp machines.

Comment 7 Jason Vas Dias 2005-02-07 17:17:36 EST
And DNS runs on both windows machines ? 
Are you using ISC BIND or MS-DNS ?
I know ISC BIND creates log entries for each DNS update request -
I think MS-DNS can be configured to do so as well .
Are both DNS servers configured to accept DNS updates from both
DHCP servers ?

Are there any DNS or DHCP server event log entries for the times 
the packet traces were collected and the problem reproduced ?
They would be most useful to append to this bug.

As I said in the previous comment, the packets generated by the two
versions of dhclient appear to be IDENTICAL , so that would suggest
that a component other than dhclient is the cause of this problem. 

For the old dhclient version trace, the client gets its first OFFER 
from the .2 DHCP server , and in the new dhclient version trace, the
.3 DHCP server responds first . 

Please can you retry the tcpdump with the two versions using this
exact tcpdump command, if you did not use it to generate the 
previous trace:

# tcpdump -nl -vvv -i eth0 -s 2048 port bootpc or port bootps 2>&1 |
tee /tmp/tcpdump.log

If you did use it to produce the previous trace, please check that
you have tcpdump version 3.7.2-7+ installed, and install it if not.

The '-vvv' option makes tcpdump actually print out the option values -
eg. it will show the values of the 'host-name' options sent, assuming
you have tcpdump version 3.7.2-7 . Perhaps when all the DHCP options
are printed out the packets will not be identical - I know both
versions produce identical packets on the RHEL-3 system I've been
testing on, with 'send host-name' in /etc/dhclient.conf, using the
tcpdump command above.   


Note You need to log in before you can comment on or make changes to this bug.