1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-25 01:34:11 +03:00
Commit Graph

12 Commits

Author SHA1 Message Date
Laine Stump
6612d1adb7 network: fix problems with SRV records
A patch submitted by Steven Malin last week pointed out a problem with
libvirt's DNS SRV record configuration:

  https://www.redhat.com/archives/libvir-list/2014-March/msg00536.html

When searching for that message later, I found another series that had
been posted by Guannan Ren back in 2012 that somehow slipped between
the cracks:

  https://www.redhat.com/archives/libvir-list/2012-July/msg00236.html

That patch was very much out of date, but also pointed out some real
problems.

This patch fixes all the noted problems by refactoring
virNetworkDNSSrvDefParseXML() and networkDnsmasqConfContents(), then
verifies those fixes by added several new records to the test case.

Problems fixed:

* both service and protocol now have an underscore ("_") prepended on
  the commandline, as required by RFC2782.

  <srv service='sip' protocol='udp' domain='example.com'
       target='tests.example.com' port='5060' priority='10'
       weight='150'/>

  before: srv-host=sip.udp.example.com,tests.example.com,5060,10,150
  after:  srv-host=_sip._udp.example.com,tests.example.com,5060,10,150

* if "domain" wasn't specified in the <srv> element, the extra
  trailing "." will no longer be added to the dnsmasq commandline.

  <srv service='sip' protocol='udp' target='tests.example.com'
       port='5060' priority='10' weight='150'/>

  before: srv-host=sip.udp.,tests.example.com,5060,10,150
  after:  srv-host=_sip._udp,tests.example.com,5060,10,150

