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

Bug #1773377 reported by Dmitrii Shcherbakov on 2018-05-25
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Designate Charm
Medium
Pedro Guimarães
OpenStack Designate-Bind Charm
Medium
Pedro Guimarães
OpenStack neutron-gateway charm
Medium
Pedro Guimarães
OpenStack neutron-openvswitch charm
Medium
Pedro Guimarães

Bug Description

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.

description: updated
James Page (james-page) on 2018-06-18
Changed in charm-designate:
status: New → Triaged
Changed in charm-designate-bind:
status: New → Triaged
Changed in charm-neutron-openvswitch:
status: New → Triaged
Changed in charm-designate:
importance: Undecided → Medium
Changed in charm-designate-bind:
importance: Undecided → Medium
Changed in charm-neutron-openvswitch:
importance: Undecided → Medium
Changed in charm-designate:
milestone: none → 18.08
Changed in charm-designate-bind:
milestone: none → 18.08
Changed in charm-neutron-openvswitch:
milestone: none → 18.08
Changed in charm-designate:
assignee: nobody → Pedro Guimarães (pguimaraes)
Changed in charm-designate-bind:
assignee: nobody → Pedro Guimarães (pguimaraes)
Changed in charm-neutron-openvswitch:
assignee: nobody → Pedro Guimarães (pguimaraes)
Nobuto Murata (nobuto) wrote :

> 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) wrote :

> 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) wrote :

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

Nobuto Murata (nobuto) wrote :

> 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) wrote :

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.

Changed in charm-neutron-gateway:
assignee: nobody → Pedro Guimarães (pguimaraes)
milestone: none → 18.08
Dmitrii Shcherbakov (dmitriis) wrote :

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) wrote :

> 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.

Changed in charm-designate-bind:
status: Triaged → In Progress

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

Changed in charm-neutron-gateway:
status: New → In Progress

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

Changed in charm-neutron-openvswitch:
status: Triaged → In Progress
James Page (james-page) on 2018-09-12
Changed in charm-neutron-gateway:
milestone: 18.08 → 18.11
James Page (james-page) on 2018-09-12
Changed in charm-neutron-openvswitch:
milestone: 18.08 → 18.11
Changed in charm-designate:
milestone: 18.08 → 18.11
Changed in charm-designate-bind:
milestone: 18.08 → 18.11
Xav Paice (xavpaice) on 2018-09-13
tags: added: canonical-bootstack
Drew Freiberger (afreiberger) wrote :

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.

James Page (james-page) on 2018-11-20
Changed in charm-neutron-openvswitch:
milestone: 18.11 → 19.04
Changed in charm-designate:
milestone: 18.11 → 19.04
Changed in charm-designate-bind:
milestone: 18.11 → 19.04
Changed in charm-neutron-gateway:
milestone: 18.11 → 19.04
James Page (james-page) on 2018-12-04
Changed in charm-neutron-gateway:
importance: Undecided → Medium

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

David Ames (thedac) on 2019-04-17
Changed in charm-neutron-openvswitch:
milestone: 19.04 → 19.07
Changed in charm-designate:
milestone: 19.04 → 19.07
Changed in charm-designate-bind:
milestone: 19.04 → 19.07
Changed in charm-neutron-gateway:
milestone: 19.04 → 19.07
David Ames (thedac) on 2019-08-12
Changed in charm-neutron-openvswitch:
milestone: 19.07 → 19.10
Changed in charm-designate:
milestone: 19.07 → 19.10
Changed in charm-designate-bind:
milestone: 19.07 → 19.10
Changed in charm-neutron-gateway:
milestone: 19.07 → 19.10
David Ames (thedac) on 2019-10-24
Changed in charm-neutron-openvswitch:
milestone: 19.10 → 20.01
Changed in charm-designate:
milestone: 19.10 → 20.01
Changed in charm-designate-bind:
milestone: 19.10 → 20.01
Changed in charm-neutron-gateway:
milestone: 19.10 → 20.01
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers