[RFE] RFC 2317 support in Neutron with designate provider

[Charles Decoux]

proposal: RFC 2317 support in Neutron with designate provider
============================================================

Discussion
----------

**Summary : Add four settings `ipv4_ptr_zone`, `ipv4_ptr_record_template`, `ipv6_ptr_zone` and`ìpv6_ptr_record_template` in various contexts to allow for custom DNS zone selection and resource record generation in case of unusual DNS PTR zones.**

**Rationale:** The creation of PTR DNS zones for non byte-delimited subnets is not possible in OpenStack, it is therefore impossible to manage PTR records in case of a classless in-addr delegation, as described in RFC 2317.

In those situations, one can be given a delegation of a reverse zone with an unusual name, for instance 0-25.2.0.192.in-addr.arpa (when assigned the 192.0.2.0/25 prefix). This scheme is based on the fact that a DNS record for reverse resolution can be a CNAME to another record. This proposal adds a generic mechanism to properly handle such cases.

**Security considerations:** Giving users the ability to make neutron create new arbitrary zones in designate by updating PTR zone settings may pose a security risk. It would be preferable to limit the ability to update these settings to administrators only.

Proposed changes
----------------

Add a `ipv4_ptr_zone` setting to define a PTR zone name, and a `ipv4_ptr_record_template` setting to define the record name template. The template can use placeholders which are replaced with the n-th byte or nibble of the IP address. `%s(octetN)s` is a candidate and is already a notation used in Designate[1].

#### Use cases

Configuration for subnet 192.0.2.0/25 would be as follow:

```
ipv4_ptr_zone = "0-25.2.0.192.in-addr.arpa"
ipv4_ptr_record_template = "%(octet3)s"
```

Which would lead to this zone file:

```
$ORIGIN 0-25.2.0.192.in-addr.arpa

1 IN PTR reverse-1.example.
2 IN PTR reverse-2.example.
# [...]
127 IN PTR reverse-127.example.
```

Assuming that the parent zone has an accurate configuration, such as:

```
$ORIGIN 2.0.192.in-addr.arpa.

0-25 IN NS designate.os.example.
1 IN CNAME 1.0-25
2 IN CNAME 2.0-25
# [...]
127 IN CNAME 127.0-25
```

Configuration for the subnet `192.168.0.0/16` would look like:

```
ipv4_ptr_zone = "168.192.in-addr.arpa"
ipv4_ptr_record_template = "%(octet3)s.%(octet2)s"
```

Same logic for `172.16.0.0/12`:

```
ipv4_ptr_zone = "16/12.172.in-addr.arpa"
ipv4_ptr_record_template = "%(octet3)s.%(octet2)s.%(octet1)s"
```

When absent, the old behavior of `ipv4_ptr_zone_prefix_size` or `ipv6_ptr_zone_prefix_size` is kept.

### First step: global Neutron configuration

The behavior described above is configured with settings in the global neutron configuration file.

Raise an error in case of invalid setting configuration:
* `ipv4_ptr_zone_prefix_size` is set and either `ipv4_ptr_zone` or `ipv4_ptr_record_template` is set.
* `ipv4_ptr_zone` is set and `ipv4_ptr_record_template` is not set.
* `ipv4_ptr_zone` is not set and `ipv4_ptr_record_template` is set.
* The same applies for IPv6 settings.

### Second step: per-IPAllocationPool configuration

Global settings could be overwritten for each `IPAllocationPool`; however, it would require an update of both `IPAllocationPool` and `IPAllocation` models (in `neutron/db/models_v2.py`), as `IPAllocation` would need to keep track of `IPAllocationPool` rDNS settings.

Theses settings could be stored in the `IPAllocationPool` model:

```python
class IPAllocationPool(model_base.BASEV2, model_base.HasId):
    # [snip]
    ptr_zone = sa.Column(sa.String(255), nullable=True)
    ptr_record_template = sa.Column(sa.String(255), nullable=True)
```

A reference to the originating `IPAllocationPool` could be kept into the `IPAllocation` model in order to retrieve the rDNS settings:

```python
class IPAllocation(model_base.BASEV2):
    # [snip]
    ip_allocation_pool_id = sa.Column(sa.String(64), nullable=False)
```

[Slawek Kaplonski (slaweq)]

Lets discuss that initially on our next drivers meeting on Friday 12.03.2021: http://eavesdrop.openstack.org/#Neutron_drivers_Meeting

[Slawek Kaplonski (slaweq)]

Conclusion from our meeting is that we are ok with this RFE. But let's wait for the feedback from the Designate team first and if they will not have anything against, I will mark this rfe as approved.

[Michael Johnson (johnsom)]

Can you provide an example of a case where you are unable to create a port in neutron with a specific IP address?

I do not understand why this is needed with Designate.

If you configure neutron to manage PTR records for ports, Designate will create the required PTR zones based on the IP address. These zones are owned by the project specified in neutron.conf [designate] project_name. These zones will be managed on an octet boundary automatically, based on the ipv4_ptr_zone_prefix_size.

[Slawek Kaplonski (slaweq)]

On the last drivers meeting (http://eavesdrop.openstack.org/meetings/neutron_drivers/2021/neutron_drivers.2021-03-19-14.00.log.html#l-76) we decided to approve this RFE.
Please now provide the spec with detailed information about this change and its prerequisite steps required by that new functionality.

We are now waiting for review spec proposed by You. Spec can be proposed to the https://opendev.org/openstack/neutron-specs repo.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-specs/+/791400

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Rodolfo Alonso <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron-specs/+/791400
Reason: Please, feel free to restore this spec if needed.