Bug #6413


dhcpd.conf DDNS PTR zone wrong with third octet of 0

Added by Eric Knabke over 7 years ago. Updated over 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


Reference Link:

Not sure if this is the best place to post this issue, but as it is related to the DHCP Server, it seems to make sense.

pfSense Version: 2.3.1-RELEASE

I set the system up to serve out DHCP addresses in the subnet of This all worked fine and dandy, but for various reasons I am running a separate BIND server, hence I am not using the builtin DNS Forwarder or Resolver. I did however setup the system to register leased DHCP addresses on behalf of the clients by the pfSense router. This I believe worked for adding a forward map to the corresponding domain zone on the BIND server (I say believe, because I can't for sure recall if it worked for forwards before I modified the file to add the ddns-domainname and ddns-rev-domainname), either way, forwards worked as expected. Where I ran into trouble was with the reverse maps...these were not working as I expected. Now, for times sake (namely my time), I will skip a few things and go straight to the issue at hand, there appears to be a bug with the '' script (this is the script that dynamically generates the dhcpd.conf file upon boot). What seems to be the issue is that even though the subnect is a perfectly valid subnet....the code in the file does not handle the '0' in the third octet well. So, what happens is that the system generates a 'zone' entry in the dhcpd.conf file that looks like this:

zone {

When I saw this I thought this was very strange...and low it is! After quite a bit of digging, I believe I found the offending code in the file (line 682 - 713):

         $revsubnet = array_reverse(explode('.',$subnet));

         /* Take care of full classes first */
         switch ($ifcfgsn) {
            case 8:
               $start_octet = 3;
            case 16:
               $start_octet = 2;
            case 24:
               $start_octet = 1;
               $start_octet = 0;
               /* Add subnet bitmask to first octet */
               $revsubnet[0] .= '-' . $ifcfgsn;


         $ptr_domain = '';
         for ($octet = 0; $octet <= 3; $octet++) {
            if ($octet < $start_octet) {
            $ptr_domain .= (empty($ptr_domain) ? '' : '.');
            $ptr_domain .= $revsubnet[$octet];
         $ptr_domain .= "";
         $newzone['ptr-domain'] = $ptr_domain;
         unset($ptr_domain, $revsubnet, $start_octet);

The specific offending line is (line 708):

$ptr_domain .= (empty($ptr_domain) ? '' : '.');

This makes perfect sense once you take the time to write a small test routine like I did with the above incorporated (includes a couple of functions from

The issue here is that the PHP 'empty()' function returns true for a value of '0', hence instead of adding a '.' which is what I am guessing is the desired effect, it concatenates a blank. Then, the next line adds the value of the octet. So, basically this is how you end up with an incorrect 'zone' entry in the dhcpd.conf file.

So, to the devs, I have three requests:

  1. Verify if this is a bug or intentional (I'm thinking bug)
  2. If it is a bug, please correct it (i.e.: don't use 'empty()')
  3. Please add an option in the WebConfigurator to add 'ddns-rev-domainname' to the dhcpd.conf (I would like reverse maps with no hassle) (value should be: ddns-rev-dommainname "")
    • It would be nice to have an option called "Register Reverse DNS Client Addresses", or something along those lines. Would be located directly next to the checkbox for registering DHCP clients in DNS.

NOTE: There is a workaround for this, set the subnet to, this alleviates the symptom but does not correct the cause.

Actions #1

Updated by Chris Buechler over 7 years ago

  • Subject changed from Similar bug to Bug #5041 to dhcpd.conf DDNS PTR zone wrong with third octet of 0
  • Status changed from New to Confirmed
  • Target version deleted (2.3.1-p1)
  • Affected Version changed from 2.3.1 to All
  • Affected Architecture added
  • Affected Architecture deleted (amd64)
Actions #2

Updated by Chris Buechler over 7 years ago

  • Status changed from Confirmed to Feedback
  • Target version set to 2.3.1-p2

what I just pushed fixes

Actions #3

Updated by Chris Buechler over 7 years ago

  • Status changed from Feedback to Resolved



Also available in: Atom PDF