yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #84313
[Bug 1902950] [NEW] [OVN] DNS resolution not forwarded with OVN driver
Public bug reported:
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.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: dns ovn
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1902950
Title:
[OVN] DNS resolution not forwarded with OVN driver
Status in neutron:
New
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1902950/+subscriptions
