From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: The zone statement in /etc/dhcpd.conf should be like this: zone example.com. { .... } However, if the zone statement is like this: zone example.com. IN { ... } (note the "IN" class keyword, as in named.conf.) dhcpd does not complain about this, but no keys or "primary" statements specified for "example.com." work. Version-Release number of selected component (if applicable): dhcp-3.0.1-11 How reproducible: Always Steps to Reproduce: 1. Create a zone statement like this zone example.com. IN { key <your_key> } 2. Restart dhcpd Actual Results: dhcpd will start normally The key will not work to update DNS records: the DNS requests will be sent with no signature (as default). Expected Results: dhcpd should complain about syntax error in config file (and refuse to load), OR properly understand/ignore the class description keyword ("IN") as named does. Additional info: It looks like dhcpd permits spaces in zone names, and just removes them. So it treats "example.com. IN" as "example.com.in.", and puts this as a zone name in its hash. Later when trying to search for keys for "example.com." it obviously can't find them, because there's no "example.com." in its hash, only "example.com.in.". Same applies to reverse zones.
This is really an upstream (ISC) issue. I will develop a patch to fix this and submit it to ISC. This problem should be fixed in the next version of dhcp (dhcp-3.0.1-12).
Sorry this bug was somehow overlooked . Having now had a chance to investigate this fully, I don't think it is a bug: Yes, dhcp allows spaces in host names - eg. this is valid: 'option routers 1 . 2 . 3 . 4, router2 . my . net;' and sets the routers option to '1.2.3.4, dns_lookup("router2.my.net. A")' We really don't want to change this, as users may actually depend on it. The 'zone' statement syntax as shown in dhcpd.conf shows host names as the only argument allowed between 'zone' and '{', and makes no pretense of supporting named.conf 'zone' syntax . 'example.com. IN' is valid DHCP input syntax for the host name 'example.com.in', but 'example.com IN' (also valid named.conf syntax) is invalid DHCP host name syntax and does produce a dhcpd.conf parse error. So yes, this is somewhat confusing, but there is not much that can be done about it as long as dhcp ignores whitespace in host name input text, as it always has done and is likely to continue to do.