* when optional attributes aren't specified, the separating comma is
  also now not placed on the dnsmasq commandline. If optional
  attributes in the middle of the line are not specified, they are
  replaced with a default value in the commandline (1 for port, 0 for
  priority and weight).

  <srv service='sip' protocol='udp' target='tests.example.com'
       port='5060'/>

  before: srv-host=sip.udp.,tests.example.com,5060,,
  after:  srv-host=_sip._udp,tests.example.com,5060

  (actually the would have generated an error, because "optional"
  attributes weren't really optional.)

* The allowed characters for both service and protocol are now limited
  to alphanumerics, plus a few special characters that are found in
  existing names in /etc/services and /etc/protocols. (One exception
  is that both of these files contain names with an embedded ".", but
  "."  can't be used in these fields of an SRV record because it is
  used as a field separator and there is no method to escape a "."
  into a field.) (Previously only the strings "tcp" and "udp" were
  allowed for protocol, but this restriction has been removed, since
  RFC2782 specifically says that it isn't limited to those, and that
  anyway it is case insensitive.)

* the "domain" attribute is no longer required in order to recognize
  the port, priority, and weight attributes during parsing. Only
  "target" is required for this.

* if "target" isn't specified, port, priority, and weight are not
  allowed (since they are meaningless - an empty target means "this
  service is *not available* for this domain").

* port, priority, and weight are now truly optional, as the comments
  originally suggested, but which was not actually true.
2014-03-26 16:42:43 +02:00
Laine Stump
66f75925eb network: change default of forwardPlainNames to 'yes'
The previous patch fixed "forwardPlainNames" so that it really is
doing only what is intended, but left the default to be
"forwardPlainNames='no'". Discussion around the initial version of
that patch led to the decision that the default should instead be
"forwardPlainNames='yes'" (i.e. the original behavior before commit
f3886825). This patch makes that change to the default.
2014-02-04 12:00:26 +02:00
Laine Stump
f69a6b987d 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.
2014-02-04 12:00:26 +02:00
Diego Woitasen
22547b4c98 Add forwarder attribute to <dns/> element
Useful to set custom forwarders instead of using the contents of
/etc/resolv.conf. It helps me to setup dnsmasq as local nameserver to
resolve VM domain names from domain 0, when domain option is used.

Signed-off-by: Diego Woitasen <diego.woitasen@vhgroup.net>
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-09-17 17:47:33 -06:00
Ján Tomko
d8bd24a9ec Remove the space before the slash in network XML
This matches the style we use elsewhere and allows
nat-network-dns-srv-record{,-minimal}.xml to be tested in
network XML -> XML test.
2013-08-28 08:05:46 +02:00
Laine Stump
4f595ba61c network: permit upstream forwarding of unqualified DNS names
This resolves the issue that prompted the filing of

  https://bugzilla.redhat.com/show_bug.cgi?id=928638

(although the request there is for something much larger and more
general than this patch).

commit f3868259ca disabled the
forwarding to upstream DNS servers of unresolved DNS requests for
names that had no domain, but were just simple host names (no "."
character anywhere in the name). While this behavior is frowned upon
by DNS root servers (that's why it was changed in libvirt), it is
convenient in some cases, and since dnsmasq can be configured to allow
it, it must not be strictly forbidden.

This patch restores the old behavior, but since it is usually
undesirable, restoring it requires specification of a new option in
the network config. Adding the attribute "forwardPlainNames='yes'" to
the <dns> elemnt does the trick - when that attribute is added to a
network config, any simple hostnames that can't be resolved by the
network's dnsmasq instance will be forwarded to the DNS servers listed
in the host's /etc/resolv.conf for an attempt at resolution (just as
any FQDN would be forwarded).

When that attribute *isn't* specified, unresolved simple names will
*not* be forwarded to the upstream DNS server - this is the default
behavior.
2013-08-14 09:46:22 -04:00
Laine Stump
db2536a627 Revert "Add support for <option> tag in network config"
This reverts commit 383ebc4694.

We decided the xml for this feature needed more thought to make sure
we are doing it the best way, in particular wrt option values that
have multiple items.
2013-02-27 10:55:24 -05:00
Gene Czarcinski
0b73a763f3 use client id for IPv6 DHCP host definition
Originally, only a host name was used to associate a
DHCPv6 request with a specific IPv6 address.  Further testing
demonstrates that this is an unreliable method and, instead,
a client-id or DUID needs to be used.  According to DHCPv6
standards, this id can be a duid-LLT, duid-LL, or duid-UUID
even though dnsmasq will accept almost any text string.

Although validity checking of a specified string makes sure it is
hexadecimal notation with bytes separated by colons, there is no
rigorous check to make sure it meets the standard.

Documentation and schemas have been updated.

Signed-off-by: Gene Czarcinski <gene@czarc.net>
Signed-off-by: Laine Stump <laine@laine.org>
2013-02-25 02:49:06 -05:00
Pieter Hollants
383ebc4694 Add support for <option> tag in network config
This patch adds support for a new <option>-Tag in the <dhcp> block of
network configs, based on a subset of the fifth proposal by Laine
Stump in the mailing list discussion at
https://www.redhat.com/archives/libvir-list/2012-November/msg01054.html.
Any such defined option will result in a dhcp-option=<number>,"<value>"
statement in the generated dnsmasq configuration file.

Currently, DHCP options can be specified by number only and there is
no whitelisting or blacklisting of option numbers, which should
probably be added.

Signed-off-by: Pieter Hollants <pieter@hollants.com>
Signed-off-by: Laine Stump <laine@laine.org>
2013-02-22 19:45:19 -05:00
Laine Stump
d66eb78667 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
753ff83a50. 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 12:15:03 -05:00
Eric Blake
7339bc4ced network: match xml warning message
I noticed that /var/lib/libvirt/dnsmasq/*.conf used the wrong word;
it was intended to match the wording in src/util/xml.c.

* src/network/bridge_driver.c (networkDnsmasqConfContents): Fix typo.
* tests/networkxml2confdata/*.conf: Update accordingly.
2012-12-12 15:12:58 -07:00
Gene Czarcinski
8b32c80df0 network: put dnsmasq parameters in conf-file instead of command line
This patch changes how parameters are passed to dnsmasq.  Instead of
being on the command line, the parameters are put into a file (one
parameter per line) and a commandline --conf-file= specifies the
location of the file.  The file is located in the same directory as
the leases file.

Putting the dnsmasq parameters into a configuration file
allows them to be examined and more easily understood than
examining the command lines displayed by "ps ax".  This is
especially true when a number of networks have been started.

When the use of dnsmasq was originally done, the required command line
was simple, but it has gotten more complicated over time and will
likely become even more complicated in the future.

Note: The test conf files have all been renamed .conf instead of
.argv, and tests/networkxml2xmlargvdata was moved to
tests/networkxml2xmlconfdata.
2012-12-11 05:49:45 -05:00