Bug 36616 - Reverse zone: wrong description, wrong mapping to IPv4/IPv6
Reverse zone: wrong description, wrong mapping to IPv4/IPv6
Status: REOPENED
Product: UCS
Classification: Unclassified
Component: UMC - DNS
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.x
Assigned To: UMC maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-11-12 18:34 CET by Florian Best
Modified: 2024-01-29 17:12 CET (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.171
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2014-11-12 18:34:54 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.
Comment 1 Stefan Gohmann univentionstaff 2019-01-03 07:17:00 CET
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.
Comment 2 Philipp Hahn univentionstaff 2024-01-29 17:12:25 CET
(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>