libvirt instance of dnsmasq in raring fails to forward DNS requests

Bug #1126488 reported by Steve Langasek
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
dnsmasq (Ubuntu)
Fix Released
High
Unassigned

Bug Description

On a raring system, the dnsmasq instance spawned by libvirt is not forwarding DNS requests to the upstream resolver. dnsmasq is run as: /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf

The contents of default.conf are:

##WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
##OVERWRITTEN AND LOST. Changes to this configuration should be made using:
## virsh net-edit default
## or other application using the libvirt API.
##
## dnsmasq conf file created by libvirt
strict-order
domain-needed
user=libvirt-dnsmasq
local=//
pid-file=/var/run/libvirt/network/default.pid
except-interface=lo
bind-dynamic
interface=virbr0
dhcp-range=192.168.122.2,192.168.122.254
dhcp-no-override
dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases
dhcp-lease-max=253
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts

If I downgrade to dnsmasq-base 2.59-4 from quantal, comment out the (unrecognized) 'bind-dynamic' option, and run with -z (for --bind-interfaces), this dnsmasq instance then correctly forwards DNS queries.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: dnsmasq (not installed)
ProcVersionSignature: Ubuntu 3.8.0-6.11-generic 3.8.0-rc7
Uname: Linux 3.8.0-6-generic x86_64
ApportVersion: 2.8-0ubuntu4
Architecture: amd64
Date: Fri Feb 15 00:31:11 2013
InstallationDate: Installed on 2010-09-24 (875 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
MarkForUpload: True
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to quantal on 2013-01-25 (20 days ago)

Related branches

CVE References

Revision history for this message
Steve Langasek (vorlon) wrote :
Revision history for this message
Simon Kelley (simon-thekelleys) wrote : Re: [Bug 1126488] [NEW] libvirt instance of dnsmasq in raring fails to forward DNS requests

On 15/02/13 18:00, Steve Langasek wrote:
> Public bug reported:
>
> On a raring system, the dnsmasq instance spawned by libvirt is not
> forwarding DNS requests to the upstream resolver. dnsmasq is run as:
> /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
>

Steve, what version of dnsmasq is exhibiting the bug?

Simon.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Fri, Feb 15, 2013 at 06:35:40PM -0000, Simon Kelley wrote:
> On 15/02/13 18:00, Steve Langasek wrote:
> > Public bug reported:

> > On a raring system, the dnsmasq instance spawned by libvirt is not
> > forwarding DNS requests to the upstream resolver. dnsmasq is run as:
> > /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
> Steve, what version of dnsmasq is exhibiting the bug?

The raring version, 2.65-1.

I've just installed a test package from
https://launchpad.net/~mdeslaur/+archive/testing per Seth Arnold's
suggestion on IRC, which appears to resolve the issue. According to Seth,
that implies this is probably linked to
<https://bugzilla.redhat.com/show_bug.cgi?id=894486>.

Steve Langasek (vorlon)
Changed in dnsmasq (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Steve Langasek (vorlon) wrote :

Marc, any ETA for getting this fixed dnsmasq into raring?

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

I was waiting for 2.66 to come out.

Simon, is a 2.66 release planned soon?

Revision history for this message
Simon Kelley (simon-thekelleys) wrote : Re: [Bug 1126488] Re: libvirt instance of dnsmasq in raring fails to forward DNS requests

On 15/02/13 18:52, Steve Langasek wrote:
> On Fri, Feb 15, 2013 at 06:35:40PM -0000, Simon Kelley wrote:
>> On 15/02/13 18:00, Steve Langasek wrote:
>>> Public bug reported:
>
>>> On a raring system, the dnsmasq instance spawned by libvirt is not
>>> forwarding DNS requests to the upstream resolver. dnsmasq is run as:
>>> /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
>> Steve, what version of dnsmasq is exhibiting the bug?
>
> The raring version, 2.65-1.
>
> I've just installed a test package from
> https://launchpad.net/~mdeslaur/+archive/testing per Seth Arnold's
> suggestion on IRC, which appears to resolve the issue. According to Seth,
> that implies this is probably linked to
> <https://bugzilla.redhat.com/show_bug.cgi?id=894486>.
>
>
> ** Bug watch added: Red Hat Bugzilla #894486
> https://bugzilla.redhat.com/show_bug.cgi?id=894486
>

That's possible, but the fix for RedHat involves subtracting from the
set of queries which get answered, not adding to it, so that doesn't
quite fit the description.

Simon.

Revision history for this message
Simon Kelley (simon-thekelleys) wrote :

On 15/02/13 19:52, Marc Deslauriers wrote:
> I was waiting for 2.66 to come out.
>
> Simon, is a 2.66 release planned soon?
>

Probably not soon. There are no current showstopper issues, but there's
a lot of new code over 2.65, so it will need a reasonably long
release-candidate period to get it tested.

I'd like to understand what the problem is with 2.65, since I'm not
aware of this problem and I don't understand how 2.66 has fixed it.

Simon.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dnsmasq - 2.65-1ubuntu1

---------------
dnsmasq (2.65-1ubuntu1) raring; urgency=low

  * Fix local resolving when used with libvirt and bind-dynamic (LP: #1126488)
    - debian/patches/fix_tcp_queries.patch: Correct behaviour for TCP
      queries to allowed address via banned interface in src/dnsmasq.*,
      src/network.c.
    - debian/patches/fix_wrong_interface.patch: Handle wrong interface for
      locally-routed packets in src/dnsmasq.*, src/forward.c, src/network.c,
      src/tftp.
 -- Marc Deslauriers <email address hidden> Fri, 15 Feb 2013 15:27:58 -0500

Changed in dnsmasq (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.