[OVN] DNS resolution not forwarded with OVN driver

[Nate Johnston]

With ML2/OVS and ML2/LB, instances on tenant networks can resolve in-cloud and external DNS names even if the tenant network has no router or outside connectivity. It does this via the dnsmasq instance being configured as the DNS resolver for the instances. A DNS request from an instance on one of these private networks will go to dnsmasq. If the address is not in the list of static addresses populated in dnsmasq by neutron, it will then resolve the request using either configured resolvers or the host resolver. This is use case 2 in the DNS Resolution for Instances document [1].

With ML2/OVN, there is no dnsmasq instance. In this case, the request is "hijacked" by OVN, and if there is a static record that matches, it will respond with the static entry. If there is no matching static record, instances without connectivity to the "8.8.8.8" DNS server that is default in the OVN DHCP packet cannot resolve DNS. This means that these instances cannot utilize DNS records published by Designate.

The lack of a masquerading forwarding DNS resolver available to instances on isolated tenant networks is the feature parity gap between ML2/OVS and ML2/OVN this bug requests be fixed. The driver for this is to allow instances on isolated tenant networks to use DNS published by Designate.

[1] https://docs.openstack.org/neutron/latest/admin/config-dns-res.html#case-2-dhcp-agents-forward-dns-queries-from-instances

Evidence:

On the host:
$ nslookup www.redhat.com
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
www.redhat.com canonical name = ds-www.redhat.com.edgekey.net.
ds-www.redhat.com.edgekey.net canonical name =
ds-www.redhat.com.edgekey.net.globalredir.akadns.net.
ds-www.redhat.com.edgekey.net.globalredir.akadns.net canonical name =
e3396.dscx.akamaiedge.net.
Name: e3396.dscx.akamaiedge.net
Address: 23.64.196.72
Name: e3396.dscx.akamaiedge.net
Address: 2600:1409:12:39e::d44
Name: e3396.dscx.akamaiedge.net
Address: 2600:1409:12:383::d44

#### So host name resolution is working correctly.

On a guest on a tenant network:

# nslookup webserver1
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: webserver1.openstackgate.local
Address: 172.21.1.154

#### It can resolve itself.

# nslookup webserver2
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: webserver2.openstackgate.local
Address: 172.21.1.31

### It can resolve other VMs

# nslookup www.redhat.com
;; connection timed out; no servers could be reached

#### It cannot resolve anything that is not in the OVN DB. This is the problem.

[Daniel Alvarez (dalvarezs)]

It looks to me that we can somehow unblock this use case for now by deploying Neutron DHCP Agent.

In the long haul, perhaps we can explore an RFE in core OVN to send DNS requests to an external bridge when there's no gateway :?

[Dr. Jens Harbott (j-harbott)]

One would also have to have a way to disable DNS and DHCP within OVN for the subnet, otherwise responses from the Neutron DHCP Agent will conflict with responses generated by OVN.

[sean mooney (sean-k-mooney)]

you could argue the ML2/OVS and ML2/LB bevhior is incorrect and actuly a security issue.

https://www.checkpoint.com/cyber-hub/network-security/what-is-dns-tunneling/

in the case of ML2/OVS and ML2/LB the isolated networks are not actually properly isolated and are vulnerable to DNS tunneling attacks.

ML2/OVN is more correctly respecting what the user asked for
An isolated network that is not routable for any traffic.

the only exception to that would be if the network was marked as external.
in that case there could be an expectation that routablity has been provided by the datacenter admin external to neutrons API.

but for normal tenant networks i think OVN is actually doing the right thing by not allowing DNS form the isolated networks.

[sean mooney (sean-k-mooney)]

for what its worth if you wish to address this in neutorn i would consider it a Feature not a bug and a feature that a user should be able to enable or disable on a subnet or network level.