Bug #8179
closed
Incorrect reverse DNS zone in DHCP server config for non-octet-aligned subnet mask
100%
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
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.
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. :)
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.
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.
Updated by Viktor Gurov over 4 years ago
Updated by Jim Pingle over 4 years ago
- Status changed from New to Pull Request Review
- Target version set to 2.5.0
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!
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.
Updated by Anonymous about 4 years ago
- Target version changed from 2.5.0 to Future
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
Updated by Vyacheslav Kononenko almost 3 years ago
OMG for 4 years they cannot add custom block to DHCP config. Unbelievable level of support!
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.
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.
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.
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