Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 "Create zone from prefix" broken in GUI #107

Open
cmmacneill53 opened this issue Nov 16, 2018 · 3 comments · May be fixed by #139
Open

IPv6 "Create zone from prefix" broken in GUI #107

cmmacneill53 opened this issue Nov 16, 2018 · 3 comments · May be fixed by #139
Labels

Comments

@cmmacneill53
Copy link

Short description
Multiple issues with "Create zone from prefix" in GUI for IPv6 zones:-

  1. 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.

  2. 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

  1. 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.

@jsoref
Copy link
Contributor

jsoref commented Jun 7, 2019

I had filed point 1 as #135 and since fixed it with #137

jsoref added a commit to jsoref/dns-ui that referenced this issue Jun 10, 2019
@jsoref jsoref linked a pull request Jun 10, 2019 that will close this issue
@thomas-pike
Copy link
Collaborator

thomas-pike commented Jan 18, 2020

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...

@jsoref
Copy link
Contributor

jsoref commented Aug 9, 2020

I made the same mistake as the reporter. I don't see any reason not to also reasonably handle someone entering /xx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants