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.
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.
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)
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!
(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).
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.
The patch looks good. I'm pushing it into fedora testing update.
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
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
(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!
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.
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.