Bug 129646 - dhclient not updating DNS FQDN correctly
Summary: dhclient not updating DNS FQDN correctly
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dhcpcd
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-11 13:13 UTC by Tony Davalos
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-08-16 19:46:16 UTC
Target Upstream Version:

Attachments (Terms of Use)
tcpdump of dhclient eth0 (6.23 KB, text/plain)
2004-08-12 19:27 UTC, Tony Davalos
no flags Details
New dump log (2.23 KB, text/plain)
2004-08-13 19:19 UTC, Tony Davalos
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:566 0 normal SHIPPED_LIVE Updated dhcp and dhclient packages 2005-05-26 04:00:00 UTC

Description Tony Davalos 2004-08-11 13:13:59 UTC
From Bugzilla Helper:

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7)

Description of problem:
When using a laptop configured with DHCP to obtain an IP address, the
dhcp client is not updating the ddns with the correct FQDN.
The situation is that we are post merger and have two separate domains
in play right now.  The old domain is the default, but the new domain
is available as well.
Our Windows environment uses only the old domain and the Windows
client will update the ddns to use not only the correct hostname but
also the correct domain name.  Our Linux clients only seem to update
the hostname and we cannot force any of the options below to modify
the domain to the new domain name.
I've put the entries in the following files to try to work around this:
send fqdn.fqdn "newhostname.newdomain.com."; # tried w/o trailing .
send fqdn.encoded on;
send fqdn.server-update on;
send host-name "newhostname"; tried FQDN here too
I've tried every variation of options that I can think of with no
success.  Based on my research and discussions with Tcomm, we're
looking for more info on the DHCP extension code 81 (option 81) which
should allow us to specify a client provided FQDN to the DNS.
I logged this with the component of dhcpcd because dhclient was not
listed and this was the closest component for dhcp clients.

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

How reproducible:

Steps to Reproduce:
1. Reset the hostname and domain name on leased IP address in DHCP
2. Put above changes on Linux client
3. Boot and review dns 

Actual Results:  The linux client will boot and get an IP address.  It
will also set the hostname correctly in DNS but the domain name will
not be modified correctly.

Expected Results:  I'd like to be able to change the hostname and the
domain name as our Windows XP clients.

Additional info:

Comment 1 Jason Vas Dias 2004-08-11 21:44:09 UTC
Try renaming your "/etc/dhclient" file quoted above to 
/etc/dhclient-eth0.conf - that's the config file passed
to dhclient by /sbin/ifup .

Comment 2 Tony Davalos 2004-08-11 22:01:32 UTC
Sorry, my mistake when entering the bug, the name of the file that I 
was testing with was actually /etc/dhclient-eth0.conf.

Comment 3 Jason Vas Dias 2004-08-12 00:13:59 UTC
I've been looking into the documentation on this.
 According to the relevant standard for dhcp option 81 (FQDN),
 which is at :
 (The earlier draft-ietf-dhc-fqdn-option-00.txt supported by
  dhcp-3.0pl2 has expired and is no longer available) 

   "clients which send the Client FQDN option in their messages
    MUST NOT also send the Host-Name option"
So try taking out the DHCP_HOSTNAME from ifcfg-eth0 (which must
be a hostname, not a FQDN). 

The fact that your clients are able to update the hostname portion
(only) suggests this may be the problem.

The server should be requesting that the client supply their FQDN
option; if they still do not, put ONLY the 
  'send fqdn.fqdn "newhostname.newdomain.com."'
line in the /etc/dhclient-eth0.conf file.

Note that the client's name must actually be
"newhostname.newdomain.com" - ensure this is so
by setting the 
in /etc/sysconfig/network-scripts/ifcfg-eth0 .

If it still fails, read on.

Also, in the dhclient.conf(5) manpage, it says: 
   "To make it work, you have to declare a key and  zone  as  
   in  the  DHCP server  (see  dhcpd.conf(5)  for details)"

This suggests to me that you must declare the correct zone 
and key data used by your DHCP server to update the DNS server
in your dhclient.conf.

