VM Reverse DNS Lookup Returns Wrong Domain Due to OVN DNS Interception

Problem

Virtual machines in Private Cloud Director Virtualization environments receive the wrong DNS search domain via DHCP. Short-name queries resolve against the global blueprint domain instead of the expected per-network or per-site domain, causing incorrect FQDNs in lookups and failures in site-specific name resolution. The issue affects both Linux and Windows guest operating systems. Virtual machines running on non-PCD hypervisors (for example, VMware) on the same network resolve correctly using the expected domain.

Running nslookup or dig from inside an affected virtual machine returns FQDNs constructed from the global blueprint domain:

Affected VM

$ nslookup <SHORT_NAME>
Server:         [DNS_SERVER_IP]
Address:        [DNS_SERVER_IP]#53

Name:   [SHORT_NAME].[GLOBAL_DOMAIN]
Address: [VM_IP_ADDRESS]

The search domain in the guest /etc/resolv.conf or Windows DNS settings reflects the global blueprint domain rather than the expected per-site or per-network domain.

Environment

• Private Cloud Director Virtualization — All versions
• Self-Hosted Private Cloud Director Virtualization — All versions
• Component: Networking Service, OVN ML2

Cause

The Networking Service OVN ML2 driver populates the OVN internal DNS table using the global dns_domain value from neutron.conf, regardless of any per-port DNS configuration. The dns_domain attribute on a Networking Service network object is used by the Designate (DNS as a Service) integration only — it does not configure DHCP Option 15 and has no effect on what virtual machines receive in /etc/resolv.conf. OVN intercepts all DNS queries originating from virtual machines at the logical switch level and answers from this internal table — the external authoritative DNS server is never consulted for these queries. Virtual machines therefore receive DHCP Option 15 (DNS domain suffix) derived from the global domain only. Per-port DHCP domain configuration via --extra-dhcp-option name=domain-name is not set by default. The only way to deliver the correct per-site domain to guests via DHCP is to configure this option explicitly on each port — or, after PCD-6289 is available, via the new per-network pf9_dhcp_domain attribute.

Diagnostics

1

Step 1 — Confirm the port DNS assignment shows the wrong domain

Retrieve the port attached to the affected virtual machine and inspect the dns_assignment field. The fqdn value reflects the global domain rather than the expected per-network domain.

OpenStack CLI

$ openstack port list --server <VM_UUID> -c id -c dns_assignment

Sample Output — Port dns_assignment with Incorrect Domain

+--------------------------------------+------------------------------------------------------------------------------------+
| id                                   | dns_assignment                                                                     |
+--------------------------------------+------------------------------------------------------------------------------------+
| [PORT_UUID]                          | [{"hostname": "[VM_HOSTNAME]", "ip_address": "[VM_IP]",                           |
|                                      |   "fqdn": "[VM_HOSTNAME].[GLOBAL_DOMAIN]."}]                                      |
+--------------------------------------+------------------------------------------------------------------------------------+

If the fqdn shows the global blueprint domain instead of the expected per-network domain, proceed to Step 2.

2

Step 2 — Confirm OVN is intercepting DNS queries locally using dig +trace

Run dig +trace from inside the affected virtual machine. An OVN-intercepted response returns in 0 ms from what appears to be the authoritative or root DNS server — an impossibly fast round-trip that confirms OVN is answering from its internal table rather than forwarding the query to the external DNS server. The returned FQDN also reflects the global domain, not the expected per-network domain.

Inside VM

$ dig +trace <SHORT_NAME>

Sample Output — OVN Intercepting DNS Locally

; <<>> DiG [VERSION] <<>> +trace [SHORT_NAME]

.                       518400  IN      NS      [ROOT_SERVER].
;; Received [BYTES] bytes from [DNS_SERVER_IP]#53([DNS_SERVER_IP]) in 0 ms

[EXPECTED_DOMAIN].      3600    IN      NS      [AUTHORITATIVE_NS].
;; Received [BYTES] bytes from [DNS_SERVER_IP]#53([DNS_SERVER_IP]) in 1 ms

[SHORT_NAME].[GLOBAL_DOMAIN].  300  IN  A  [VM_IP]
;; Received [BYTES] bytes from [DNS_SERVER_IP]#53([DNS_SERVER_IP]) in 0 ms

