Project

General

Profile

Actions

Bug #8179

closed

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

Added by Chaos215 Bar2 almost 7 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Category:
DHCP (IPv4)
Target version:
-
Start date:
12/10/2017
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
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.)


Related issues

Has duplicate Bug #12779: Bogus domain generated for reverse DDNS when network mask is custom (not 24 16 or 8)New

Actions
Actions #1

Updated by Yousif Hassan over 6 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. :)

Actions #2

Updated by Jim Pingle over 5 years ago

  • Category set to DHCP (IPv4)
Actions #3

Updated by Yousif Hassan about 5 years 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.

Actions #5

Updated by Jim Pingle over 4 years ago

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

Updated by Renato Botelho over 4 years 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!

Actions #7

Updated by Yousif Hassan over 4 years 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.

Actions #8

Updated by Anonymous about 4 years ago

  • Target version changed from 2.5.0 to Future
Actions #9

Updated by Jim Pingle almost 3 years ago

  • Has duplicate Bug #12779: Bogus domain generated for reverse DDNS when network mask is custom (not 24 16 or 8) added
Actions #10

Updated by Vyacheslav Kononenko almost 3 years ago

OMG for 4 years they cannot add custom block to DHCP config. Unbelievable level of support!

Actions #11

Updated by Azamat Khakimyanov over 2 years ago

  • Status changed from Feedback to Resolved

Tested on 22.05

With IP: 172.24.208.1/23 on DMZ interface and enabled DHCP pool: 172.24.208.10-172.24.209.254 and dynamic DNS configured I got in /var/dhcpd/etc/dhcpd.conf
zone 208-209.24.172.in-addr.arpa. {
primary 127.0.0.1;
key "123adf";
}

I marked this Bug as Resolved.

Actions #12

Updated by Yousif Hassan over 2 years ago

Azamat Khakimyanov wrote in #note-11:

Tested on 22.05

With IP: 172.24.208.1/23 on DMZ interface and enabled DHCP pool: 172.24.208.10-172.24.209.254 and dynamic DNS configured I got in /var/dhcpd/etc/dhcpd.conf
zone 208-209.24.172.in-addr.arpa. {
primary 127.0.0.1;
key "123adf";
}

I marked this Bug as Resolved.

Did a PTR get successfully updated? Does ISC dhcpd support classless dynamic DNS updates now? Otherwise this is still technically a problem with the way pfSense allows the user to interact, as it generates a (technically correct?) classless dhcp zone file but which does not work with dhcpd's DNS updating code.

Actions #13

Updated by Azamat Khakimyanov over 2 years ago

Yousif Hassan wrote in #note-12:

Azamat Khakimyanov wrote in #note-11:

Tested on 22.05

With IP: 172.24.208.1/23 on DMZ interface and enabled DHCP pool: 172.24.208.10-172.24.209.254 and dynamic DNS configured I got in /var/dhcpd/etc/dhcpd.conf
zone 208-209.24.172.in-addr.arpa. {
primary 127.0.0.1;
key "123adf";
}

I marked this Bug as Resolved.

Did a PTR get successfully updated? Does ISC dhcpd support classless dynamic DNS updates now? Otherwise this is still technically a problem with the way pfSense allows the user to interact, as it generates a (technically correct?) classless dhcp zone file but which does not work with dhcpd's DNS updating code.

I closed this bug because the issue this bug was about were solved. I also reopened https://redmine.pfsense.org/issues/12779 so if you have something to add, please add your comment into https://redmine.pfsense.org/issues/12779.
If there is another issue related to reverse DNS zone, please open a new Bug.

Actions #14

Updated by Andrzej Milewski about 2 years ago

It is working. @Yousif Hassan you have to set two zones:
208.24.172.in-addr.arpa and 209.24.172.in-addr.arpa
not 24.172.in-add.arpa.
That is my resoved problem https://forum.netgate.com/topic/174977/bind-dhcp-dynamic-update-reverse-zone-if-algin-is-non-octet-problem/6

Actions #15

Updated by Jim Pingle about 2 years ago

  • Target version deleted (Future)
Actions

Also available in: Atom PDF