1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-26 03:21:44 +03:00
libvirt/tests/networkxml2confdata/nat-network-dns-hosts.conf

16 lines
443 B
Plaintext
Raw Normal View History

##WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
##OVERWRITTEN AND LOST. Changes to this configuration should be made using:
## virsh net-edit default
## or other application using the libvirt API.
##
## dnsmasq conf file created by libvirt
strict-order
domain=example.com
expand-hosts
network: only prevent forwarding of DNS requests for unqualified names In commit f386825 we began adding the options --domain-needed --local=/$mydomain/ to all dnsmasq commandlines 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). This was later changed to domain-needed local=/$mydomain/ when we moved the options from the dnsmasq commandline to a conf file. 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 (mydomain == ""), the addition of "domain-needed 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 *qualified* 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. A later patch (commit 4f595ba) attempted to remedy this by adding a "forwardPlainNames" attribute to the <dns> element. The idea was that if forwardPlainNames='yes' (default is 'no'), we would allow unresolved names to be forwarded. However, that patch was botched, in that it only removed the "domain-needed" option when forwardPlainNames='yes', and left the "local=/mydomain/". Really we should have been just including the option "--domain-needed --local=//" (note the lack of domain name) regardless of the configured domain of the network, so that requests for names without a domain would be treated as "local to dnsmasq" and not forwarded, but all others (including those in the network's configured domain) would be forwarded. We also shouldn't include *either* of those options if forwardPlainNames='yes'. This patch makes those corrections. This patch doesn't remedy the fact that default behavior was changed by the addition of this feature. That will be handled in a subsequent patch.
2013-12-06 14:55:37 +04:00
domain-needed
local=//
network: prevent dnsmasq from listening on localhost This patch resolves the problem reported in: https://bugzilla.redhat.com/show_bug.cgi?id=886663 The source of the problem was the fix for CVE 2011-3411: https://bugzilla.redhat.com/show_bug.cgi?id=833033 which was originally committed upstream in commit 753ff83a50263d6975f88d6605d4b5ddfcc97560. That commit improperly removed the "--except-interface lo" from dnsmasq commandlines when --bind-dynamic was used (based on comments in the latter bug). It turns out that the problem reported in the CVE could be eliminated without removing "--except-interface lo", and removing it actually caused each instance of dnsmasq to listen on localhost on port 53, which created a new problem: If another instance of dnsmasq using "bind-interfaces" (instead of "bind-dynamic") had already been started (or if another instance started later used "bind-dynamic"), this wouldn't have any immediately visible ill effects, but if you tried to start another dnsmasq instance using "bind-interfaces" *after* starting any libvirt networks, the new dnsmasq would fail to start, because there was already another process listening on port 53. (Subsequent to the CVE fix, another patch changed the network driver to put dnsmasq options in a conf file rather than directly on the dnsmasq commandline, but preserved the same options.) This patch changes the network driver to *always* add "except-interface=lo" to dnsmasq conf files, regardless of whether we use bind-dynamic or bind-interfaces. This way no libvirt dnsmasq instances are listening on localhost (and the CVE is still fixed). The actual code change is miniscule, but must be propogated through all of the test files as well.
2012-12-13 10:46:40 +04:00
except-interface=lo
bind-dynamic
interface=virbr0
addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts