add configuration option to allow-transfer a zone

[Felipe Reyes]

Some datacenters already have a DNS solution integrated and they would like to use it as a "secondary master server"[0].

Currently MAAS has no method to configure this option.

To test I edited the file named.conf.template[1][2] and included the allow-transfer

--------- 8< ---------
include "{{named_rndc_conf_path}}";

# Zone declarations.
{{for zone in zones}}
{{for zoneinfo in zone.zone_info}}
zone "{{zoneinfo.zone_name}}" {
    type master;
    file "{{zoneinfo.target_path}}";
    {{if zoneinfo.zone_name == "maas"}}allow-transfer { 192.168.11.10; };{{endif}}
};
{{endfor}}
{{endfor}}

# Access control for recursive queries. See named.conf.options.inside.maas
# for the directives used on this ACL.
acl "trusted" {
{{for trusted_network in trusted_networks}}
    {{trusted_network}};
{{endfor}}
    localnets;
    localhost;
};
--------- 8< ---------

[0] https://help.ubuntu.com/community/BIND9ServerHowto#Secondary_Master_Server
[1] /usr/lib/python3/dist-packages/provisioningserver/templates/dns/named.conf.template
[2] https://git.launchpad.net/maas/tree/src/provisioningserver/templates/dns/named.conf.template?h=2.2

[Dongwon Cho (dongwoncho)]

It would be great if implemented with 'allow-query' option with being able to define ACLs as well.

[LaMont Jones (lamont)]

There should be a way to add both allow-transfer and allow-query in the global options block, as well as per-domain. (Data center my have customers that are providing off-site secondary DNS, and need to be able to get the zone.)

[Adam Collard (adam-collard)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team

[Jerzy Husakowski (jhusakowski)]

This feature request is added to the internal backlog for future prioritisation (internal ref PF-3954)

[Bruce Elrick (virtuous-sloth)]

Hello, I have a customer with an issue directly related to the mechanism this bug raises - the configuration of bind9 allow-transfer option under MAAS control.

However, in our case the request is the opposite. Since MAAS does not set the bind9 allow-transfer option at all then by default bind9 allows AXFR from all sources; my customer considers this a security risk from a defence-in-depth point of view and would like to restrict allow-transfer.

I was able to add the option in /etc/bind/named.conf.options as hinted at by the comments there:

    //
    // This file is managed by MAAS. Although MAAS attempts to preserve changes
    // made here, it is possible to create conflicts that MAAS can not resolve.
    //
    // DNS settings available in MAAS (for example, forwarders and
    // dnssec-validation) should be managed only in MAAS.
    //
    // The previous configuration file was backed up at:
    // /etc/bind/named.conf.options.2023-10-24T16:34:48.735188
    //
    options { directory "/var/cache/bind";
    listen-on-v6 { any; };
    allow-recursion { trusted; };
    allow-transfer { trusted; 10.20.30.0/24; 192.168.7.8; };
    include "/etc/bind/maas/named.conf.options.inside.maas"; };

And this correctly limited transfers in the testing I did (I did not test the "trusted" MAAS acl in a cluster MAAS case, though).

However, it would be nice is the MAAS configuration was secure by default; I don't think restricting AXFR is controversial.

I developed a straightforward patch[0] that adds "allow-transfer { trusted; };" to /etc/bind/maas/named.conf.options.inside.maas via src/provisioningserver/templates/dns/named.conf.options.inside.maas.template, including adding the template logic to avoid collisions between users adding the option in the /etc/bind/named.conf.options and MAAS adding it here, avoiding breaking the named config. I've tested a MAAS code upgrade where the option exists in /etc/bind/named.conf.options before a patched version of MAAS is upgraded to and it correctly does not add a redundant/conflicting entry in /etc/bind/maas/named.conf.options.inside.maas. My test builds are in three PPAs [1][2][3].

Unless PF-3954 has concrete plans attached, I wonder if this patch would be considered as an interim improvement in the default MAAS bind9 configuration.

[0] https://git.launchpad.net/~virtuous-sloth/maas/diff/?h=lp1711395-restrict-allow-transfer
[1] https://launchpad.net/~virtuous-sloth/+archive/ubuntu/maas-3.1
[2] https://launchpad.net/~virtuous-sloth/+archive/ubuntu/maas-3.2
[3] https://launchpad.net/~virtuous-sloth/+archive/ubuntu/maas-3.3

[Ryan Stewart (stew3254)]

Hello, there is another customer who is experiencing this issue and also considers it a security vulnerability. If possible, please update us on the status if this might be patched.