The DYNAMIC DNS UPDATE SECURITY section of dhcpd.conf(5),
describes the zone and key declarations: 

      key DHCP_UPDATER {
         algorithm hmac-md5;
         secret pRP5FapFoJ95JEL06sv4PQ==;

       zone "example.org" {
            type master;
            file "example.org.db";
            allow-update { key DHCP_UPDATER; };

So, try copying the zone & key declarations from your DHCP server
to your dhclient-eth0.conf. 

If all the above still fails, please do the following, as root, on
an example client: 
       $ pkill dhclient;
       $ tcpdump -nl -i eth0 -vv -xx '(' port bootpc ')' or '(' port
bootps ')' > /tmp/tcpdump.log &
       $ dhclient eth0
       $ pkill tcpdump
and attach the resulting /tmp/tcpdump.log to this bug. 

Comment 4 Jason Vas Dias 2004-08-12 00:18:43 UTC
Sorry, if you have to do the tcpdump, please add the '-s 2048' option .

Comment 5 Jason Vas Dias 2004-08-12 00:28:46 UTC
Sorry, the lines above:
by setting the 
in /etc/sysconfig/network-scripts/ifcfg-eth0 .
should have been:
by setting the 
in /etc/sysconfig/network

Comment 6 Tony Davalos 2004-08-12 19:27:22 UTC
Created attachment 102669 [details]
tcpdump of dhclient eth0

This is the tcpdump of starting the dhclient

Comment 7 Tony Davalos 2004-08-12 19:29:04 UTC
I made the changes you requested.

I removed the DHCP_HOSTNAME from /etc/sysconfig/network-scripts/ifcfg-
eth0 and the HOSTNAME in /etc/sysconfig/network was already the fully 
qualified name.  I made the changes to /etc/dhclient-eth0.conf so 
that it now appears as:

zone "newdomain.net" {
        type slave;
        file "sec_qip\db.newdomain.net";
        masters {; };
        allow-update { any; };
        allow-transfer { any; };
send fqdn.fqdn "ho-mobilegeo1-x.newdomain.net."; 
send fqdn.encoded on; 
send fqdn.server-update on; 

I've attached the tcpdump.log that was generated at your request.


Comment 8 Jason Vas Dias 2004-08-12 20:24:15 UTC
Aha! It appears you must set :

    send fqdn.server-update off;

Looking at the source code, if this option is not set, 
the client will send no fqdn; if it is true (on) then
the server is expected to update DNS and the client
will send no fqdn; if false (off) then the client is 
expected to send a fqdn update. 
IE. this option means "the server will update DNS" -
not the client.

Try this /etc/dhclient-eth0.conf file:
   send fqdn.server-update off;
   send fqdn.fqdn "ho-mobilegeo1-x.newdomain.net";
   send fqdn.encoded on;

If this still doesn't work, try putting back in the "zone" declaration
, but remove the "file" line - presumably this refers to a file on
the server ?

Comment 9 Tony Davalos 2004-08-13 15:03:22 UTC
No luck with either one of these, but I'm getting a different result
now.  My domain name is not updated, but the hostname is now
"ho-mobilegeo1-x-newdomain-net".  It's replacing the "." with "-". 
I'm also getting the following two line error message in

Aug 13 09:57:29 ho-mobilegeo1-x dhclient: if IN A
ho-mobilegeo1-x.newdomain.net. rrset doesn't exist add 3600 IN A
ho-mobilegeo1-x.newdomain.net. add 3600 IN TXT
"005fac82c5ccb7e2b0ff1aa2f742ad18e5": ran out of space.

Aug 13 09:57:29 ho-mobilegeo1-x network: Bringing up interface eth0: 

Comment 10 Jason Vas Dias 2004-08-13 16:52:03 UTC
Well, it looks like the client is trying to do the right thing -
it is now sending the DNS update, but it is getting a response
from the server that :
 a) rrset doesn't exist - this is good, as it means that no 
    previous mapping existed, and the server is attempting to
    create a new one.
 b) creation of the new TXT record fails on the server because it 
    'ran out of space' - this is the client printing the 
    error message received from the server.
The BIND DNS server returns the 'ran out of space' message when
parsing of the TXT record fails because it runs out of available
buffer memory - typically when there is a missing quote in a TXT
The dhclient tries to associate a TXT record consisting of the
dhcp-client-identifier (default is the ethernet address) with the
A record , and the parsing of this TXT record has failed, causing
the 'out of space' error. 
Try setting your dhcp-client-identifier to your ethernet address
string (enclosed in quotes) manually.

If this still fails, please attach another tcpdump file of the
dhclient transaction:
tcpdump -nl -i eth0 -vv -xx -s 2048 '(' port bootpc ')' or '(' port
bootps ')' > /tmp/tcpdump.log &

Comment 11 Tony Davalos 2004-08-13 19:06:39 UTC
Still fails.  Here is the current contents of my dhclient-eth0.conf:

supersede domain-name "newdomain.net";
send fqdn.server-update off;  
send fqdn.fqdn "ho-mobilegeo1-x.newdomain.net.";  
send fqdn.encoded on; 
send dhcp-client-identifier "00:0F:1F:1B:1D:C9";
zone "newdomain.net" {
        type slave;
        masters {; };
        allow-update { any; };
        allow-transfer { any; };

I'll include the dump log in another entry.


Comment 12 Tony Davalos 2004-08-13 19:19:57 UTC
Created attachment 102715 [details]
New dump log

This is the new dump log that was created after adding the dhcp-client

Comment 13 Jason Vas Dias 2004-08-13 21:14:01 UTC
Did you try it without the "zone" declaration ?

send fqdn.server-update off;  
send fqdn.fqdn "ho-mobilegeo1-x.newdomain.net.";  
send fqdn.encoded on; 
send dhcp-client-identifier "00:0F:1F:1B:1D:C9";

What is it saying in /var/log/messages now ?

Sorry, the tcpdump would be much more informative if it was:

tcpdump -nl -vv -XX -s 2048 port bootp or port bootps or port domain

this will also show the DNS update and responses from the DNS server.

Comment 14 Jason Vas Dias 2004-08-16 19:46:16 UTC
 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, I use only options:
   send fqdn.fqdn "myhost.mydomain.";
   send fqdn.server-update off;
 IF the nameserver is authoritative for the "mydomain." zone,
 and allows updates (from "any" or based on IP), then:
  A) after sending DHCPOFFER to client, the server adds a 
     reverse mapping for client's IP address;
  B) after sending DHCPREQUEST and receiving DHCPACK, the
     client does in fact add a forward DNS mapping for the
     requested domain name.

 It would appear that this problem was caused by a nameserver
 or dhcp server misconfiguration, and that there is no bug with
 the Red Hat dhclient distribution.

 Further help in resolving this problem may be obtained by emailing
 these mailing lists: bind-users@isc.org, dhcp-client@isc.org .


Comment 15 John Flanagan 2004-12-21 19:41:51 UTC
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.