Issues integrating MAAS DNS into a large corporate environment

Hi, all.

I’ve run into a few difficulties trying to get MAAS DNS configured correctly.

1) I cannot set the SOA RNAME to a suitable (encoded) email address

Rationale:

When asking our DNS administrators for the zones to be delegated to MAAS, they request a valid email address in the SOA with which to contact us in the event of issues with the zone.

Issues:

Suggestions:

  • Make it configurable (globally and/or per-domain).
  • Make the template customisable.

2) There’s only one NS record for master region controller (and I can’t name it)

Rationale:

Our DNS administrators expect at least two DNS servers for a zone (and want to match the glue NS records in the parent zone to the NS records in the zone)

Issues:

  • Despite having HA enabled with a second region controller, only one NS record is automatically generated (for the master).
  • Adding additional NS records (with maas [profile] dnsresource-records create domain=[domain_id] name=@ rrtype=ns rrdata=[hostname]) works… but the default record is still present (it’s in the template). This also only works for forward (host-to-ip) domains, adding a reverse (ip-to-host) domain is accepted but records added to it seem to be ignored. Update: also, creating a reverse zone (to add NS records to) breaks MAAS’s BIND as there are now two entries for the reverse zone in named.conf.

Suggestions:

  • Add NS records for additional region controllers (preferably with a customisable hostname, e.g. “ns” producing “ns1” and “ns2”)
  • Make the NS records consistently configurable (globally and/or per-domain); make sure they work in (automatically-generated) reverse zones.
  • If NS records are present, suppress any auto-generated ones (and their associated A records).
  • Make the template customisable.

3) I can’t (correctly) slave a zone from MAAS

Rationale:

It’s easier for us to get DNS delegated to some other pre-existing DNS servers under our control, and we could then slave the zones from MAAS. This has the added advantage of “shielding” the MAAS servers from (lots of) client queries.

Issues:

  • MAAS does allow AXFRs, but as it is unaware of the slaves, it does not send NOTIFYs when the zone is updated, leading to delays in propogating updates.
  • As per #2, NS records do not accurately reflect the authoritative nameservers.

Suggestions:

  • Fixing #2 should fix these, as I believe BIND uses the NS records to know where to send NOTIFYs by default; alternatively, make this configurable (per zone, possibly with global default).

Configuration vs. customisable templates

The only issue with customisable templates is upgrade path; if additional functionality is added that requires a template change, the administrator may have some manual changes on their hands, or worse, might miss the change entirely.

Adding configuration options for every possible customisation is also not sustainable. That said, I think the above requirements are far from outlandish.

(If these should have been raised as bugs rather than suggestions, let me know.)

5 Likes

We have exactly the same problems and needs that you describe. The DNS service in MAAS really needs to be improved from a redundancy perspective. But also to be able to integrate into a wider DNS environment. As a configurable SOA and NS records. Also to be able to use external secondary name servers in a correct way.
Would be interesting to hear more opinions on this.

@drulgaard After contacting Canonical support, I have opened a bug for MAAS DNS i large environments. https://bugs.launchpad.net/maas/+bug/1926255
I refer to your excellent description here.

1 Like

Any news on this? The LP bug was closed.

As MAAS becomes more important to our operations, proper DNS integration is coming into our view as a priority. Addressing these issues would be a very useful improvement to us.