Bug 138677 - dhcpd silently accepts malformed dhcpd.conf zone statement
dhcpd silently accepts malformed dhcpd.conf zone statement
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
3
All Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-10 12:32 EST by Pavel Polischouk
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-13 19:28:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pavel Polischouk 2004-11-10 12:32:27 EST
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.
Comment 1 Jason Vas Dias 2004-11-10 13:49:15 EST
 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).
Comment 2 Jason Vas Dias 2005-10-13 19:28:48 EDT
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.

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