Bug 849787

Summary: missing dnsmasq options
Product: [Fedora] Fedora Reporter: Gene Czarcinski <gczarcinski>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: berrange, clalancette, crobinso, eblake, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-27 12:58:50 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
add --local= or --local=/<domainname>/
first patch had slight error ... missing ";"
update with tests updated none

Description Gene Czarcinski 2012-08-20 17:11:11 EDT
Description of problem:
As currrently started by libvirt, the dnsmasq instances for a virtual network is undesirably passing some queries upstream.  When host is used, it standardly queries for A (ipv4), AAAA (ipv6), and MX records.  BTW, nslookup only does the A record query by default.  Even with NO domain name specified (just plain names), dnsmasq will provide the A answer but forward the AAAA MX queries.  This should not be happening!

Version-Release number of selected component (if applicable):
Fedora 17, libvirt, dnsmasq-2.59-5.fc17 

How reproducible:
yes, every time

Steps to Reproduce:
1.do query from guest that should only be resolved by the dnsmasq for that virtual network
2.Using wireshark or whatever, monitor what the dnsmasq sends upstream
3.(I was actually using query-loggin on the upstream dnsmasq server.)
Actual results:
queries for AAAA and MX forwarded; query for A was answered by the dnsmasq server.

Expected results:
no queries forwarded upstream for the "domain" controlled the dnsmasq (in other words, only those from /etc/hosts and from the dhcp service).

Additional info:

First, I wish there was an easier way to test changes to how the dnsmasq is started.  Rahter than beatting my head up against doing a whole bunch of software changes, I tested things virtually.

I set up a guest with two NICs: default and a private network.  I ran dnsmasq supporting dns and dhcp for the private network.  From another guest which which had that private network on a NIC, do queries (host or nslookup) for its name.  If you enable query logging for the dnsmasq server, you can see what is going on.

If "domain" is not specified, the dnsmasq uses the system's name for the domain.

The real problem is that "local=/<domain>/" needs to be specified.

After much looking, googling, and reading, the answer is quite clear in the example dnsmasq.conf

Lets say that a user specified <domain name="virt" /> then --local="virt" must also be specified.  If no domain name is specified, then you could use the name of the system the dnsmasq server is running on or (probably better) make up some name that you create.

This has been bothering me so I spent some time to figure out what was going on.  If you have any questions, just say them.
Comment 1 Gene Czarcinski 2012-08-21 09:20:36 EDT
Created attachment 605934 [details]
add --local= or --local=/<domainname>/

OK, I have does a whole bunch of experimenting (testing with virtual guests certainly makes things easier) and have come up with the needed changes ... namely adding "--local="

I have tested these changes with a dnsmasq on a virtual but have not really rebuilt libvirt with the patch applied  ... it is going to take me some time to figure out the #$%^ spec file.

The patch will produce either "--domain <domain> --local=/<domain>/" or
"--local=" which results in no forwarding for the names/IPs that dnsmasq controls.  Naturally, everything else gets forwarded.
Comment 2 Gene Czarcinski 2012-08-21 10:09:59 EDT
Created attachment 605942 [details]
first patch had slight error ... missing ";"
Comment 3 Eric Blake 2012-08-21 10:12:04 EDT
Can you please also post your patches upstream to libvir-list@redhat.com? You will get faster review response there.
Comment 4 Gene Czarcinski 2012-08-21 10:58:41 EDT
Patch submitted to libvir-list@redhat.com

I am still unable to rebuild the libvirt rpm ... I got the fillowing doing and rpmbuild -bi --short-circuit [-bp and -bc worked]

TEST: jsontest
      ....                                     4   OK
PASS: jsontest
TEST: networkxml2xmltest
      .............                            13  OK
PASS: networkxml2xmltest
TEST: networkxml2argvtest
      !!!!!!!!!                                9   FAIL
FAIL: networkxml2argvtest
TEST: nwfilterxml2xmltest
      ........................................ 40  OK
PASS: nwfilterxml2xmltest
Comment 5 Gene Czarcinski 2012-08-22 12:50:47 EDT
Created attachment 606340 [details]
update with tests updated

OK, this "should" do it.
Both the code and the patches in tests/networkxml2argvdata/ have been updated.

A test rpm has been built on an x86_64 system and the updated code has been tested.  As far as I can see, it works.

Note: dnsmasq will still pass some MX queries upstream ... ones that should not be done.  I will take this up with the dnsmasq folks.

I am also posting this to the libvir-list+
Comment 6 Gene Czarcinski 2012-08-22 15:51:48 EDT
My oh my.  Putting something on the libvir-list does get some very prompt handling of a patch (even if I did not know all the rules for contributing fixes to libvirt).  The patch has been added to git:


I am not sure what this means with respect to this bug report or how soon it will actually be part of the published package.

I have my locally created rpms with the fix and can easily reapply it locally if there are new libcirt packages without the fix.
Comment 7 Eric Blake 2012-08-22 17:48:49 EDT
F18 and rawhide will pick up this fix by virtue of the fact that they are rebasing to 0.10.0 or newer; but for F17, we now need this fix backported to the upstream v0.9.11-maint branch, and wait for Cole to cut v0.9.11.6 when more bugs have been collected (he just built this week, so it may be another couple of weeks before another maintenance build is worthwhile).  I'm moving this bug to POST to track that it's ready for backport.
Comment 8 Gene Czarcinski 2012-08-29 07:35:26 EDT
The patch is included in libvirt-0.10.0-1.fc17 which is now available at ftp://libvirt.org/libvirt/

Is there any reason not to build this and run it on F17?
Comment 9 Gene Czarcinski 2012-09-04 15:18:31 EDT
Unfortunately, this fix needs a bit more work.  As it is, forwarding name queries for the dnsmasq local domain will not occur.  However, dnsmasq will still forward PTR queries for its domain.

I am going to attempt to fix things without adding something to the network configuration file such as:
   <domain name="virt" addr="" /domain>
Comment 10 Laine Stump 2012-09-05 11:57:14 EDT
Also, as pointed out in Bug 854137 and on the mailing list, the patch referenced about added --filterwin2k, which prevents guests attached to the libvirt network from joining a Windows domain. That part of the patch definitely shouldn't go into F17.

BTW, if you'd like to run newer libvirt on F17, you can add the virt-preview repo to your yum configuration:


This will always be the version of libvirt used by Fedora ${your-release}+1, but built on Fedora ${your-release}.
Comment 11 Gene Czarcinski 2012-09-06 12:12:03 EDT
New patch submitted to libvir-list to remove "--filterwin2k"
Comment 12 Laine Stump 2012-09-11 13:02:42 EDT
The following patch was pushed upstream. If you decide to include the earlier patch in F17, you should also include this one:

commit f20b7dbe633acf7df9921027c6ca4f0b97918c8c
Author: Gene Czarcinski <gene@czarc.net>
Date:   Thu Sep 6 12:08:22 2012 -0400

    remove dnsmasq command line parameter "--filterwin2k"
    This patch removed the "--filterwin2k" dnsmasq command line
    parameter which was unnecessary for domain specification,
    possibly blocked some usage, and was command line clutter.
    Gene Czarcinski <gene@czarc.net>
Comment 13 Fedora Update System 2012-10-07 20:10:03 EDT
libvirt- has been submitted as an update for Fedora 17.
Comment 14 Gene Czarcinski 2012-10-08 09:55:28 EDT
I am sure this will fix things but I have moved along and am running libvirt-0.10.2-1 (with some patches by me.
Comment 15 Fedora Update System 2012-10-08 17:53:46 EDT
Package libvirt-
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).