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@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...
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)