Red Hat Bugzilla – Bug 177963
dhcpd omits domainname when sending dynamic dns update
Last modified: 2007-11-30 17:07:22 EST
+++ This bug was initially created as a clone of Bug #176615 +++
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922
Description of problem:
between dhcp-3.0.2-22 and dhcp-3.0.2-24 some code was moved around and i think
this had an undesired side-effect. i tried to find the exact spot, but couldn't
The release notes say:
>"append"ing a string onto the end of a "t" type option (such as the
>domain-name field) that had been improperly NULL-terminated by the
>DHCP server will no longer result in a truncated string containing
>only the option from the server, and not the expected appended value.
For me it has the opposite effect.
See the attached logfile.
Notice how 3.0.2-24 says only BOOLE while 3.0.2-22 says BOOLE.creaholic.com.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set up a dhcp-server for dynamic dns updates
2. have a nt-client
3. in a dos-shell release ip ("ipconfig /release")
4. in a dos-shell renew ip ("ipconfig /renew")
Actual Results: logfile on dhcp-server shows error:
Unable to add forward map from BOOLE to 192.168.131.226: timed out
zonefiles on dns-server has no records for BOOLE
Expected Results: logfile should show:
Added new forward map from BOOLE.creaholic.com. to 192.168.131.226
added reverse map from 220.127.116.11.in-addr.arpa. to BOOLE.creaholic.com.
zonefiles on dns-server should have forward and reverse records for BOOLE
notice in attached logfile how it uses the fqdn to remove the dns-records, but
uses the hostname without domainname to add dns-records.
-- Additional comment from email@example.com on 2005-12-27 12:27 EST --
Created an attachment (id=122601)
logfile showing good and bad behaviour
-- Additional comment from firstname.lastname@example.org on 2006-01-09 13:55 EST --
I'm investigating this now.
Did you try the latest dhcp-3.0.2-28.FC4 release now in updates/testing
(and being moved to updates/final today) ? This release has the complete
upstream patch for the null termination issue.
It would also be most helpful if you could gather a tcpdump of the server/client
traffic on the server:
# tcpdump -nl -i any -vvv -s 4096 -X port bootps or port bootpc \
Then boot the client, duplicating the problem, 'pkill tcpdump', and append
the /tmp/dhcp.tcpdump.log contents to this bug report - thank you.
-- Additional comment from email@example.com on 2006-01-09 16:49 EST --
I cannot reproduce this issue with dhcp-3.0.2-28.FC4, or with dhcp-3.0.1-52.EL4
in RHEL-4, both of which have the latest upstream fix for the trailing NUL
I was using a Windows-XP-Professional client, which had the option
"Register this connection's addresses in DNS" checked (selected) in the
"DNS" tab of the "Advanced TCP/IP Settings" dialog, reached by clicking on
the "Advanced" button of the "Internet Protocol (TCP/IP) Properties" dialog
of the "Local Area Connection Properties" dialog.
NOTE: Windows has several options regarding DDNS updates :
o "Append primary and connection specific DNS suffixes" -
The "connection specific DNS suffix" comes from the DHCP 'domain-name'
option, and is listed in the 'ipconfig' output.
The "primary" suffix is the suffix of the primary DNS server (which may
or may not be in the DHCP 'domain-name-servers' option).
o "Append these DNS suffixes" -
A list of domain name suffixes to update can be specified explicitly.
o "DNS suffix for this connection" -
A DNS suffix can be explicitly specified for the connection.
Note also that the dhcp server can request the client to do the DNS updates
by sending the a 'fqdn.server-update' value of 0 (false) ( or by setting the
'allow client-updates' option ) (but I'm not sure how you'd tell windows about
the DNS zone keys).
If you still have problems with dhcp-3.0.2-28.FC4, please gather the tcpdump
output requested above, and send me it along with your dhcpd.conf file -
-- Additional comment from firstname.lastname@example.org on 2006-01-13 11:14 EST --
Can you reproduce this problem with dhcp-3.0.2-28.FC4 ? I've not been able to.
If you can, please send me the tcpdump and dhcpd.conf data requested above,
and re-open this bug - thank you.
-- Additional comment from email@example.com on 2006-01-14 12:46 EST --
Created an attachment (id=123200)
tcpdump of dhcp client/server communication
-- Additional comment from firstname.lastname@example.org on 2006-01-14 12:47 EST --
Created an attachment (id=123201)
-- Additional comment from email@example.com on 2006-01-14 12:53 EST --
Problem still persists with dhcp-3.0.2-28.FC4.
-dhcp-client ist windows nt (not xp)
-dhcp-server is set to do the ddns-update.
-the dhcp-client doesn't know anything about ddns.
-- Additional comment from firstname.lastname@example.org on 2006-01-14 12:58 EST --
Created an attachment (id=123202)
tcpdump of dhcp-server to dns-server traffic
note how dhcpd sends only TAYLOR not taylor.creaholic.com to the dns.
-- Additional comment from email@example.com on 2006-01-16 16:32 EST --
Many thanks for appending the client->server dhcp traffic - I've found and
fixed the problem now.
This bug is fixed with dhcp-3.0.2-30.FC4, to be release to FC-4/Updates/Testing
today, and dhcp-3.0.3-20.FC5 in Rawhide.
Please try out the new version and let me know of any issues - thanks .
This bug is also upstream in ISC DHCP 3.0.4b2 .
Fixed with dhcp-3.0.1-54.EL4 - patch sent upstream .
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.