A response time of 0 ms at each delegation hop, combined with a returned FQDN using [GLOBAL_DOMAIN] rather than [EXPECTED_DOMAIN], confirms OVN is intercepting and answering the query locally. A correctly resolving virtual machine would show non-zero round-trip times with a full delegation chain to the authoritative DNS server.

3

Step 3 — Confirm no per-port DHCP domain-name option is configured

Verify that the affected virtual machine port does not have a domain-name DHCP option set via extra_dhcp_opts. An empty result confirms no per-port override has been applied and the guest is receiving the global domain via DHCP by default.

OpenStack CLI

$ openstack port show <PORT_UUID> -c extra_dhcp_opts

Sample Output — No per-port DHCP domain configured (issue confirmed)

+------------------+-------+
| Field            | Value |
+------------------+-------+
| extra_dhcp_opts  | []    |
+------------------+-------+

An empty extra_dhcp_opts field confirms that no domain-name DHCP option has been set on this port. Proceed to Step 4.

The dns_domain attribute visible on openstack network show is used by the Designate (DNS as a Service) integration only. Setting it does not configure DHCP Option 15 and does not affect the domain name delivered to virtual machines via DHCP.

4

Step 4 — Verify OVN DNS records use the global domain

Inspect the OVN NB database DNS table to confirm that records are populated with the global domain rather than the per-network domain.

Self-Hosted only: This step requires direct access to the control plane. SaaS customers cannot perform this step independently — contact Platform9 Support to have this completed on your behalf.

Control Plane Node

$ kubectl exec -n <REGION_NS> <OVN_NORTHD_POD> -- ovn-nbctl list DNS

Sample Output — OVN DNS Records Using Global Domain

_uuid               : [DNS_RECORD_UUID]
external_ids        : {neutron:network_id="[NETWORK_UUID]"}
records             : {"[VM_HOSTNAME].[GLOBAL_DOMAIN]"="[VM_IP]"}

DNS entries in the OVN NB table using the global domain instead of the expected per-network domain confirm the root cause.

5

Step 5 — Confirm OVN DNS interception at the OVS flow level

On the compute host running the affected virtual machine, inspect the Open vSwitch flow table to confirm that OVN has installed a flow rule intercepting all UDP DNS traffic (port 53) before it reaches the physical network.

Compute Host

$ ovs-ofctl dump-flows br-int table=32 | grep "tp_dst=53"

Sample Output — OVN DNS Intercept Flow Rule Present

cookie=0x0, duration=[DURATION]s, table=32, n_packets=[PACKET_COUNT], n_bytes=[BYTE_COUNT], priority=100,udp,tp_dst=53 actions=controller(userdata=[USERDATA],pause)

The presence of a flow rule at table=32 with tp_dst=53 and actions=controller(...pause) confirms that OVN is intercepting all UDP DNS queries at the logical switch. A non-zero n_packets count indicates that DNS traffic has already been intercepted. Virtual machines running on non-PCD hypervisors (for example, VMware) on the same network do not have this flow rule and resolve DNS correctly through the external authoritative server.

If all checks above match, proceed to Workaround.

Resolution

PCD-6289 introduces a new Networking Service network attribute pf9_dhcp_domain that allows DHCP Option 15 (DNS search domain) to be configured per-network. This replaces the need for per-port --extra-dhcp-option name=domain-name configuration. However, PCD-6289 does not stop OVN from intercepting DNS queries — OVN DNS interception continues to operate after this change. A complete resolution requires both setting pf9_dhcp_domain per-network (once PCD-6289 is available in Private Cloud Director Virtualization 2026.AUG) and removing the dns_domain_ports extension driver to disable OVN DNS interception. In the meantime, use the Workaround below.

Workaround

The workaround requires two actions applied together. First, set the correct DHCP domain name on each affected virtual machine port (Step 2). Second, remove the dns_domain_ports OVN ML2 extension driver from the Networking Service configuration (Steps 3–6). Setting the per-port domain name alone does not stop OVN from intercepting DNS queries — reverse lookups continue to return the global domain until the extension driver is removed. Both steps are required for full resolution.

Removing the dns_domain_ports extension driver disables OVN-internal DNS resolution entirely. After applying this workaround, virtual machines cannot resolve each other by hostname using OVN's internal table — all name resolution relies on the external DNS servers specified in the subnet dns_nameservers field. Confirm that external DNS entries exist for all virtual machines that require hostname-based access before proceeding.

