[RFE][OVN] Support DNS subdomains at a network level

[Elvira García Ruiz]

Right now we can only set domain names at a global level, using the dns_domain parameter neutron.conf file.

However, there are use cases where it is useful to provide more granularity to DNS, like at a network or port level where the dns_domain attribute exists.
This is feasible with the OVN driver because OVN sets the DNS naming at a port level:

[root@controller-0 /]# ovn-nbctl list DNS
_uuid : 9f8ce4cf-29b2-4118-84e8-f269b86f423c
external_ids : {ls_name=neutron-b857b04d-005e-44d7-8766-c440ec665715}
records : {server1="192.168.100.12", server1.example.org="192.168.100.12", server2="192.168.100.120", server2.example.org="192.168.100.120"}

Thus, we could create an option to allow DNS using network naming as subdomains.
e.g.:

Global dns_domain: example.org
Networks: net-a, net-b
Server in Network A: server1
Server in Network B: server1
FQDN for server1 in network A: server1.net-a.example.org
FQDN for server1 in network B: server1.net-b.example.org

This would allow servers from different networks with the same name to have unique FQDNs, as opposed to the current approach were we would get the same FQDN in both cases: server1.example.org

[Arian Nadir Sersale (arnaser)]

In a multitenant environment, where the OpenStack admin(s) has(have) limited control over what users can do, there are at least two use cases that could greatly benefit from this RFE:

1) different users working on different projects use common hostnames for their VMs (server1, web001,…) which leads to a FQDN conflict. As users don’t even know the hostnames other VMs have, they may inadvertently cause trouble with an unexpected FQDN clash;

2) users working on different stages of the same application may want to re-use hostnames and simply distinguish stages based on the subdomain. Example: app001.uat.example.com (for UAT) vs app001.prd.example.com (for Production) both have the same hostname.

This kind of advantage is even greater in environments where (non-shared, provider) networks are already mapped to OSP projects, for example for IPAM purposes. Such a 1:1 subnet:project mapping could translate, under this RFE, in a further 1:1 subnet:subdomain cardinality, which would allow anyone to immediately identify, given an FQDN, what project that VM belongs to, improving visibility, troubleshooting (think log parsing),…

Alternative approaches relying on cloud-init obviously don’t work on VMs not supporting cloud-init (virtual appliances, Windows,…). Once again, in a multitenant IaaS the OpenStack provider doesn’t necessarily control the images that are being deployed.

A native solution at the Neutron/OVN layer would be the best fit in these scenarios.

[Lajos Katona (lajos-katona)]

during the last drivers meeting (see [0]) the agreement was to accept the RFE and continue the discussion in a spec review.

[0]: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-02-25-14.00.log.html#l-67

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-specs/+/832658

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Elvira García Ruiz <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron-specs/+/832658
Reason: There is no known use case for this feature right now. We will retake it whenever it is needed.

[Mikhail Stolyarov (toggetit)]

Hello!
It's my (honestly not only mine - in my local community many people try to resolve this issue but no one report it officially! =)
Please take a look at this simple patch
https://review.opendev.org/c/openstack/neutron/+/878820