maas should be able to configure what addresses its DNS server listens on

[Ian Johnson]

The MAAS snap currently cannot be used simultaneously with the multipass snap since MAAS wants to own DNS and it listens on 0.0.0.0 which means that it is listening to all addresses, including some addresses that are owned by the multipass snap's bridge it sets up.

When this happens, the multipass snap cannot startup:

Oct 01 08:55:26 multipassd[371104]: Using AppArmor support
Oct 01 08:55:26 multipassd[371104]: Starting dnsmasq
Oct 01 08:55:26 multipassd[371104]: Applied AppArmor policy: multipass.dnsmasq
Oct 01 08:55:26 multipassd[371104]: [371166] started: dnsmasq --keep-in-foreground --strict-order --bind-interfaces --pid-file --domain=multipass --local=/multipass/ --except-interface=lo --interface=mpqemubr0 --listen-address=10.148.187.1 --dhcp-no-override --dhcp-authoritative --dhcp-leasefile=/var/snap/multipass/common/data/multipassd/network/dnsmasq.leases --dhcp-hostsfile=/var/snap/multipass/common/data/multipassd/network/dnsmasq.hosts --dhcp-range 10.148.187.2,10.148.187.254,infinite --conf-file=/var/snap/multipass/common/data/multipassd/network/dnsmasq-hzotUo.conf
Oct 01 08:55:26 multipassd[371104]:
                                    dnsmasq: failed to create listening socket for 10.148.187.1: Address already in use
Oct 01 08:55:26 multipassd[371104]: dnsmasq died: Process returned exit code: 2. Ensure nothing is using port 53.
Oct 01 08:55:26 multipassd[371104]: Caught an unhandled exception: dnsmasq died: Process returned exit code: 2. Ensure nothing is using port 53.
Oct 01 08:55:26 systemd[1]: snap.multipass.multipassd.service: Main process exited, code=exited, status=1/FAILURE

Because MAAS is already listening on that port/address since it greedily listens on all addresses via 0.0.0.0.

[Björn Tillenius (bjornt)]

It's the same issue when LXD is running. The workaround there is to tell LXD not to manage DNS for the bridge. Not sure if that's possible with multipass as well.

[Jerzy Husakowski (jhusakowski)]

While we acknowledge that it would be useful for MAAS to be able to deal with another entity owning DNS, it is currently by design not the case. We will consider this as a feature request and add to our roadmap.