maas incorrectly overmanages DNS reverse zones

Bug #1356012 reported by LaMont Jones on 2014-08-12
This bug affects 5 people
Affects Status Importance Assigned to Milestone
LaMont Jones
LaMont Jones
maas (Ubuntu)

Bug Description

when I configure maas to manage DNS and DHCP for, it creates a reverse zone for

If is in use for other things, and only was delegated to scalingstack, then no reverse DNS can happen, since the parent zone will win the argument.

In this case, maas needs to create the following zones, and properly populate them (nsupdate will do the right thing if the zone declarations are correct):
(a total of 16 zones.)

Seen on trusty:
ii maas-dns 1.5.2+bzr2282-0ubuntu0.2 all MAAS DNS server

Please let me know what other information you need.


Tags: dns Edit Tag help

Related branches

LaMont Jones (lamont) on 2014-08-12
summary: - maas incorrectly overmanages DNS
+ maas incorrectly overmanages DNS reverse zones
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in maas (Ubuntu):
status: New → Confirmed
Julian Edwards (julian-edwards) wrote :

This was a known issue when the code was originally written. I'm not sure the solution you write about was ever considered, so I am sure Raphaël will be interested to see this!

Changed in maas:
status: New → Triaged
importance: Undecided → Medium
tags: added: dns
LaMont Jones (lamont) wrote :

See also for a very nice (still current best practice 16 years later) writeup on how to handle zones smaller than /24.

If you guys have any other DNS questions, feel free to ask me, or one of the other admins.

Mike Pontillo (mpontillo) wrote :

Thanks to LaMont's recent work on this for MAAS-next, we have the opportunity to backport this fix to 1.9.0 before the codebase diverges too much.

Changed in maas:
milestone: none → 1.9.0
Andres Rodriguez (andreserl) wrote :

Hi Guys,

This is more of a feature request rather than a proper bug fix. This would change the behavior of 1.9, and as such, it is not back portable.

no longer affects: maas/1.9
Blake Rouse (blake-rouse) wrote :

This is being hit by users. I think we should fix this in 1.9.1.

LaMont Jones (lamont) wrote :

This will also entail adding a field to Subnet (default=True, changable via the api, but we won't clutter the web UI with it) to also be authoritative for the parent /24 zone and generate glue for the /{25..30} rfc2317 zone.

LaMont Jones (lamont) wrote :

As the change was implemented in 2.0, backporting it to 1.9 would require a data migration in 1.9, which we need to avoid.

As such, if we ever do backport this to 1.9, we'll probably need assume rdns_mode=Enabled in the code, and if the admin wants rdns_mode=rfc2317_glue (the 2.0 default), then he will need to create the parent /24 subnet in maas, so that we generate that zone (and the glue that lives therein)

Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers