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

Bug #1904559 reported by Sergei Chekanov on 2020-11-17
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Unassigned

Bug Description

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

I want to create PTR record for IP, if dns_domain zone was not created in designate.

# setting up dns for port
openstack port set --dns-name smtp --dns-domain company.com. 545f1e96-39ea-4ce9-8119-a9044c94e871

# getting error
ERROR neutron.plugins.ml2.extensions.dns_integration neutron_lib.exceptions.dns.DNSDomainNotFound: Domain company.com. not found in the external DNS service

Sometimes I don't want (or do not have access) to create zone company.com, but need PTR record for IP, usually for smtp server working.

I can offer my fix for neutron/services/externaldns/drivers/designate/driver.py, if it is acceptable.

Revision history for this message
Jakub Libosvar (libosvar) wrote :

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

Changed in neutron:
importance: Undecided → Medium
tags: added: dns
Revision history for this message
Sergei Chekanov (sergeychekanov) wrote :
Revision history for this message
Sergei Chekanov (sergeychekanov) wrote :

Please review.

Revision history for this message
Dr. Jens Harbott (j-harbott) wrote :

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.

Changed in neutron:
status: New → Incomplete
Revision history for this message
Sergei Chekanov (sergeychekanov) wrote :

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?

Revision history for this message
Dr. Jens Harbott (j-harbott) wrote :

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.

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

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.

tags: added: rfe
Changed in neutron:
status: Incomplete → New
importance: Medium → Wishlist
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

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

Revision history for this message
Sergei Chekanov (sergeychekanov) wrote :

Will try to be online tomorrow meeting time.

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

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.

Revision history for this message
Michael Johnson (johnsom) wrote :

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?

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

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.

tags: added: rfe-approved
removed: rfe
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers