Commit Graph

9 Commits

Author SHA1 Message Date
Ján Tomko
6b59d6cac1 tests: do not test dnsmasq older than 2.67
Prepare to retire older versions by droping older tests.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
2021-12-15 15:28:17 +01:00
Laine Stump
82fe58ff26 network: add netmask to dhcp range of dnsmasq conf file for IPv4
dnsmasq documentation says that the *IPv4* prefix/network
address/broadcast address sent to dhcp clients will be automatically
determined by dnsmasq by looking at the interface it's listening on,
so the original libvirt code did not add a netmask to the dnsmasq
commandline (or later, the dnsmasq conf file).

For *IPv6* however, dnsmasq apparently cannot automatically determine
the prefix (functionally the same as a netmask), and it must be
explicitly provided in the conf file (as a part of the dhcp-range
option). So many years after IPv4 DHCP support had been added, when
IPv6 dhcp support was added the prefix was included at the end of the
dhcp-range setting, but only for IPv6.

A user had reported a bug on a host where one of the interfaces was a
superset of the libvirt network where dhcp is needed (e.g., the host's
ethernet is 10.0.0.20/8, and the libvirt network is 10.10.0.1/24). For
some reason dnsmasq was supplying the netmask for the /8 network to
clients requesting an address on the /24 interface.

This seems like a bug in dnsmasq, but even if/when it gets fixed
there, it looks like there is no harm in just always adding the
netmask to all IPv4 dhcp-range options similar to how prefix is added
to all IPv6 dhcp-range options.

Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2019-02-21 13:06:16 -05:00
Martin Wilck
4ac20b3ae4 network: add dnsmasq option 'dhcp-authoritative'
The dnsmasq man page recommends that dhcp-authoritative "should be
set when dnsmasq is definitely the only DHCP server on a network".
This is the case for libvirt-managed virtual networks.

The effect of this is that VMs that fail to renew their DHCP lease
in time (e.g. if the VM or host is suspended) will be able to
re-acquire the lease even if it's expired, unless the IP address has
been taken by some other host. This avoids various annoyances caused
by changing VM IP addresses.
2016-10-10 15:15:11 -04:00
Peter Krempa
421406808a network: dnsmasq: Don't format lease file path
Now that we don't use the leases file at all for leases just don't
format it into the config and use the leaseshelper to do all the
lifting.
2014-12-03 14:22:40 +01:00
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
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