Designate driver: allow_reverse_dns_lookup doesn't works if dns_domain zone wasn't created

Thanks for the bug report, Sergey. Please, feel free to propose a fix if you've already written a patch.

Fix: https://review.opendev.org/c/openstack/neutron/+/768594

Please review.

I don't think that this is reasonable, if you do not handle the forward zone within designate, you should also not have the PTR in it. I see the current implementation as a safeguard against create bogus or malicious PTRs and I wouldn't want to change that.

Yes, I understand what you mean, but in some cases domain zone and ptr zone may be hosted by different DNS servers (our case), so we have to create zone if regular (not PTR) zone like domain.com. not exists in Designate.

How you think about add config option like "allow_reverse_dns_lookup_permit_all_domains" or something like it? Will it be possible solution?

In my personal opinion, that would still be out of the scope of the neutron dns_integration, but feel free to create an RFE and discuss this with the neutron drivers team.

Thx Sergei for reporting that issue and Jens for commenting on it already.
Let's treat it as new RFE from now. I would like e.g. Miguel to take a look at it before we will discuss it on the drivers meeting. I will keep You updated in that LP.

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

Will try to be online tomorrow meeting time.

Conclusion from our meeting is that we would first like to know opinion of the Designate team about it. After their feedback we will continue our discussion about it.

I agree with j-harbott on this.

Decoupling the forward zone management from the PTR record management in neutron creates a security concern and doesn't really fit the purpose of this integration.

I think if we want to pursue this, it would require a significant change to the neutron integration (beyond the proposed patch) to address the security ramifications.

Essentially we would need to change the model where reverse zones are owned by the service account to a model where the reverse zones could be owned by the project creating the port. Thus, the user creating the port would require permission to update the reverse zone. At which point you will simply be automating the PTR record create call on behalf of the user creating the port.

Wouldn't it be easier to just make a call to designate to create the record rather than setting the name and domain on the port?

On the last drivers meeting (http://eavesdrop.openstack.org/meetings/neutron_drivers/2021/neutron_drivers.2021-03-19-14.00.log.html#l-30) we decided to approve this RFE as a concept.
But please now provide the spec with detailed information about this change.
It would be also great if that RFE can be implemented as new driver, without changing behavior of the existing driver at all.

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