You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Short description
Multiple issues with "Create zone from prefix" in GUI for IPv6 zones:-
Web page input validation allows entry of prefix with bitmask on the end, e.g. /nn. PHP script doesn't validate either and generates invalid zone, e.g. enter 2400:7700::/32, generates 2.3./.0.0.7.7.0.0.4.2.ip6.arpa. To my knowledge this is not a valid zone.
Algorithm does not correctly handle "packed" prefixes, i.e. prefixes where leading zeros have been removed. For my specific error I was adding a /64. Algorithm handled missing leading zeros in blocks 2 & 3 OK, i.e. nibbles 5 thru 12, but truncated the result for block 4 (nibbles 13 to 16).
Environment
Operating system: Debian v9 (Stretch)
Software version: PowerDNS v4.1.5, Opera version unknown, latest from GIT
Software source: PowerDNS repository, Opera GIT
Backend: PostgreSQL v9.6.10
Steps to reproduce
Enter 2001:470:d:eb3 in "Create zone from prefix" in IPv6 Zones.
Expected behaviour
Should return 3.b.e.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa.
Actual behaviour
returns 3.b.e.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa. (4th nibble from left is missing, resultant is only 15 nibbles, should be 16).
Other information
Happens on other /64 packed prefixes too.
2001:470:1f2d:14b = b.4.1.d.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa.
2001:470🅱️612 = 2.1.6.b.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa.
The text was updated successfully, but these errors were encountered:
Regarding point 2, you would get the behaviour that you are expecting by entering 2001:470:d:eb3: as the zone prefix (note the trailing colon). The current behaviour is kind of by design, but admittedly it might be a confusing choice; it is done this way to allow subnets of lengths that are not represented by whole groups of 4 digits, eg a /60.
I could probably be convinced to change the behaviour though...
Short description
Multiple issues with "Create zone from prefix" in GUI for IPv6 zones:-
Web page input validation allows entry of prefix with bitmask on the end, e.g. /nn. PHP script doesn't validate either and generates invalid zone, e.g. enter 2400:7700::/32, generates 2.3./.0.0.7.7.0.0.4.2.ip6.arpa. To my knowledge this is not a valid zone.
Algorithm does not correctly handle "packed" prefixes, i.e. prefixes where leading zeros have been removed. For my specific error I was adding a /64. Algorithm handled missing leading zeros in blocks 2 & 3 OK, i.e. nibbles 5 thru 12, but truncated the result for block 4 (nibbles 13 to 16).
Environment
Steps to reproduce
Expected behaviour
Should return 3.b.e.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa.
Actual behaviour
returns 3.b.e.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa. (4th nibble from left is missing, resultant is only 15 nibbles, should be 16).
Other information🅱️ 612 = 2.1.6.b.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa.
Happens on other /64 packed prefixes too.
2001:470:1f2d:14b = b.4.1.d.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa.
2001:470
The text was updated successfully, but these errors were encountered: