Cannot start lxd-bridge.service when MAAS is managing DNS

[Gavin Panella]

$ sudo systemctl restart lxd-bridge.service
$ journalctl -u lxd-bridge.service
Jun 20 10:52:02 madagascar systemd[1]: Stopped LXD - network bridge.
Jun 20 10:52:02 madagascar systemd[1]: Starting LXD - network bridge...
Jun 20 10:52:03 madagascar lxd-bridge.start[3158]: dnsmasq: failed to create listening socket for 10.224.138.1: Address already in use
Jun 20 10:52:03 madagascar lxd-bridge.start[3158]: Failed to setup lxd-bridge.
Jun 20 10:52:03 madagascar systemd[1]: Started LXD - network bridge.

The address 10.224.138.1 is the subnet that lxdbr0 is trying to set up. If I stop bind9.service and start lxd-bridge.service again it works fine.

(There seems to be a bug in lxd-bridge.service here too; the unit logs "Failed to setup ..." then systemd says "Started LXD - network bridge". Seems like systemd is not being told that it didn't work.)

[Mike Pontillo (mpontillo)]

This is actually a bug in the bind9 package, from what I understand. I think LaMont is already giving it some thought.

[Launchpad Janitor (janitor)]

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

[David A. Desrosiers (setuid)]

Adding these two lines (specifically the second line) to /etc/bind/named.conf.options and restarting bind, should solve this for you:

listen-on-v6 { none; };
listen { !10.224.138.0/24; };

[David A. Desrosiers (setuid)]

Correction to my last comment (listen-on, not listen):

listen-on { !10.224.138.0/24; };

[Zhanglei Mao (zhanglei-mao)]

It seems not works on my side ( 18.04 ARM64). I have to add the listening IP explicitly.

ubuntu@infra1:/etc/bind$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"

ubuntu@infra1:/etc/bind$ uname -a
Linux infra1 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:32:18 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

ubuntu@infra1:/etc/bind$ cat /etc/bind/named.conf.options
..
options { directory "/var/cache/bind";
auth-nxdomain no;
listen-on-v6 { none; };
listen-on { 185.168.3.1; };
//listen-on { !10.54.224.0/24; };
//listen-on { any; };
include "/etc/bind/maas/named.conf.options.inside.maas"; };
ubuntu@infra1:/etc/bind$

[Zhanglei Mao (zhanglei-mao)]

to add floating ip too as:
listen-on { 185.168.3.1; 185.168.3.5; };

[Jason Hobbs (jason-hobbs)]

MAAS is installing bind9 and configuring it for its own purposes - it provides other config for bind, and it's perfectly reasonable to expect maas to configure it to only listen on interfaces MAAS wants to provide DNS services on.

[Alexander Balderson (asbalderson)]

This workaround doesnt seem to work for snapped maas applying the fix to /var/snap/maas/current/bind/named.conf.options.

[Alexander Balderson (asbalderson)]

subbing to field high,
the workaround for a new snapped install MaaS seems to be to install Maas into a container, but existing installs upgrading to Focal will run into this problem.

[Adam Collard (adam-collard)]

Can you `lxc network set lxdbr0 dns.mode=none` adjusting for the name of your bridge.

This will tell LXD to not manage DNS on the bridge, as per https://github.com/lxc/lxd/blob/master/doc/networks.md.

Note you might also want to disable DHCP: `lxc network set lxdbr0 ipv4.dhcp=false` and `lxc network set lxdbr0 ipv6.dhcp=false`

[Alberto Donato (ack)]

Could you please confirm if commands provided by Adam in #10 work for you?

[Björn Tillenius (bjornt)]

I think we need to solve this somehow.

I'm thinking that we could re-use the 'allow_dns' flag on subnets. If it's False, we shouldn't listen on an address in that subnet.

I think it should be safe, since AFAIK, allow_dns is only used to determine whether the address should be returned in the DHCP response.

[Launchpad Janitor (janitor)]

[Expired for MAAS because there has been no activity for 60 days.]

[Jerzy Husakowski (jhusakowski)]

We plan to implement Bjorn's suggestion to re-use the 'allow_dns' flag on subnets. Note that this may be a breaking change for users who rely on the current default behaviour.

[Jerzy Husakowski (jhusakowski)]

This improvement in DNS handling has been moved to an internal backlog for future prioritisation (internal ref PF-3954).