Bridge not created if bind9 is on

Thanks for reporting this bug.

Note that another workaround should be to put 'listen-on { ! 10.0.3.1 };' in the named.conf.

However, when I tried to reproduce this in saucy I could not, so I wonder if there is something specific in your configuration customizations which caused this.

Could you please re-enable bind and then run 'apport-collect 1240757'? Hopefully apport will report customizations.

apport information

apport information

apport information

apport information

Unfortunately that didn't give me as much information as I'd hoped.

Could you please tell us what release you are on, and (after sanitizing for any private information) the contents of /etc/bind/named* ?

Currently on Raring. I'm adding comments with the respective files attached:

I can reproduce this if I add a 'sleep 10' right before the dnsmasq call in /etc/init/lxc-net.conf, so it appears to be purely timing related. (in other words, bind will always by default attach to all interfaces as they come up; it's not anything in your configs)

The question is then just how to properly handle this.

Leaving medium prio since there's a manual workaround (using listen-on).

Leaving confirmed in both lxc and bind9, as the best fix may still include a change to the bind9 package, rather than named.conf.options changes made by lxc postinst.

Another potential workaround would be to instruct bind9 to not poll to discover new interfaces (with interface-interval 0;). I have not tested this.

This bug just hit me in Ubuntu 14.04 LTS and is quite serious because LTS is used in servers, and it is common to try to have virtualization (LXC) as well as being configured as DNS servers (bind9).

Additionally, under some configurations at least, the whole DNS resolving becomes malfunctioning as 10.0.3.1 is the first entry in /etc/resolv.conf (put by resolvconf / dnsmasq) but it is not accessible. As a result, any DNS resolving wait some seconds for a timeout!

A detailed workaround without reboot:

1. Add this line in /etc/bind/named.conf.options before the last line::

    listen-on { ! 10.0.3.1; };

2. Restart bind9::

    service bind9 restart

3. Restart the LXC network::

    service lxc-net restart

It would be ideal if we could create a /etc/named.conf.d/lxc file and put the "listen-on { ! 10.0.3.1; };" there.

Does bind9 yet support named.conf.d ?

Looks like the proper syntax for the listen-on named config is either

Just tested on MAAS dns service which fails > 75% of the time when brought up in a vm due to timing issues.

The proposed "listen-on { ! 10.0.3.1; };" cannot be parsed by bind because ! is supposed to be outside the address list match element. (per http://www.zytrax.com/books/dns/ch7/address_match_list.html)

I think the fix should be:

listen-on ! { 10.0.3.1; };

With this setting in my maas dns/bind conf, bind comes up without error and I don't get collisions with lxc ips on the system.

hmm, I should've validated this statement above further on deployments. I am seeing other errors with bind with the above suggestion. I'll debug more and present results.

Ok attempt #2.

Looks like the original clause below didn't match any addresses so I was getting connection refused messages

listen-on { ! 10.0.3.1; };

What I found worked on my end was specifying a secondary address match list 'any' which we fall through to match any ipv4 address that is not 10.0.3.1:

listen-on { ! 10.0.3.1; any; };

Yes, I can confirm that the proper setting for ipv4 is:

    listen-on { ! 10.0.3.1; any; };

Now, the problem at hands appears again with ipv6. In /var/log/upstart/lxc-net.log:

    dnsmasq: failed to create listening socket for<some ipv6 address>%lxcbr0: Address already in use.

Deactivating ipv6 in bind solves it, but is of course not a final solution. In /etc/bind/named.conf.options

    listen-on-v6 { none; };

Unfortunately this isn't something that LXC itself can do, unless there is some kind of .d mechanism where we can dump a bind config snippet into.

Having bind use .d mechanism seems like the cleanest way to handle this.

Marking this won't fix for LXD since LXD is now letting API users create bridges dynamically which makes generating .d files very impractical for us. We may however be able to add a check for this issue and at least report a better error to the user.

For LXC, we could still use a .d mechanism since we have a fixed bridge there.