1

Step 1 — Verify all affected subnets have external DNS nameservers configured

Before proceeding, confirm that every subnet in the affected region has dns_nameservers pointing to an authoritative external DNS server. Subnets with no dns_nameservers configured will have no DNS resolution for hosted virtual machines after the workaround is applied.

OpenStack CLI

$ openstack subnet list --network <NETWORK_UUID> -c id -c name -c dns_nameservers

Sample Output — Subnet DNS Nameservers

+--------------------------------------+---------------+------------------+
| id                                   | name          | dns_nameservers  |
+--------------------------------------+---------------+------------------+
| [SUBNET_UUID]                        | [SUBNET_NAME] | [DNS_SERVER_IP]  |
+--------------------------------------+---------------+------------------+

The dns_nameservers field must be non-empty for all subnets where virtual machines must resolve DNS. If any subnet has an empty dns_nameservers field, add the authoritative DNS server IP before proceeding:

OpenStack CLI

$ openstack subnet set --dns-nameserver <DNS_SERVER_IP> <SUBNET_UUID>

2

Step 2 — Set the correct DHCP domain-name on affected virtual machine ports

For each affected virtual machine port, set the domain-name DHCP option to the expected per-site domain using the --extra-dhcp-option flag. This configures DHCP Option 15 on the port and updates the guest OS /etc/resolv.conf search domain on the next DHCP lease renewal or virtual machine reboot.

OpenStack CLI

$ openstack port set <PORT_UUID> --extra-dhcp-option name=domain-name,value=<EXPECTED_DOMAIN>

Confirm the option is set:

OpenStack CLI

$ openstack port show <PORT_UUID> -c extra_dhcp_opts

Sample Output — DHCP domain-name option confirmed

+------------------+-----------------------------------------------------------------------------------+
| Field            | Value                                                                             |
+------------------+-----------------------------------------------------------------------------------+
| extra_dhcp_opts  | [{"opt_name": "domain-name", "opt_value": "<EXPECTED_DOMAIN>", "ip_version": 4}] |
+------------------+-----------------------------------------------------------------------------------+

After applying this option, renew the DHCP lease inside the virtual machine or reboot it to pick up the updated domain. Forward short-name lookups from inside the guest will now resolve correctly. Reverse lookups will still return the global domain until the dns_domain_ports extension driver is removed in the following steps.

After PCD-6289 is available, the pf9_dhcp_domain attribute can be set per-network instead of requiring per-port configuration:

$ openstack network set --pf9-dhcp-domain <EXPECTED_DOMAIN> <NETWORK_UUID>

3

Step 3 — Remove dns_domain_ports from the Networking Service ML2 extension drivers

Edit the Networking Service ML2 configuration to remove dns_domain_ports from the extension_drivers list in the [ml2] section of ml2_conf.ini. On Self-Hosted deployments, this configuration is stored in a Kubernetes ConfigMap or Secret in the region namespace.

Self-Hosted only: This step requires direct access to the control plane. SaaS customers cannot perform this step independently — contact Platform9 Support to have this completed on your behalf.

Locate the ConfigMap or Secret containing ml2_conf.ini:

Control Plane Node

$ kubectl get configmap -n <REGION_NS> | grep -i ml2
$ kubectl get secret -n <REGION_NS> | grep -i ml2

Edit the configuration and remove dns_domain_ports from the extension_drivers line:

ml2_conf.ini — Before

[ml2]
extension_drivers = port_security,qos,dns_domain_ports

ml2_conf.ini — After

[ml2]
extension_drivers = port_security,qos

Apply the updated ConfigMap or Secret to the cluster after saving the change.

4

Step 4 — Restart the Networking Service

Restart the Networking Service deployment to load the updated ML2 configuration.

Self-Hosted only: This step requires direct access to the control plane. SaaS customers cannot perform this step independently — contact Platform9 Support to have this completed on your behalf.

Control Plane Node

$ kubectl rollout restart deployment/neutron-server -n <REGION_NS>
$ kubectl rollout status deployment/neutron-server -n <REGION_NS>

Sample Output — Networking Service Restart Successful

deployment.apps/neutron-server successfully rolled out

Wait for the rollout to complete fully before proceeding to Step 5.

