On Fri, Dec 06, 2013 at 04:19:01PM +0200, Laine Stump wrote:
In commit f386825 we began adding the option "--local=/$mydomain/" to all dnsmasq commandlines (later changed to "local=/$mydomain/" when we moved the options from the commandline to a conf file) with the stated reason of preventing forwarding of DNS queries for names that weren't fully qualified domain names ("FQDN", i.e. a name that included some "."s and a domain name).
The original patch on the list, and discussion about it, is here:
https://www.redhat.com/archives/libvir-list/2012-August/msg01594.html
When a domain name isn't specified (no <domain> element in the network definition), the corresponding addition of "local=//" will prevent forwarding of domain-less requests to the virtualization host's DNS resolver, but if a domain *is* specified, the addition of "local=/domain/" will prevent forwarding of any requests for names within that domain that aren't resolvable by libvirt's dnsmasq itself.
An example of the problems this causes: let's say a network is defined with:
<domain name='example.com'/> <dhcp> .. <host mac='52:54:00:11:22:33' ip='1.2.3.4' name='myguest'/> </dhcp>
This results in "local=/example.com/" being added to the dnsmasq options.
If a guest requests "myguest" or "myguest.example.com", that will be resolved by dnsmasq. If the guest asks for "www.example.com", dnsmasq will not know the answer, but instead of forwarding it to the host, it will return NOT FOUND to the guest. In most cases that isn't the behavior an admin is looking for.
Really we should have been just including the option "--local=//" in all cases, so that (unresolvable by dnsmasq) requests for names without a domain would be treated as "local to dnsmasq" and not forwarded, but all other requests would be forwarded. That's what this patch does. ---
I'm debating whether there is any value at all to maintaining the previous behavior of "don't forward unresolved requests for hosts in the network's defined domain", or if it should just be considered purely a bug. If so, I think it shouldn't be the default behavior, and should be controlled by a new attribute to the <domain> element, something like this:
<domain name='example.com' forwardUnresolved='no'/>
(this would default to yes). Any opinions on 1) whether or not this is needed, and 2) if so, any better name for the option? (it would be nice if it could default to 'no' or 'local-only' (which was == 0) or something else that didn't require a non-0 default or a strange double-negative name).
So considering your example XML config above we're debating the behaviour of the following 5 possible DNS requests - myguest - myguest.example.com - notmyguest - notmyguest.example.com - google.com Originally - myguest -> dnsmasq - myguest.example.com -> dnsmasq - notmyguest -> forwarded - notmyguest.example.com -> forwarded - google.com -> forwarded With the current GIT - myguest -> dnsmasq - myguest.example.com -> dnsmasq - notmyguest -> error - notmyguest.example.com -> error - google.com -> forwarded With your proposal - myguest -> dnsmasq - myguest.example.com -> dnsmasq - notmyguest -> error - notmyguest.example.com -> fowarded - google.com -> forwarded IMHO I tend to think that the original behaviour should not have been changed and is the right default. If we desired either of the other behaviours we should have a config option for them to force returning of errors instead of forwarding. A simple boolean wouldn't suffice since there are 3 possible valid behaviours here - so we'd need an enum attribute Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|