>@ahasenack, nice find! I guess I had assumed the
>second-dns-server-past-the-post would have
> failed to come online, so didn't think to check this.
Same here :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
** Changed in: bind9 (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1796164
Title:
After interface/IP changes, bind9 can fail to respond to queries on
the new
@ahasenack, nice find! I guess I had assumed the second-dns-server-past-
the-post would have failed to come online, so didn't think to check
this.
In addition to my discourse post, I think we may have some tutorials
and/or docs that need to be updated based on this.
--
You received this bug noti
@paelzer gave me the hint that solved it.
TL;DR: bind9 conflicts with dnsmasq that is setup to listen on :53 on
the newly created libvirt bridge.
So when you query the new IP, it's dnsmasq who is getting the request,
and not bind.
Right after bringing up the new interface, both dnsmasq and named
Maybe firewall rules, although I can't imagine how a bind9 restart would
"fix" that. Investigation continues.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1796164
Title:
After interface/IP changes,
It's not just a bridge, something else is going on, because this works:
root@cosmic-bind9-bridge:~# ip l|grep br0
root@cosmic-bind9-bridge:~# dig +short @192.168.1.1 maestro.example.internal
;; connection timed out; no servers could be reached
root@cosmic-bind9-bridge:~# brctl addbr br0
root@cosmi
** Changed in: maas
Milestone: 2.5.0rc1 => None
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1796164
Title:
After interface/IP changes, bind9 can fail to respond to queries on
the new interfa
Marking as won't fix for MAAS as this issue really sets outside of MAAS.
** Changed in: maas
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1796164
Title:
Afte
** Description changed:
Steps to reproduce:
(1) Install MAAS.
- (2) Add an interface to a MAAS controller with an IP address
+ (2) Add a bridge interface to a MAAS controller with an IP address (this
+ can be easily done using libvirt)[1].
- (3) Observe that bind9 is responding on the
I can confirm this on cosmic with a libvirt network (virbrN). The logs
say named started listening on the new nic, but queries don't work. In
fact, even with query logging enabled, nothing is logged when a query
comes in via that interface.
tcpdump shows (virbr1 is 10.0.3.1):
listening on any, lin
Is MAAS using netplan to add the new interface? I was trying to
reproduce this without MAAS, but it worked just fine. I fear that maybe
netplan is triggering something else that MAAS by itself isn't, and that
made it work.
Here is what I did.
New VM, with just one nick, configured via netplan to
** Changed in: maas
Status: Triaged => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1796164
Title:
After interface/IP changes, bind9 can fail to respond to queries on
the new in
Taking a look.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1796164
Title:
After interface/IP changes, bind9 can fail to respond to queries on
the new interface
To manage notifications about thi
13 matches
Mail list logo
