Bug 1305661 - libvirt's DNS instance should not forward requests of assigned domain to system resolver
libvirt's DNS instance should not forward requests of assigned domain to syst...
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
All Linux
unspecified Severity low
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2016-02-08 15:31 EST by Daniel Miranda
Modified: 2016-02-08 16:38 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-02-08 15:50:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Miranda 2016-02-08 15:31:35 EST
Description of problem:

libvirt's dnsmasq instance is automatically configured to manage a domain chosen in the network configuration. It is not, however, configured to avoid forwarding unsatisfied requests to that domain externally. That may cause DNS loops in some particular use cases, among which is one I'll describe next.

I'm using NetworkManager, that also sets up it's dnsmasq instance to locally proxy requests to external resolvers. I want libvirt's virtual machines to be accessible by their hostnames from my host system, under the same domain I configured libvirt to serve. To achieve that, I set up the proxy dnsmasq (call it DNS-P) to relay requests to libvirt's dnsmasq (DNS-L) with the following configuration:


libvirt's network is configured as:

    <forward mode='nat'/>
    <bridge name='virbr0' stp='on' delay='0'/>
    <mac address='52:54:00:a2:53:a9'/>
    <domain name='virt.danielqm.lan'/>
    <ip address='' netmask=''>
        <range start='' end=''/>

Everything works correctly when requesting valid domains: DNS-P happily forwards the request to DNS-L and gets an answer. Trouble appears when an unknown domain is requested. DNS-P will forward to DNS-L, which will not have an answer, then try to forward to the system resolver, which is DNS-L. That will cause an infinite loop that will exhaust the maximum allowed simultaneous queries of both servers.

Observing the dnsmasq configuration generated by libvirt, I notice it does not mark the served domain as local, which would stop any requests to it from being forwarded. Adding the following to the generated configuration would be sufficient to fix the issue as far as I could test it:


In addition to the already existing line with:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Set up NM's resolver to forward to libvirt's
2. Make a query to an invalid hostname in libvirt's domain

Actual results:

The two dnsmasq instances DoS each other.

Expected results:

Loops are avoided and libvirt's DNS responds immediately with not-found for invalid queries of it's configured domain.
Comment 1 Laine Stump 2016-02-08 15:50:07 EST
This problem was encountered and solved quite awhile back. To eliminate the loop, modify this line in your libvirt network config:

    <domain name='virt.danielqm.lan'/>

to this:

    <domain name='virt.danielqm.lan' localOnly='yes'/>

(use "virsh edit default" to make the change, then when you're done, run "virsh net-destroy default && virsh net-start default". You will need to shutdown and re-start any guest that was using the network at the time.)

This changes the dnsmasq setup in exactly the manner you describe.

Note that this cannot be done by default due to libvirt's policy of maintaining default behavior of existing functionality in new releases (so as not to break functioning setups), and also because it's probably more likely that the original behavior is what's desired.

See: http://www.libvirt.org/formatnetwork.html for more configuration options for libvirt networks.
Comment 2 Daniel Miranda 2016-02-08 16:38:00 EST
I looked around the documentation quite a lot and managed to miss it. Sorry for the bogus report, and thanks for the quick response.

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