Bug 129646

Try renaming your "/etc/dhclient" file quoted above to 
/etc/dhclient-eth0.conf - that's the config file passed
to dhclient by /sbin/ifup .

Sorry, my mistake when entering the bug, the name of the file that I 
was testing with was actually /etc/dhclient-eth0.conf.

I've been looking into the documentation on this.
 
 According to the relevant standard for dhcp option 81 (FQDN),
 which is at :
   http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-07.txt
 (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 
    HOSTNAME="newhostname.newdomain.com"
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. 

Sorry, if you have to do the tcpdump, please add the '-s 2048' option .

Sorry, the lines above:
by setting the 
    HOSTNAME="newhostname.newdomain.com"
in /etc/sysconfig/network-scripts/ifcfg-eth0 .
should have been:
by setting the 
    HOSTNAME="newhostname.newdomain.com"
in /etc/sysconfig/network

Created attachment 102669 [details]
tcpdump of dhclient eth0

This is the tcpdump of starting the dhclient

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 {138.32.45.40; };
        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.

Thanks

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 ?

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
/var/log/messages:

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. 158.139.13.21 add 3600 IN TXT
ho-mobilegeo1-x.conocophillips.net.
"005fac82c5ccb7e2b0ff1aa2f742ad18e5": ran out of space.

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

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
record.
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 &

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 {138.32.45.40; };
        allow-update { any; };
        allow-transfer { any; };
}

I'll include the dump log in another entry.

Thanks

Created attachment 102715 [details]
New dump log

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

Did you try it without the "zone" declaration ?

ie:
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.

 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, dhcp-client .




 

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.

http://rhn.redhat.com/errata/RHBA-2004-566.html