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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list