Open Stack

Hi Thomas,

Currently the only way to block this is to exclude the reverse pointer
zones that may be assigned in the cloud from the TLD list, or
pre-creating the in-addr.arpa. zone(s) under the service account that
will be used by the neutron extension to create the PTR records.

This of course has the downside of not allowing the projects to see
their PTR records in designate (they are owned by the service
account).

We are currently working on "shared zones" [1] which may allow (in the
future) a neutron extension to "share" a classless PTR zone with the
project. I have started a write up of this use case [2] and I am
planning to propose a summit talk covering "shared zones" and
classless PTR delegation. There has been interest from multiple clouds
for this feature.

Michael

[1] https://review.opendev.org/c/openstack/designate/+/726334
[2] https://review.opendev.org/c/openstack/designate/+/856866

On Thu, Dec 15, 2022 at 2:23 AM Thomas Goirand <zigo at debian.org> wrote:
>
> Hi,
>
> We implemented this scenario for our public cloud:
> https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html#use-case-3b-the-dns-domain-ports-extension
>
> This is currently in production in beta-mode at Infomaniak's public cloud.
>
> We did that, because we want our customers to be able to set any domain
> name or PTR for the IPs they own.
>
> However, we discovered that there's no restriction on what zone
> customers can set. For example, if customer A owns the IP 203.0.113.9,
> customer B can do "openstack zone create 9.113.0.203.in-addr.arpa.",
> preventing customer A to set their PTR record.
>
> Is there currently a way to fix this? Or maybe a spec to implement the
> correct restrictions? What is the way to fix this problem in a public
> cloud env?
>
> Cheers,
>
> Thomas Goirand (zigo)
>