maas incorrectly overmanages DNS reverse zones

Bug #1356012 reported by LaMont Jones on 2014-08-12
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
MAAS
High
LaMont Jones
1.9
Wishlist
Unassigned
Trunk
High
LaMont Jones
maas (Ubuntu)
Undecided
Unassigned

Bug Description

when I configure maas to manage DNS and DHCP for 10.89.64.0/20, it creates a reverse zone for 89.10.in-addr.arpa.

If 10.89.0.0/16 is in use for other things, and only 10.89.64.0/20 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):
    64.89.10.in-addr.arpa
    65.89.10.in-addr.arpa
    ...
    78.89.10.in-addr.arpa
    79.89.10.in-addr.arpa
(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.

lamont

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 https://www.ietf.org/rfc/rfc2317.txt 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