Bug 904940 - RFE: libvirt's dnsmasq instances should answer LOCAL DNS Queries
RFE: libvirt's dnsmasq instances should answer LOCAL DNS Queries
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnsmasq (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomáš Hozza
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-28 03:43 EST by Tomáš Hozza
Modified: 2013-02-18 02:05 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-12 10:02:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomáš Hozza 2013-01-28 03:43:38 EST
From original Bug #894486


--- Josh Stone 2013-01-11 16:03:31 EST ---

Description of problem:
On my workstation, as a virtual machine host, I have NetworkManager's dnsmasq configured to forward DNS queries for a local domain to 192.168.122.1, so I can resolve those to virtual machine DHCP hostnames.  Recently this stopped working.

With manual dig commands, I found that TCP queries still work, but UDP doesn't.  For example, in libvirt I have a statically defined name "vhost" to 192.168.122.1 itself.  From the host, the command "dig +short +tcp @192.168.122.1 vhost" resolves that just fine.  But "dig +short +notcp @192.168.122.1 vhost" says "connection timed out; no servers could be reached".  From a guest, +tcp and +notcp both work fine.

Version-Release number of selected component (if applicable):
libvirt-0.9.11.8-2.fc17.x86_64, dnsmasq-2.63-1.fc17.x86_64
I also tried dnsmasq-2.65-1.fc17.x86_64 from updates-testing

How reproducible:
100%

Steps to Reproduce:
1. From the virtual machine host, try to query the libvirt dnsmasq.
  
Actual results:
$ dig +short +tcp @192.168.122.1 vhost
192.168.122.1
$ dig +short +notcp @192.168.122.1 vhost
;; connection timed out; no servers could be reached

Expected results:
A positive answer from both TCP and UDP queries.

Additional info:
I suspect this is related to the fixes for CVE-2012-3411, but it seems weird that UDP and TCP would be treated differently.


--- Josh Stone 2013-01-17 14:30:07 EST ---

This is still a problem on F18, but I've reproduced it with dnsmasq alone, so I'm retitling and reassigning this bug.

Using dnsmasq-2.65-1.fc18.x86_64, the difference is demonstrated between --bind-dynamic and the old --bind-interfaces.

A local query to dnsmasq --bind-dynamic works in TCP, but times out in UDP:
# dnsmasq --no-daemon --conf-file= --bind-dynamic --interface em1 --except-interface lo

$ dig +tcp +short @192.168.1.203 localhost
127.0.0.1
$ dig +notcp +short @192.168.1.203 localhost
;; connection timed out; no servers could be reached


The same query with --bind-interfaces works fine either way:
# dnsmasq --no-daemon --conf-file= --bind-interfaces --interface em1 --except-interface lo

$ dig +tcp +short @192.168.1.203 localhost
127.0.0.1
$ dig +notcp +short @192.168.1.203 localhost
127.0.0.1


--- Tomas Hozza 2013-01-25 02:47:44 EST ---

(In reply to comment #23)
> I would like NM's dnsmasq to answer 127.0.0.1 (by nature lo), and libvirt's
> to answer 192.168.122.1 on virbr0 or lo.  The fact that NM's can still start
> by using --bind-dynamic doesn't mean it will be the one responding, as your
> bug 886663 comment 6 indicates.  It seems you'd have a startup race for
> whoever really grabbed 127.0.0.1 first, and that's not ok.

dnsmasq with --except-interface lo will *NOT* bind to the loopback interface
this means the 127.0.0.1 will be available. Since CVE-2012-3411 and CVE-2013-0198
were fixed, libvirt's dnsmasq will *NOT* answer any DNS Queries coming on another
interface that virbrX.

Answering DNS Queries coming through lo with --except-interface lo used was
an error.

> I'll file a separate bug later today to stop polluting this CVE, and from
> there hopefully it can be hashed out who among dnsmasq, libvirt, and/or
> NetworkManager can change their options to make this work, if it is possible
> at all.

This could be resolved by implementing new option for dnsmasq, to enable
local DNS Queries (without binding to lo). It would need to be used by libvirt.
Please create the new Bug for dnsmasq.
Comment 1 Tomáš Hozza 2013-01-28 08:43:52 EST
I prepared and sent a patch adding new option into dnsmasq to the Upstream.

This new option would allow dnsmasq to answer local DNS Queries as described
in the Bug description.
Comment 2 Laine Stump 2013-01-28 12:47:05 EST
The patch hasn't shown up on dnsmasq-discuss yet, but as long as it adds this new option to the output of "dnsmasq --help", libvirt will be able to notice it and automatically add it in when available. (I don't believe it will be necessary to add a new option to libvirt's network config, since the only "new" place it will allow queries from is the host itself)
Comment 3 Josh Stone 2013-01-28 14:46:57 EST
Thanks, I look forward to this functionality!
And sorry that I forgot to file this RFE myself.

Let me share what other configuration changes I made on the host that make this work (at least until CVE-2012-3411 closed the loophole).  It may make a nice documentation example of how this feature is useful.

In libvirt's network xml (virsh net-edit default), add a domain like:
    <domain name='vm.example.com'/>

Then create a rule for NM, like /etc/NetworkManager/dnsmasq.d/vm-hosts:
server=/vm.example.com/192.168.122.1
server=/122.168.192.in-addr.arpa/192.168.122.1

Finally, tell NM to use that "vm.example.com" as a search domain too.  I didn't find a way to set this globally, but it worked fine for me to set it in "Additional search domains" of em1, since my machine is always wired.

Hope this helps!
Comment 4 Tomáš Hozza 2013-01-29 04:50:28 EST
(In reply to comment #2)
> The patch hasn't shown up on dnsmasq-discuss yet, but as long as it adds
> this new option to the output of "dnsmasq --help", libvirt will be able to
> notice it and automatically add it in when available. (I don't believe it
> will be necessary to add a new option to libvirt's network config, since the
> only "new" place it will allow queries from is the host itself)

I sent the email directly to Simon Kelley and forgot to include the mailing
list. I added you and the mailing list to CC.

There is one solution to use IPv6, but that is a better question for libvirt
maintainers. The bad thing is that there is a good reason why IPv6 is not used
(Bug #501934).
Comment 5 Tomáš Hozza 2013-01-30 05:37:46 EST
Upstream patch that should fix this issue:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=e25db1f273920d58c5d2e7569cd087e5bd73dd73;hp=79cb46c0e9912b1850a82f5b3e992c992853c659

I does not require any changes in libvirt. I will do some testing and push
a new testing update in Fedora.
Comment 6 Tomáš Hozza 2013-01-31 05:37:47 EST
The patch looks good. I'm pushing it into fedora testing update.
Comment 7 Fedora Update System 2013-01-31 05:50:25 EST
dnsmasq-2.65-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-1357/dnsmasq-2.65-4.fc18
Comment 8 Fedora Update System 2013-01-31 05:50:31 EST
dnsmasq-2.65-4.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2013-1320/dnsmasq-2.65-4.fc17
Comment 9 Tomáš Hozza 2013-01-31 05:52:22 EST
(In reply to comment #3)
> Thanks, I look forward to this functionality!
> And sorry that I forgot to file this RFE myself.

Please test the testing package https://admin.fedoraproject.org/updates/FEDORA-2013-1357/dnsmasq-2.65-4.fc18 and add Karma if it works!
Comment 10 Fedora Update System 2013-02-11 23:58:51 EST
dnsmasq-2.65-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2013-02-18 02:05:43 EST
dnsmasq-2.65-4.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.