[RFE] no relation exists to set upstream DNS servers based on server pools managed by designate

[Dmitrii Shcherbakov]

There is currently a config option called "dns-servers" to set nameserver IP addresses used by dnsmasq as forwarders.

https://github.com/openstack/charm-neutron-openvswitch/blob/stable/18.02/config.yaml#L102-L108

Providing those addresses via config is far from being flexible if Designate is used with a managed pool of servers (e.g., provided by designate-bind charm).

instance -> dnsmasq -> bind9 (managed by designate-bind charm) -> upstream DNS server

In order to provide external name resolution for instances designate-bind charm also needs to configure recursion in bind9 config (currently recursion is disabled) and allow queries from IP addresses of compute nodes hosting dnsmasq daemons.

NOTE: given that designate can manage multiple pools of different backends (e.g. bind9, InfoBlox, PowerDNS etc.) it makes sense to consider providing dns-servers via a neutron-ovs <-> designate relation.

[Nobuto Murata (nobuto)]

> In order to provide external name resolution for instances designate-bind charm also needs to configure recursion in bind9 config (currently recursion is disabled) and allow queries from IP addresses of compute nodes hosting dnsmasq daemons.

FWIW, Dmitrii opened another bug around recursive name resolution as:
https://bugs.launchpad.net/charm-designate-bind/+bug/1776952

It can be discussed there instead of the scope of designate-neutron relation to pass forwarders.

[Nobuto Murata (nobuto)]

> instance -> dnsmasq -> bind9 (managed by designate-bind charm) -> upstream DNS server

This is actually:
instance -> dnsmasq -> Neutron router or provider router -> bind9 (managed by designate-bind) -> upstream DNS server

Because dnsmasq is in fixed IP ranges or VLAN provider ranges. In that case, I don't think there is a way to determine a proper IP address of designate-bind to be passed to dnsmasq if a designate-bind unit has multiple addresses. Because the network ranges of "Neutron router or provider router" are managed outside of Juju model so no relation or network bindings to detect that.

[Nobuto Murata (nobuto)]

Hope the attached diagram makes sense why those relations would be impossible (provider range is outside of Juju model).

[Nobuto Murata (nobuto)]

> Hope the attached diagram makes sense why those relations would be impossible (provider range is outside of Juju model).

Although IP address determination with relations would be impossible, extra-binding based determination would work because most of the OpenStack charms uses "public" extra bindings to determine which address to be passed to other services as a public endpoint.

So in this case, designate-bind's "dns-frontend" extra binding could be used to set forwarders for other services.
https://git.openstack.org/cgit/openstack/charm-designate-bind/commit/?id=af9f3e79b560776ba3640d987dffb173c9504b5c

[Pedro Guimarães (pguimaraes)]

Think the best approach is to define extra-binding network(s) as allowed_recursion_nets when recursion is set and allowed_recursion_nets is empty. That way, if a user wants to expose BIND to the internet and have anyone using it as recursive DNS server, the user must define allowed_recursion_nets=any.

[Dmitrii Shcherbakov (dmitriis)]

As discussed with Pedro on IRC, what we could do is:

* create dns-provider relations between neutron-{openvswitch,gateway} and designate-bind to export designate-bind endpoints to the neutron-related charms - this will allow us to bind this "dns-provider" endpoint to a space on the designate-bind side (no need for extra-bindings) and provide values to configure dnsmasq via the dhcp agent .ini file with designate-bind IP addresses only known after the deployment (especially since we deploy designate-bind into containers that get addresses allocated dynamically);
* document a requirement that network engineers should route traffic from provider network subnets to a network space used in "dns-provider" endpoint binding;
* document a requirement that for recursion ACLs to be populated operators need to reconfigure designate-bind according to provider network subnets that will be used.

This approach allows us to avoid requiring deployers/operators to configure dns-servers at the post-deployment stage due to dynamic LXD IP address allocations. Provider network subnets for ACLs, on the other hand, can be present at the design stage and placed into bundles before the deployment.

This removes the need for post-deployment actions which is what we are trying to achieve here.

[Nobuto Murata (nobuto)]

> this will allow us to bind this "dns-provider" endpoint to a space on the designate-bind side (no need for extra-bindings)

> * document a requirement that network engineers should route traffic from provider network subnets to a network space used in "dns-provider" endpoint binding;

This suggests that the relation between designate-bind and neutron-{gateway,openvswitch} has to be on a routable network, and non-routable (isolated) network cannot be used. Also, the host OS of neutron-gateway/openvswitch will be exposed as routable from provider networks which is unnecessary.

I may be missing something, but extra-binding sounds straightforward since vlan provider networks are managed outside of Juju model anyway.

[Nobuto Murata (nobuto)]

https://review.openstack.org/#/q/topic:bug/1773377

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/597021

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/597029

[Drew Freiberger (afreiberger)]

While this relation is very useful, I think it stops short of addressing an additional concern with having to update upstream DNS conditional forwarders when designate-bind is redeployed/units added/updated.

I've opened lp#1804057 that is semi-related, but definitely a different request.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/630947

[OpenStack Infra (hudson-openstack)]

Change abandoned by Pedro Guimarães (<email address hidden>) on branch: master
Review: https://review.openstack.org/630947

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Billy Olsen <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/charm-neutron-openvswitch/+/597029
Reason: Patch has -1 comments not addressed in over 6 months. Please address comments and resubmit.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "James Page <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/charm-designate-bind/+/597009
Reason: This review is > 12 weeks without comment, and failed testing the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "James Page <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/charm-neutron-gateway/+/597021
Reason: This review is > 12 weeks without comment, and failed testing the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.