[OVN] DNS resolution not forwarded with OVN driver

Bug #1902950 reported by Nate Johnston
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
neutron
New
Medium
Elvira García Ruiz

Bug Description

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.

Tags: dns ovn
Changed in neutron:
importance: Undecided → Medium
Revision history for this message
Daniel Alvarez (dalvarezs) wrote :

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 :?

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

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.

Changed in neutron:
assignee: nobody → Elvira García Ruiz (elviragr)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.