DNS extensions reported as available even if not enabled

[Markus Hentsch]

# Summary

The Neutron Extensions API [^1] returns all possible DNS extensions even if the configured DNS extension driver for the ML2 plugin does not offer all of them or even if no DNS extension driver is enabled at all.
This is misleading to the user because it communicates features that aren't actually available depending on the backend configuration.

This is in contrast to other Neutron extensions (e.g. "uplink-status-propagation") where the Extensions API only returns the extension if it is actually enabled.

[^1]: https://docs.openstack.org/api-ref/network/v2/#id5

# Description

In the context of DNS functionality, Neutron has a hierarchy of extensions that supersede one another [^2]:

- dns-integration
- dns-domain-ports (includes dns-integration)
- subnet-dns-publish-fixed-ip (includes dns-integration and dns-domain-ports)
- dns-integration-domain-keywords (includes all others)

The "dns-integration" extension offers the least functionality and "dns-integration-domain-keywords" the most.
The `extension_drivers` setting of the ML2 plugin determines which extension will be active.
Thus, the actual DNS functionality range offered by Neutron depends on the selected extension driver.

The user documentation of Designate [^3] instructs users to query the Neutron Extensions API to determine the available functionality.
For the different use cases involving publishing fixed IP DNS records within user-created networks [^4], the documentation states: "Check that the subnet-dns-publish-fixed-ip Neutron extension is enabled.".

This suggests that the user should check for the "subnet-dns-publish-fixed-ip" extension in the Neutron Extensions API and if it is listed, they can expect the feature to work.

However, the Neutron Extensions API currently returns all DNS extensions regardless of which DNS extension driver is actually active. Even if none of them is active, all DNS extensions are still returned.
Depending on the individual configuration, this might communicate the availability of features to the user which aren't actually available.
In the case of the Designate documentation, this is especially misleading because it seems to assume that the extensions listed by Neutron API match the available functionality.

[^2]: https://docs.openstack.org/designate/latest/user/neutron-integration.html#neutron-dns-extensions

[^3]: https://docs.openstack.org/designate/latest/user/neutron-integration.html#dns-domain-ports

[^4]: https://docs.openstack.org/designate/latest/user/neutron-integration.html#dns-for-nova-server-instances

# How to reproduce

The following steps have been executed on a DevStack with Neutron @135cfa321549f04bc248dbcece45075fc59cfa67 and neutron-lib v3.11.0 with OVN-based configuration.

Consider the following example entry in `/etc/neutron/plugins/ml2/ml2_conf.ini`:

```
[ml2]
extension_drivers = port_security,qos,dns_domain_ports
```

Note: the behavior illustrated below stays the same even if `dns_domain_ports` is removed completely and no DNS extension driver is specified at all!

Either the OpenStack client can be used or API requests directly to list extensions:

```
# authenticate as user
$ source openrc demo demo

# check API extensions using client
$ openstack extension list --network -f value -c Alias | grep dns
dns-integration
dns-domain-ports
dns-integration-domain-keywords
subnet-dns-publish-fixed-ip

# check API extensions via direct HTTP request
$ TOKEN=$(openstack token issue -f value -c id)
$ curl -s -H "X-Auth-Token: $TOKEN" http://192.168.144.111:9696/networking/v2.0/extensions | jq | grep "alias.*dns"
      "alias": "dns-integration",
      "alias": "dns-domain-ports",
      "alias": "dns-integration-domain-keywords",
      "alias": "subnet-dns-publish-fixed-ip",
```

But the "subnet-dns-publish-fixed-ip" extension is not actually active:

```
$ openstack network create test-network
$ openstack subnet create --network test-network \
    --subnet-range 192.168.0.1/24 --dns-publish-fixed-ip test-subnet
$ openstack subnet show -f value -c dns_publish_fixed_ip test-subnet
None
```

In this case the `dns_publish_fixed_ip` attribute is returned as `None` and the documented behavior of DNS record publishing using Designate does not work.
This can also be verified by peeking into Neutron's database and observing that the "subnet_dns_publish_fixed_ips" table does not receive any entries.
Once the `dns_publish_fixed_ip` extension driver is enabled in `ml2_conf.ini`, the attribute will be returned as either `True` or `False` instead and the DNS record creation actually works.

# Counterexample (expected behavior)

The ML2 plugin shows a different behavior for the "uplink-status-propagation" extension.
The API will only list this extension if its extension driver actually enabled.
Documented below is the behavior of the "uplink-status-propagation" extension on the same DevStack environment.

Based on the following setting:

```
[ml2]
extension_drivers = port_security,qos
```

The extension "uplink-status-propagation" will not be listed by the Extensions API:

```
$ openstack extension list --network -f value -c Alias | grep uplink

```

Now, after adding the `uplink_status_propagation` extension driver like this:

```
[ml2]
extension_drivers = port_security,qos,uplink_status_propagation
```

... and restarting Neutron, the extension will now be listed by the Extensions API:

```
$ openstack extension list --network -f value -c Alias | grep uplink
uplink-status-propagation
```

[Slawek Kaplonski (slaweq)]

I think this may somehow leak due to the fact that it is mentioned in the https://github.com/openstack/neutron/blob/22a3384194e14ed2e7a2f3888cf5f107d0ecdb42/neutron/common/ovn/extensions.py as extension supported by the ovn driver. But that will need to be checked.