[libvirt] [PATCH] network: only prevent forwarding of DNS requests for unqualified names

Daniel P. Berrange berrange at redhat.com
Tue Dec 10 14:45:54 UTC 2013


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 :|




More information about the libvir-list mailing list