Project

General

Profile

Bug #8179

Incorrect reverse DNS zone in DHCP server config for non-octet-aligned subnet mask

Added by Alfred Barnat almost 3 years ago. Updated 10 days ago.

Status:
Feedback
Priority:
Normal
Category:
DHCP Server
Target version:
Start date:
12/10/2017
Due date:
% Done:

100%

Estimated time:
Affected Version:
Affected Architecture:

Description

I have a DHCP server running on pfSense 2.4.2 on an interface with subnet 172.24.208.0 and subnet mask 255.255.254.0. Upon configuring dynamic DNS, I saw that regular DNS records were being correctly inserted into my DNS server, but PTR records were not. Near the bottom of /var/dhcpd/etc/dhcpd.conf, I found the following:

zone 0-23.208.24.172.in-addr.arpa {
    primary 127.0.0.1;
}

This should have been:
zone 208-209.24.172.in-addr.arpa {
    primary 127.0.0.1;
}

The code responsible is in /etc/inc/services.inc. I believe I was able to restore correct behavior by replacing the entire switch ($ifcfgsn) statement with the following:

$subnet_mask_bits = 32 - $ifcfgsn;
$start_octet = $subnet_mask_bits >> 3;
$octet_mask_bits = $subnet_mask_bits & 3;
if ($octet_mask_bits) {
    $octet_mask = (1 << $octet_mask_bits) - 1;
    $octet_start = $revsubnet[$start_octet] & ~$octet_mask;
    $revsubnet[$start_octet] = $octet_start . "-" . ($octet_start + $octet_mask);
}

(Please use the above as a reference only; the code could undoubtably be improved.)

Associated revisions

Revision d95e86dc (diff)
Added by Viktor Gurov 7 months ago

Reverse DDNS zone in DHCP server for non-octet-aligned subnet. Issue #8179

History

#1 Updated by Yousif Hassan over 2 years ago

Alfred Barnat wrote:

This should have been:
zone 208-209.24.172.in-addr.arpa {
primary 127.0.0.1;
}

While the suggested code fix does in fact generate the more correct classless zone name, it appears the issue might be more complex. This article sheds more light on the situation, which is that the observed behavior of not updating the reverse zone properly is in fact a limitation of dhcpd.

https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update

note:

DHCP does NOT support updating of arbitrary zones, it takes the ip address, reverses the octets, and appends the reverse domain name (deafult in-addr.arpa). [sic]

For non "classful" boundaries (anything not /8, /16, /24, or /32), pfSense would still need to generate a zone that allows dhcpd to update it pursuant to the dhcpd limitations above, so it seems that it cannot contain a slash, hyphen, or non-IP-legal octet integer.

I think the easier way for the developers to help us work around this issue is by adding a general config option block in which one can type configuration that will go directly into dhcpd.conf. This way, a user can specify his or her own reverse zone files, or, as the article suggests, specify an alternate ddns-rev-domainname; this would allow one to use the CNAME delegation back to the in-addr.arpa zone.

I hope this helps; I really hope we can get a general config option block to add to dhcpd.conf. :)

#2 Updated by Jim Pingle about 1 year ago

  • Category set to DHCP Server

#3 Updated by Yousif Hassan about 1 year ago

Yousif Hassan wrote:

While the suggested code fix does in fact generate the more correct classless zone name, it appears the issue might be more complex. This article sheds more light on the situation, which is that the observed behavior of not updating the reverse zone properly is in fact a limitation of dhcpd.

https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update

note:
[...]

For non "classful" boundaries (anything not /8, /16, /24, or /32), pfSense would still need to generate a zone that allows dhcpd to update it pursuant to the dhcpd limitations above, so it seems that it cannot contain a slash, hyphen, or non-IP-legal octet integer.

I think the easier way for the developers to help us work around this issue is by adding a general config option block in which one can type configuration that will go directly into dhcpd.conf. This way, a user can specify his or her own reverse zone files, or, as the article suggests, specify an alternate ddns-rev-domainname; this would allow one to use the CNAME delegation back to the in-addr.arpa zone.

I hope this helps; I really hope we can get a general config option block to add to dhcpd.conf. :)

Saw that this was updated a few months ago - is pfsense going to get a workaround for this? It's still generating incompatible reverse zone names in /var/dhcpd/etc/dhcpd.conf for anything not in traditional class boundaries. While the notation used by pfsense is technically correct, dhcpd does not support it for reverse zone dynamic updates. Specifying one's own "additional" reverse zone files in the GUI would be a simple workaround. Thanks.

#5 Updated by Jim Pingle 7 months ago

  • Status changed from New to Pull Request Review
  • Target version set to 2.5.0

#6 Updated by Renato Botelho 7 months ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho
  • % Done changed from 0 to 100

PR has been merged. Thanks!

#7 Updated by Yousif Hassan 7 months ago

The PR is appreciated - However may I ask how this is going to help us? dhcpd doesn’t support the classless notation for reverse delegation, even if the computed reverse zone were corrected. Do you know something else, like does dhcpd now support updating classless reverse zones? If not, it will not generate a PTR update when an address is handed out (and the A record is generated). Thank you.

#8 Updated by Steve Beaver 10 days ago

  • Target version changed from 2.5.0 to Future

Also available in: Atom PDF