This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 177963 - dhcpd omits domainname when sending dynamic dns update
dhcpd omits domainname when sending dynamic dns update
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: dhcp (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
: Regression
Depends On: 176615
Blocks: 168430
  Show dependency treegraph
Reported: 2006-01-16 16:43 EST by Jason Vas Dias
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2006-0114
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-07 13:16:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jason Vas Dias 2006-01-16 16:43:30 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
Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

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
find it.

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

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

How reproducible:

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 timed out

zonefiles on dns-server has no records for BOOLE

Expected Results:  logfile should show:
Added new forward map from to
added reverse map from to

zonefiles on dns-server should have forward and reverse records for BOOLE

Additional info:

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 on 2005-12-27 12:27 EST --
Created an attachment (id=122601)
logfile showing good and bad behaviour

-- Additional comment from 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 \
    >/tmp/dhcp.tcpdump.log 2>&1
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 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
removal issue.

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 - 
thank you.

-- Additional comment from 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 on 2006-01-14 12:46 EST --
Created an attachment (id=123200)
tcpdump of dhcp client/server communication

-- Additional comment from on 2006-01-14 12:47 EST --
Created an attachment (id=123201)
(stripped) dhcpd.conf

-- Additional comment from on 2006-01-14 12:53 EST --
Problem still persists with dhcp-3.0.2-28.FC4.
please note:
-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 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 to the dns.

-- Additional comment from 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 .
Comment 1 Jason Vas Dias 2006-01-16 16:47:53 EST
This bug is also upstream in ISC DHCP 3.0.4b2 .

Fixed with dhcp-3.0.1-54.EL4 - patch sent upstream .
Comment 6 Red Hat Bugzilla 2006-03-07 13:16:24 EST
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.

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