pfSense

Oops, something went wrong with the formatting. The "+" signs shouldn't be there of course.

Looks like the bug is here in services.inc:

if (isset($dhcpifconf['ddnsupdate'])) {
$need_ddns_updates = true;
$newzone = array();
if($dhcpifconf['ddnsdomain'] <> "") {
$newzone['domain-name'] = $dhcpifconf['ddnsdomain'];
$dnscfg .= " ddns-domainname \"{$dhcpifconf['ddnsdomain']}\";\n";
} else {
$newzone['domain-name'] = $config['system']['domain'];
}
$revsubnet = explode(".", $subnet);
$revsubnet = array_reverse($revsubnet);
foreach ($revsubnet as $octet) {
if ($octet != "0")
break;
array_shift($revsubnet);
}
$newzone['ptr-domain'] = implode(".", $revsubnet) . ".in-addr.arpa";
}

For me (no programming skills so might be wrong) it looks like the line that shifts the array until there is no longer a "0" is causing the issue.
For a /24 net it shouldn't shift more than one octet.

For your 192.168.0.0/24 case and other odd cases like 192.168.1.128/25 and... this pull request should fix it:
https://github.com/pfsense/pfsense/pull/1827
Note that there are other cases with subnet mask bit counts <24 that are not nice multiples of 8 - and it is not entirely clear what to do about those, so I have made code that should not change the outcome for those sort of subnets - e.g. 172.17.0.0/20 or 192.168.16.0/20 ...

It's always ugly for anything other than /24, /16, and /8's. http://tools.ietf.org/html/rfc2317

Long story short the zone needs to match what's on the server, so perhaps a freeform field is a better fit rather than a guess in some cases. Tricky to accommodate all scenarios.

RFC2317 should deal just with cases of bit count >24 - tricks for delegating less than a /24 size piece of reverse lookup name space to an entity that has just a smaller piece of a /24. That will be rather difficult to achieve here.

For subnets like 10.20.16.0/20 (=10.20.16-31) the code (both versions) currently just generates:
16.20.10.in-addr.arpa

Perhaps it should generate all of:
16.20.10.in-addr.arpa
17.20.10.in-addr.arpa
...
30.20.10.in-addr.arpa
31.20.10.in-addr.arpa

For the particular case of 10.20.0.0/20 (=10.20.0-15) the code (both versions) generates:
20.10.in-addr.arpa

This is inconsistent behaviour between 10.20.0.0/20 and 10.20.16.0/20 - but that is the way it was and I didn't want to break something there for somebody. Mainly because I was not sure which is the best/correct thing to do:
20.10.in-addr.arpa
or
16.20.10.in-addr.arpa
17.20.10.in-addr.arpa
...
30.20.10.in-addr.arpa
31.20.10.in-addr.arpa

If someone tells me which way to go there, then I can easily code it.

Happy to code the auto-expansion of stuff like:
10.20.16.0/20
into
Alternative (1):
16.20.10.in-addr.arpa
17.20.10.in-addr.arpa
...
30.20.10.in-addr.arpa
31.20.10.in-addr.arpa

But maybe also the user might need it to be:
Alternative (2):
20.10.in-addr.arpa

which covers more address space, but maybe is what happens to match the reverse zone on their DNS server.

Or maybe there has to be an advanced checkbox somewhere so the user can choose which of the above alternatives they want?
And in that case, which should be the default way to do it, Alternative (1) or (2)?

bump (a month old now)