Solution 1:

If a forwarder is configured, dnsmasq will forward all DNS queries that it has no explicit data for. This includes records for configured static DHCP clients that have no active lease, AAAA records unless IPv6 addresses are defined explicitly, and more.

There are several ways to avoid this:

Don't configure a forwarder

Simply omit the fowarder entries in the network definition. Probably not desirable, unless the virtual network is really isolated. This is the only possibility that libvirt currently supports (12/2014), AFAIK.

local domain in dnsmasq.conf

Configure the domain as "local" in dnsmasq:

 domain=local.net,192.168.10.0/24
 local=/local.net/
 local=/10.168.192.in-addr.arpa/

In theory, this could be abbreviated as domain=local.net,192.168.10.0/24,local, but a dnsmasq bug fixed only recently causes this to fail.

libvirt doesn't support this. In order to use this configuration, you need to set up the bridge manually in your OS and configure the libvirt network like this:

   <network>
     <name>local</name>
     <forward mode='bridge'/>
     <bridge name='br0'/>
   </network>

You don't have to create a libvirt virtual network at all in this configuration, just use <interface 'type=bridge'> in your VM definition files.

auth zone in dnsmasq.conf

The auth-zone parameter has a similar effect to local. However it has other implications that I don't claim to fully understand. I suppose this configuration would be desirable if names in the virtual network are supposed to be resolved from the outside.

domain=local.net
auth-zone=local.net

This setup isn't supported by libvirt either, so the same procedure for setting up the bridge must be applied as above.