Univention Bugzilla – Bug 36616
Reverse zone: wrong description, wrong mapping to IPv4/IPv6
Last modified: 2024-01-29 17:12:25 CET
It's possible to add a reverse lookup zone with the subnet 256 or greater. 256.1 is blocked. 256.256.256 is blocked, too. 0 is also possible.
This issue has been filled against UCS 4.0. The maintenance with bug and security fixes for UCS 4.0 has ended on 31st of May 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
(In reply to Florian Best from comment #0) > It's possible to add a reverse lookup zone with the subnet 256 or greater. > 256.1 is blocked. 256.256.256 is blocked, too. 0 is also possible. UDM dns/reverse_zone property "subnet" uses syntax "reverseLookupSubnet". "0" and "256" are valid IPv6 prefixes: >>> from univention.admin.syntax import reverseLookupSubnet >>> import re >>> re.match(reverseLookupSubnet.regex_IPv4, "256") >>> re.match(reverseLookupSubnet.regex_IPv6, "256") <re.Match object; span=(0, 3), match='256'> But "mapSubnet()" is wrong as it maps it to the IPv4 ".in-addr.arpa." instead of the IPv6 ".ip6.arpa": >>> from univention.admin.handlers.dns.reverse_zone import mapSubnet >>> mapSubnet("256") b'256.in-addr.arpa' Please note that syntax "reverseLookupSubnet" has a fundamental problem: Quoting its "error_message": > A subnet for reverse lookup consists of the first 1-3 octets of an IPv4 address As such "0"…"255" should be allowed as a IPv4 subnet, but is not: >>> re.match(reverseLookupSubnet.regex_IPv4, "0") This is caused by the following wrong (simplified) regular expression: > regex_IPv4 = r'(\d+\.){1,2}(\d+)' ^^^ This requires minimum 2 (or 3) octets, but does not allow 1! That is only added by (simplified) regular expression for IPv6: > regex_IPv6 = r'((\x{4}:){0,7}\x{1,3})| ^ ^^^ But this is a problem for "mapSubnet()" which maps "1" as IPv4 only to "1.in-addr.arp", but not as IPv6 to "1.ip6.arpa" as there is no ":" in the sting. Before you ask: 1-126 are class-A networks, so should be allowed to be used as IPv4 subnets. On the other hand any routable IPv6 (except ::address will have at least one ":". See <https://en.wikipedia.org/wiki/IPv6_address>