designate fails to accept classless in-arpa.addr zones

[Arturo Borrero Gonzalez]

DNS classless in-arpa.addr delegations are defined in RFC2317 [0].

Per the RFC, the zone name usually contains the '/' character in the zone name, example:

 * 0/29.1.168.192.in-addr.arpa. (delegation for 192.168.1.0/29)
 * 0/25.0.1.10.in-addr.arpa. (delegation for 10.1.0.0/25)

In Designate, when trying to create a zone with such a name, it is reported as invalid:

$ openstack zone create [..] 0/29.57.15.185.in-addr.arpa.
Provided object is not valid. Got a ValueError error with message Domain 0/29.57.15.185.in-addr.arpa. is not match

This error backtrace is:

ERROR designate.objects.adapters.base Traceback (most recent call last):
ERROR designate.objects.adapters.base File "/usr/lib/python3/dist-packages/designate/objects/adapters/base.py", line 188, in parse
ERROR designate.objects.adapters.base values, output_object, *args, **kwargs)
ERROR designate.objects.adapters.base File "/usr/lib/python3/dist-packages/designate/objects/adapters/api_v2/zone.py", line 88, in _parse_object
ERROR designate.objects.adapters.base values, object, *args, **kwargs)
ERROR designate.objects.adapters.base File "/usr/lib/python3/dist-packages/designate/objects/adapters/base.py", line 295, in _parse_object
ERROR designate.objects.adapters.base setattr(output_object, obj_key, value)
ERROR designate.objects.adapters.base File "/usr/lib/python3/dist-packages/designate/objects/base.py", line 144, in __setattr__
ERROR designate.objects.adapters.base super(DesignateObject, self).__setattr__(name, value)
ERROR designate.objects.adapters.base File "/usr/lib/python3/dist-packages/designate/objects/base.py", line 498, in setter
ERROR designate.objects.adapters.base field_value = field.coerce(self, name, value)
ERROR designate.objects.adapters.base File "/usr/lib/python3/dist-packages/designate/objects/fields.py", line 205, in coerce
ERROR designate.objects.adapters.base raise ValueError("Domain %s is not match" % value)
ERROR designate.objects.adapters.base ValueError: Domain 0/29.57.15.185.in-addr.arpa. is not match

Basically, the input seems to don't match this regex [1]:

 RE_ZONENAME = r'^(?!.{255,})(?:(?!\-)[A-Za-z0-9_\-]{1,63}(?<!\-)\.)+\Z'

The fix should be to allow the '/' character in the zone name, as recommended in the RFC.

[0] https://tools.ietf.org/html/rfc2317
[1] https://opendev.org/openstack/designate/src/branch/master/designate/objects/fields.py#L95

[Graham Hayes (grahamhayes)]

We should update the docs to say that we should replace the `/` in the examples with something like `-` for designate as we will reject a zone with `/`

[Arturo Borrero Gonzalez (arturoborrero)]

Follow-up comment:

using '-' instead of '/' is indeed allowed and accepted by Designate.

[Dr. Jens Harbott (j-harbott)]

But it may happen that a provider decides on using the scheme as documented in the RFC and then a deployer needs to use a zone like 0/25.bla.in-addr.arpa, so it would be reasonable for designate to support that.

[Michael Johnson (johnsom)]

The RFC actually advises to use hyphen instead of '/':

The examples here use "/" because it was felt to be more visible and
pedantic reviewers felt that the 'these are not hostnames' argument
needed to be repeated. We advise you not to be so pedantic, and to
not precisely copy the above examples, e.g. substitute a more
conservative character, such as hyphen, for "/".

[Michael Johnson (johnsom)]

I am going to close this bug as Designate properly handles the RFC recommendation to use a hyphen instead of a forward slash.

[Elvis Espinal (elvisespinal)]

As Designate's goal is to allow us to manage dns through its API and dns servers like BIND9 allow us to define zones with / on its name because it appears like RFC2317 do not reject the usage of / while creating ptr records, I suggest that we all consider allowing users to create zone with / on its name.

My current problem is that companies like att will not delegate static block of IP to our DNS using -, they will only do it with /.

To go around this, I had to deploy a separate BIND9 server, point the dns that att delegated the static block of ip to and manually create the 0/25.57.15.185.in-addr.arpa. but this is something that I understand, should be also managed by designate/designate-bind.

Another solution could be creating some sort of alias that tell designate (or designate-bind) that queries for a specific subnet should also reply if there is a zone that match the subnet definition with -, for example, assuming that we have a zone in designate defined as follows:
ZONE_NAME = 0-127.57.15.185.in-addr.arpa.

When someone ask for the PTR record like this:

;; QUESTION SECTION:
93.57.15.185.in-addr.arpa. IN PTR

ISPs are currently delegating the /25 subnet with the following CNAME:
;; ANSWER SECTION:
93.57.15.185.in-addr.arpa. 86400 IN CNAME 93.0/25.57.15.185.in-addr.arpa.

Designate (or designate-bind specifically), should also understand that 93.0/25.57.15.185.in-addr.arpa. its part of the zone 0-127.57.15.185.in-addr.arpa. and should also reply with the record defined for 93.0-127.57.15.185.in-addr.arpa. as follows:

93.0/25.57.15.185.in-addr.arpa. 3600 IN PTR mail.examplesub.example.com.

[Michael Johnson (johnsom)]

The root of the issue is that, per the RFCs, '/' is not a valid character for PTR records.
https://datatracker.ietf.org/doc/html/rfc1034#section-3.5