5

Step 5 — Clear existing OVN DNS records from all logical switches

After restarting the Networking Service, clear existing OVN DNS records from every logical switch in the region. Without this step, previously created DNS records remain in the OVN NB database and virtual machines continue to receive the wrong domain until the next port operation triggers a rebuild.

Self-Hosted only: This step requires direct access to the control plane. SaaS customers cannot perform this step independently — contact Platform9 Support to have this completed on your behalf.

List all OVN NB DNS records to identify the network UUIDs requiring cleanup:

Control Plane Node

$ kubectl exec -n <REGION_NS> <OVN_NORTHD_POD> -- ovn-nbctl list DNS

Sample Output — OVN DNS Records Before Cleanup

_uuid               : [DNS_RECORD_UUID_1]
external_ids        : {neutron:network_id="[NETWORK_UUID_1]"}
records             : {"[VM_HOSTNAME_1].[GLOBAL_DOMAIN]"="[VM_IP_1]"}

_uuid               : [DNS_RECORD_UUID_2]
external_ids        : {neutron:network_id="[NETWORK_UUID_2]"}
records             : {"[VM_HOSTNAME_2].[GLOBAL_DOMAIN]"="[VM_IP_2]"}

Note each [NETWORK_UUID] value from the external_ids field. Clear the DNS records for each affected logical switch. Run the following command once per network UUID:

Control Plane Node

$ kubectl exec -n <REGION_NS> <OVN_NORTHD_POD> -- \
  ovn-nbctl clear logical_switch neutron-<NETWORK_UUID> dns_records

Confirm all DNS records have been cleared:

Control Plane Node

$ kubectl exec -n <REGION_NS> <OVN_NORTHD_POD> -- ovn-nbctl list DNS

Sample Output — OVN DNS Records Cleared

(no output)

6

Step 6 — Verify DNS resolution from inside an affected virtual machine

Log in to a previously affected virtual machine and confirm DNS resolution now returns the correct domain. The query must reach the external authoritative DNS server and return the expected per-site FQDN.

Inside VM

$ nslookup <SHORT_NAME>

Sample Output — DNS Resolution Using Correct Domain

Server:         [DNS_SERVER_IP]
Address:        [DNS_SERVER_IP]#53

Name:   [SHORT_NAME].[EXPECTED_DOMAIN]
Address: [VM_IP_ADDRESS]

The returned FQDN must use the expected per-site or per-network domain, not the global blueprint domain. DNS resolution is confirmed as working correctly.

Additional Information

This issue is tracked in PCD-6289. PCD-6289 introduces the pf9_dhcp_domain network attribute for per-network DHCP domain configuration. It does not stop OVN from intercepting DNS queries — removing the dns_domain_ports extension driver is still required to disable OVN DNS interception.

• The dns_domain_ports OVN ML2 extension driver enables per-port DNS hostname assignment and populates OVN's internal DNS table. Removing this driver stops OVN from intercepting DNS queries but also disables OVN-internal hostname resolution between virtual machines. After applying this workaround, all hostname-based communication between virtual machines must rely on external DNS entries.
• OVN DNS records are automatically regenerated on any port operation (create, update, or delete). Running ovn-nbctl clear logical_switch neutron-<NETWORK_UUID> dns_records alone provides only temporary relief — the permanent solution is to remove dns_domain_ports from the Networking Service extension_drivers and restart the Networking Service before clearing OVN records.
• Setting --extra-dhcp-option name=domain-name,value=<EXPECTED_DOMAIN> on individual ports (not subnets) configures DHCP Option 15 and updates the guest OS /etc/resolv.conf search domain on the next DHCP lease renewal. This corrects forward short-name lookups within the guest but does not stop OVN from intercepting DNS queries — reverse lookups continue to return the global FQDN. Both the per-port domain-name option and removing the dns_domain_ports extension driver are required for complete resolution.
• The dns_domain attribute on a Networking Service network object (visible via openstack network show -c dns_domain) is used exclusively by the Designate (DNS as a Service) integration. It does not configure DHCP Option 15 and has no effect on the search domain delivered to virtual machines via DHCP or on OVN internal DNS table entries. Setting openstack network set --dns-domain will not resolve this issue.
• If DNS resolution remains incorrect after applying the workaround, contact Platform9 Support for assistance.