From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20030226 Description of problem: When setting up dynamic DNS with dhcpd, the man page for dhcp.conf gives an example snippet of ISC bind named.conf, as well as dhcpd.conf. Quote: the zone containing PTR records ‐ for ISC BIND, something like this: key DHCP_UPDATER { secret pRP5FapFoJ95JEL06sv4PQ==; }; End Quote. the problem is: the line "algorithm HMAC-MD5.SIG-ALG.REG.INT;" is illegal syntax in all production versions of bind 9 (9.2.1) The only working algorithm is "hmac-md5" In addition: in the dhcpd.conf man page, the description goes on to specify the algorithm as HMAC-MD5.SIG-ALG.REG.INT; Quote: To do so, you need to add something like this to your dhcpd.conf file: key DHCP_UPDATER { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret pRP5FapFoJ95JEL06sv4PQ==; }; End Quote If you use this algorithm as specified in the dhcpd.conf man page, you will never get your dynamic updates to work. Why? Because the secret key shown in the example is a different method, even though they both say HMAC-MD5. The HMAC-MD5.SIG-ALG.REG.INT will change the encoding to a different format -- that is incompatible with the hmac-md5 system that bind 9 only accepts. Changing the line to 'algorithm hmac-md5;' solves all of these problems. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: set up name daemon. bind 9. Require TSIG be used for dynamic updates for your zone key "foo-key." { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret "pRP5FapFoJ95JEL06sv4PQ==;"; }; 2. reconfig name server 'rndc reconfig' 3. look at /var/log/messages file -- notice named didn't take your new config -- the algorithm is illegal. Mar 5 00:07:10 www named[930]: /etc/named.conf:83: configuring key 'pietbarber-dhcp.': bad algorithm Mar 5 00:07:10 www named[930]: reloading configuration failed: bad algorithm 1b. Set up your DNS server to allow updates with your TSIG key. 2b. Set up dhcpd with the same zone and key statements, and tell it to do dynamic updates based off of client's hostname. 3b. Set up client to do dynamic update with hostname. 4b. Watch this message appear in /var/log/messages when dhcp tries to update the name daemon: Mar 4 23:42:58 www dhcpd: if IN A hammy.pietbarber.com. domain doesn't exist add 43200 IN A hammy.pietbarber.com. 10.9.0.253 add 43200 IN TXT hammy.pietbarber.com. "00a567[snip]281": bad DNS key. Actual Results: I got nasty messages in my /var/log/messages, and the pietbarber.com zone didn't get updated. Fooey. Expected Results: I expected to see pietbarber.com get dynamically updated, but all I got was key errors. Additional info: In Chapter 17 of the Redhat documentation for /etc/sysconfig doesn't have much to say about the /etc/sysconfig/network-scripts/ifcfg-* configuration for DHCP_HOSTNAME -- This would be a prime place to put that information! (http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/custom-guide/s1-dhcp-configuring-client.html) If one wants DNS to be dynamically updated through dhcpd, tinkering with dhclient.conf all day will not do the trick -- making a change to the sysconfig scripts will. Add this to /etc/sysconfig/network-scripts/ifcfg-eth0 : DHCP_HOSTNAME="${HOSTNAME%%.*}"
Created attachment 90472 [details] patch to fix dynamic DNS documentation in dhcpd.conf.5 dhcpd.conf misled the user into using the wrong TSIG algorithm for dynamic updates in conjunction with dhcpd.
I have fixed the Man Page in Rawhide. Tammy could you take a look at the documentation problem. Thanks.
Good point. I'll work on adding it for the next version of the manual.
In regards to your RHL docs bugs: >In Chapter 17 of the Redhat documentation for /etc/sysconfig doesn't have much >to say about the /etc/sysconfig/network-scripts/ifcfg-* configuration for >DHCP_HOSTNAME -- This would be a prime place to put that information! >(http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/custom-guide/s1-dhcp-configuring-client.html) I will add an explanation of this option here and also make sure the option is added to the Reference Guide. However, our DHCP server does not honor this option. It is only there for DHCP servers that require a hostname from the client. >If one wants DNS to be dynamically updated through dhcpd, tinkering with >dhclient.conf all day will not do the trick -- making a change to the sysconfig >scripts will. > >Add this to /etc/sysconfig/network-scripts/ifcfg-eth0 : >DHCP_HOSTNAME="${HOSTNAME%%.*}" On a RHL DHCP server, DNS information is passed to the client if it exists for the client in the DHCP configuration file. If a RHL DHCP client receives DNS information from the server, it will use it. I don't understand how you think the DHCP_HOSTNAME option will allow the client to grab the DNS information since it does without the option. Maybe your server requires a hostname to be passed to it to get the DNS information?
Hi Tammy. Thanks for all the great work you have done with documenting Linux over the years. > On a RHL DHCP server, DNS information is passed to the client if it exists for > the client in the DHCP configuration file. Yes, provided there are DNS entries for the host in question. :) > I don't understand how you think the DHCP_HOSTNAME option will allow the > client to grab the DNS information since it does without the option. > Maybe your server requires a hostname to be passed to it to get the DNS > information? (The server in question is RHL 8.0) The DHCP_HOSTNAME option is for when the client wishes to assert a hostname. (not when it is willing to have its hostname handed-out from the DHCP server). If my RHL workstation (that acts as a dhcp client) has a name associated with it (Just like a Windows 2000 workstation, for instance), I can assert to the DHCP server what is contained in the DHCP_HOSTNAME variable. I did a lot of packet sniffs and analysis with ethereal and tcpdump. I noticed that the Windows 2000 box would always assert to the DHCP server "Hello! My name is pbarber-lt-30; please update your DNS accordingly" and (when I got the dynamic updates working correctly with the dhcp server), the assertions were dynamically updated into the DNS. However, with the RedHat linux workstations, the packet sniffs showed a very different conversation: the hostname's assertion was never a part of the request. The RHL dhcp client scuffed its feet in the dirt, and allowed the DHCP server to tell it what its name was. That's not very assertive, is it? I looked into the dhclient.conf man pages and noticed that there are places to notify the dhcp server of the client's hostname. Making changes to dhclient.conf exactly as the "Dynamic updates" section of the dhclient.conf man page didn't quite do the trick -- The assertions for hostname were never sent to the dhcp server in the same way the Windows 2000 client did. HOWEVER, The init script that starts and stops the network appends to the dhclient.conf file whenever the init script is run. The section of code that does this is in the ifup script (/sbin/ifup) Here it is: if ! grep "send *host-name *\"${DHCP_HOSTNAME}\"" /etc/dhclient-${DEVICE}.conf > /dev/null 2>&1 ; then echo "send host-name \"${DHCP_HOSTNAME}\"; # temporary RHL ifup addition" >> /etc/dhclient-${DEVICE}.conf fi The dhclient.conf man page says that in order to assert a hostname, one has to use this syntax: man dhclient.conf--- DYNAMIC DNS The client now has some very limited support for doing DNS updates when a lease is acquired. This is prototypical, and probably doesnât do what you want. It also only works if you happen to have control over your DNS server, which isnât very likely. (Now THAT'S a ringing endorsement! --pb) send fqdn.fqdn "grosse.fugue.com."; send fqdn.encoded on; send fqdn.serverâupdate off; That seems to be getting ignored, I didn't see the appropriate thing in the packet sniffs for hostname assertion. Also, the $DHCP_HOSTNAME addition with the ifup script seems to override the "send" entries in dhclient.conf. (the dhclient.conf man page doesn't say anything about 'send host-name "hammy.pietbarber.com"', at least until the SAMPLE section of the man page. I hope I 'splained what I needed to say adequately. :)
Steve, can you look at this and tell me what you think?
This is now fixed in all current dhcp-3.0.1+ releases.