maas incorrectly overmanages DNS reverse zones

[LaMont Jones]

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

[Launchpad Janitor (janitor)]

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

[Julian Edwards (julian-edwards)]

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!

[LaMont Jones (lamont)]

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)]

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.

[Andres Rodriguez (andreserl)]

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.

[Blake Rouse (blake-rouse)]

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

[LaMont Jones (lamont)]

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)]

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)