yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #85379
[Bug 1918424] [NEW] [RFE] RFC 2317 support in Neutron with designate provider
Public bug reported:
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)
```
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1918424
Title:
[RFE] RFC 2317 support in Neutron with designate provider
Status in neutron:
New
Bug description:
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)
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1918424/+subscriptions
