[Wishlist] Configurable Service IPs for bind servers

Bug #1804057 reported by Drew Freiberger on 2018-11-19
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Designate-Bind Charm
Wishlist
Unassigned

Bug Description

Given an environment where openstack's designate is configured in a corporate DNS structure (or even registrar NS data) as the conditional forwarder for a given domain/set of domains, the upstream DNS or registrar entries must have static IPs to point to for the canonical reference for those zones.

Example:

zone example.org.
  ns1.example.org A 10.0.0.10
  ns2.example.org A 10.0.0.11

Given the typical situation of having two designate-bind9 units running, and running bind in a container or VM in the juju environment, the addresses assigned to the units' dns-frontend space binding will not necessarily stay the same (you can't preselect LXD IPs in MAAS deploys, and likely can't preselect IPs in VM deploys in clouds). When we need to recover or rebuild the designate-bind servers/service units, we will get new IPs that then would have to be populated back into upstream DNS or registrars.

I'd suggest that we add a "service_ips" config option to designate-bind charm to configure as IPs for the designate-bind units. To illustrate the possible solution:

Spaces:
  internal: 192.168.0.0/24
  external: 10.0.0.0/24 (dhcp range 10.0.0.20-10.0.0.254, reserved range 10.0.0.1 - 10.0.0.19)

designate-bind:
  bindings:
    "": internal
    dns_backend: internal
    dns_frontend: external
  options:
    num_units: 2
    service_ips: 10.0.0.10 10.0.0.11

Deploy the two units, they get 10.0.0.20 and 10.0.0.21. The first unit inteh cluster would then take the 10.0.0.10 IP address of the service_ips stack and mark it used in the cluster relation data, then the second unit would use the 10.0.0.11 address and mark it used in the cluster relation data. The units would then configure the IPs as additional addresses on the interface where the dns_frontend ip space is bound, and then advertises and configures any front-end relations and listeners to listen on the service_ips instead of the ips auto-assigned by the binding to dns_frontend.

This would allow us to recover designate-bind services without having to update upstream forwarding rules or registrar data which both run much more slowly with updates than juju/cloud iterations, depending on SOA, record timeouts, etc.

Drew Freiberger (afreiberger) wrote :

FYI, this is semi-related to lp#1773377 where we're looking to pass dns_frontend IPs to n-ovs and n-gw charms via relation. Instead of this, we can workaround by using/configuring these vips/service_ips and just manually configure the IPs in all three charms plus squash an upstream no-relation-available issu with this feature.

summary: - [Wishlist] VIP/Overlay IPs for bind servers
+ [Wishlist] Service IPs for bind servers
summary: - [Wishlist] Service IPs for bind servers
+ [Wishlist] Configurable Service IPs for bind servers
Dmitrii Shcherbakov (dmitriis) wrote :

My 2 cents:

1) containers are registered as generic "devices" with interfaces with nodes set as parent devices in MAAS by juju during provisioning;
2) there is no way to specify device placeholders with fixed IPs similar to how static IPs can be assigned to nodes;
3) as a workaround, a VLAN with a small subnet for the "dns-access" space can be used. In that subnet, all extra IPs can be added to a reserved range so that there are only as many usable IPs as there are designate bind units. One additional IP will be used for a VLAN bridge on a host, one IP will be used for an L3 gateway. This seems like a good deployment-time workaround.

James Page (james-page) wrote :
James Page (james-page) wrote :

I'm not very keen on the approach of adding more out-of-band management of IP addresses via charm config - just like VIP's, having IP via config is brittle and prone to error. How much of a problem is this really? I appreciate that having to update DNS pointers in upstream DNS systems to point to new bind servers in the deployment is *work*.

Changed in charm-designate-bind:
status: New → Incomplete
importance: Undecided → Wishlist
Drew Freiberger (afreiberger) wrote :

I think we could have this debate for a while about the work/changes involved. This is a pain point for every cloud handover to bootstack. the customer tests DNS with one set of bind IPs with Field Engineering, then Bootstack redeploys getting new bind IPs (without Dmitrii's workaround subnet).

Work required sometimes spans many groups and many services, though. You've got corporate DNS which is controlled outside the juju model, you've potentially got internic/whois records, if it's a public cloud which take X hours/days to update, you've got firewalls/ACLs to reconfigure, and you have to bounce neutron-gateway/n-ovs for dhcp-agent dns-server updates for dnsmasq. All of these are risks when what may have happened was a box hosting a bind server died and needed to be rebuilt.

I take the point of not wanting to add more ip management in the charm, but right now, DNS is brittle without statically assignable IPs, as it is the one service that can't be referenced by external name records.

Another solution is to deploy KVMs with static IPs on the infra nodes for bind, but that would require those VMs to be able to be deployable within two zones (which maas pods don't do).

I think the issue is less work-effort, and more about time to restore service based on the different things that plug into DNS that have to be reconfigured and aren't under the control of the cloud operator.

Changed in charm-designate-bind:
status: Incomplete → New
James Page (james-page) on 2019-03-11
Changed in charm-designate-bind:
status: New → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers