Ability to manage /23 reverse zones

[misilot]

trafficstars

Is your feature request related to a problem? Please describe. From the documentation

REV complies with RFC2317, "Classless in-addr.arpa delegation" for netmasks of size /25 through /31. While the RFC permits any format, we abide by the recommended format: FIRST/MASK.C.B.A.in-addr.arpa where FIRST is the first IP address of the zone, MASK is the netmask of the zone (25-31 inclusive), and A, B, C are the first 3 octets of the IP address. For example 172.20.18.130/27 is located in a zone named 128/27.18.20.172.in-addr.arpa

Is there a possibility to include or set a flag to allow for managing of /23 or other size zones? We have a handful of /23's we would like to manage but are running into that DNSControl requires the IPv4 mask must be multiple of 8 bits.

Describe the solution you'd like Manage any format reverse zone

Describe alternatives you've considered Not sure of any other solutions?

[tlimoncelli]

Interesting request! We're basically following the RFC, which doesn't include /23. Adding support for that sounds like an interesting challenge!

The REV() function just takes a string and returns a string. You can see the test cases in pkg/transform/arpa_test.go.

How would you want /23 to work? Could you make a dnsconfig.js snippet that doesn't use REV()? I could then back-port that to make REV() produce similar results.

[misilot]

So I wonder if this is where RFC 4183 might be a good option?

<subnet>-<subnet mask bit count>.2.0.192.in-addr.arpa (RFC 4183 style)

10.130.90.0/23 -> 90-23.130.10.in-addr.arpa.

So a snippet I believe should be

D('90-23.130.10.in-addr.arpa', NO_REGISTRAR,
    DnsProvider(AWS)
);

[tlimoncelli]

Ah! RFC 4183 covers this (Sorry, I hadn't realized)

Would you be interested in adding this case to pkg/transform/arpa_test.go and pkg/transform/arpa.go?

[misilot]

I can take a stab at it!

Though, I am wondering if it would make sense to add a feature flag that allows for specifying using RFC 4183 or RFC 2317 notation. Not sure how this would be accomplished?

[misilot]

Just putting this here for notes

Given a candidate network of the form x.y.z.n/m create an in-addr.arpa candidate domain name:

1. If the number of mask bits m is greater than or equal to 24 but less than or equal to 32, then the candidate domain name is n-m.z.y.x.in-addr.arpa.
2. If the number of mask bits m is greater than or equal to 16 but less than 24, then the candidate domain name is z-m.y.x.in-addr.arpa.
3. If the number of mask bits m is greater than or equal to 8 but less than 16, then the candidate domain name is y-m.x.in-addr.arpa.
4. The notion of fewer than 8 mask bits is not reasonable.

[tlimoncelli]

Here's some brainstorming about what we could do:

• REV() should work as it does today (RFC 2317) but any new formats are RFC 4183.
• Create REV4183() and REV2317()
  • with REV() being an alias for REV2327() for backwards compatibility.
• Create REV4183() and REV2317() and REVCOMPAT()
  • REVCOMPAT() implementing RFC 2317 for /24 to /31 and RFC4183 for everything else.
  • REV() is an alias for REVCOMPAT()
• Add an optional flag to the REV() command: REV("1.2.3.4", { format: "rfc4183" } )
  • The default would be RFC 2317 but change to RFC 4183 in the next major release.
• Add a flag to the creds.js file. "FLAGS": { "rev-format": "rfc4183" },
• Add a flag on the command line. dnscontrol preview --rev=4183
• Create ARPA() which is like REV() but is fully RFC 4183.

[tlimoncelli]

Caveat: Users that have special needs or don't like any of the options can simply do it manually:

D("1.1.1.1.in-addr.arpa", ...

However then it is difficult to write a macro that does D_EXTEND(REV("1.1.1.1").

On a personal notel... I really dislike that RFC 2317 uses a / in the domain name and would be very happy if we could just tell all people to switch to RFC 4383. Sadly, we can't make that kind of change except in a major release.