Reverse DNS for non-maas RFC1918 zones fails inside maas

[Nathaniel W. Turner]

I have a maas instance that owns 172.23.4.0/24.
I also have non-maas machines on 172.21.0.0/24 (etc.).

The version of bind in the current version of maas (currently on the latest 2.9 snap, but this has been like this for awhile) maps rfc1918 zones like 0.21.172.in-addr.arpa to an empty zone instead of forwarding them. This breaks reverse DNS lookups done by maas hosts for addresses of non-maas hosts on these other private subnets. (Forward DNS still works OK.)

This can be fixed with something like this:

--- /var/snap/maas/current/bind/named.conf.orig 2020-12-14 11:12:16.135580193 -0500
+++ /var/snap/maas/current/bind/named.conf 2020-12-14 11:12:18.679606308 -0500
@@ -11,6 +11,7 @@
     session-keyfile "/var/snap/maas/current/bind/session.key";
     auth-nxdomain no;
     listen-on-v6 { any; };
+ empty-zones-enable no;
     include "/var/snap/maas/current/bind/named.conf.options.inside.maas";
 };

Can we get this patch upstream so automatic snap updates won't revert it? Blocking reverse lookups of RFC 1918 zones in maas, which is almost certainly forwarding to another internal DNS server (which can block these zones if appropriate) doesn't seem useful, and breaks some configs.

[Nathaniel W. Turner (nturner)]

Is there anything else I can do to facilitate this going upstream?

Every time maas updates itself, I get DNS failures in my environment and have to go reapply this patch.

[Nathaniel W. Turner (nturner)]

I put together a commit explaining the rationale behind this change and a pull request at https://github.com/maas/maas/pull/10

[Björn Tillenius (bjornt)]

Hi Nathaniel,

thanks for your bug report, and your patch!

I'm going to confirm locally that this works as expected, and then I'll clean up your patch and land it. I see that you patched only the config for the snap, and not the deb.

BTW, the code on github is only a mirror. We use Launchpad for code hosting and merge proposals as well.

[Björn Tillenius (bjornt)]

I'm going to backport this to 2.9 as well, since it's a regression.

[Nathaniel W. Turner (nturner)]

Awesome, thank you for working on this!

[Stefan Fleischmann (sfleischmann)]

I'm wondering if I have a similar issue that will be fixed by this. In my case it is a RFC1918 zone that IS managed by MAAS. If I do a reverse lookup via bind on the main instance it returns the correct result, but if I query bind on one of the rack controllers instead it does not return a result. I use MAAS 2.9.2-9164-g.ac176b5c4 from snap channel 2.9/stable.