Reverse DNS for non-maas RFC1918 zones fails inside maas

Bug #1908087 reported by Nathaniel W. Turner
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
High
Björn Tillenius
2.9
Fix Committed
High
Björn Tillenius

Bug Description

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.

Tags: patch

Related branches

description: updated
Revision history for this message
Nathaniel W. Turner (nturner) wrote :

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.

Revision history for this message
Nathaniel W. Turner (nturner) wrote :

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

tags: added: patch
Revision history for this message
Björn Tillenius (bjornt) wrote :

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.

Changed in maas:
status: New → Triaged
status: Triaged → In Progress
importance: Undecided → High
assignee: nobody → Björn Tillenius (bjornt)
Revision history for this message
Björn Tillenius (bjornt) wrote :

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

Changed in maas:
milestone: none → 2.10-beta1
status: In Progress → Fix Committed
Revision history for this message
Nathaniel W. Turner (nturner) wrote :

Awesome, thank you for working on this!

Changed in maas:
status: Fix Committed → Fix Released
Revision history for this message
Stefan Fleischmann (sfleischmann) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers