CVE-2021-3448 applies.
It's possible to specify the source address or interface to be
used when contacting upstream nameservers: server=8.8.8.8@1.2.3.4
or server=8.8.8.8@1.2.3.4#66 or server=8.8.8.8@eth0, and all of
these have, until now, used a single socket, bound to a fixed
port. This was originally done to allow an error (non-existent
interface, or non-local address) to be detected at start-up. This
means that any upstream servers specified in such a way don't use
random source ports, and are more susceptible to cache-poisoning
attacks.
We now use random ports where possible, even when the
source is specified, so server=8.8.8.8@1.2.3.4 or
server=8.8.8.8@eth0 will use random source
ports. server=8.8.8.8@1.2.3.4#66 or any use of --query-port will
use the explicitly configured port, and should only be done with
understanding of the security implications.
Note that this change changes non-existing interface, or non-local
source address errors from fatal to run-time. The error will be
logged and communiction with the server not possible.
If we add the EDNS client subnet option, or the client's
MAC address, then the reply we get back may very depending on
that. Since the cache is ignorant of such things, it's not safe to
cache such replies. This patch determines when a dangerous EDNS
option is being added and disables caching.
Note that for much the same reason, we can't combine multiple
queries for the same question when dangerous EDNS options are
being added, and the code now handles that in the same way. This
query combining is required for security against cache poisoning,
so disabling the cache has a security function as well as a
correctness one.
From 606d638918edb0e0ec07fe27eb68d06fb5ebd981 Mon Sep 17 00:00:00 2001
From: Miao Wang <shankerwangmiao@gmail.com>
Date: Fri, 4 Dec 2020 09:59:37 +0800
Subject: [PATCH v2] pxe: support pxe clients with custom vendor-class
According to UEFI[1] and PXE[2] specs, PXE clients are required to have
`PXEClient` identfier in the vendor-class field of DHCP requests, and
PXE servers should also include that identifier in their responses.
However, the firmware of servers from a few vendors[3] are customized to
include a different identifier. This patch adds an option named
`dhcp-pxe-vendor` to provide a list of such identifiers. The identifier
used in responses sent from dnsmasq is identical to that in the coresponding
request.
[1]: https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf
[2]: http://www.pix.net/software/pxeboot/archive/pxespec.pdf
[3]: For instance, TaiShan servers from Huawei, which are Arm64-based,
send `HW-Client` in PXE requests up to now.
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
Hi Simon,
> Add --shared-network config. This enables allocation of addresses
> the DHCP server in subnets where the server (or relay) doesn't
> have an interface on the network in that subnet. Many thanks to
> kamp.de for sponsoring this feature.
Does this paragraph lack a preposition "by" early on the 2nd line, or am
I mis-guessing the purpose?
...enables allocation of addresses *by* the DHCP server...
The manual page also seems to offer room for linguistic improvement
(apparently written by a German, so I see the typical patterns, and also
the misuse of which vs. that.
I am attaching a patch series vs. git to fix several issues in the
manpage and CHANGELOG.
From 35b88d98429e2fe016d9989d220f6faf2b933764 Mon Sep 17 00:00:00 2001
From: Matthias Andree <matthias.andree@gmx.de>
Date: Sun, 5 Apr 2020 11:18:05 +0200
Subject: [PATCH 1/5] man/dnsmasq.8: Properly capitalize DHCP acronym.
Same as for the dbus, allow specifying ubus service name (namespace) on
the command line as an optional argument to --enable-ubus option.
Signed-off-by: Oldřich Jedlička <oldium.pro@gmail.com>
If dnsmasq is not acting as an authoritative nameserver (no second
argument to --auth-server) then it should not appear in the NS RRset.
This leaves simply the list of servers specified in --auth-sec-servers.
When a request matching the clid or mac address is
recieved the server will iterate over all candidate
addresses until it find's one that is not already
leased to a different clid/iaid and advertise
this address.
Using multiple reservations for a single host makes it
possible to maintain a static leases only configuration
which support network booting systems with UEFI firmware
that request a new address (a new SOLICIT with a new IA_NA
option using a new IAID) for different boot modes, for
instance 'PXE over IPv6', and 'HTTP-Boot over IPv6'. Open
Virtual Machine Firmware (OVMF) and most UEFI firmware
build on the EDK2 code base exhibit this behaviour.
The idea of this option was already discussed years ago on the mailing
list:
https://dnsmasq-discuss.thekelleys.org.narkive.com/ZoFQNaGo/always-ignore-client-identifier#post4
In our production environnement, we discovered that some devices are
using 'client identifier' not unique at all, resulting on IP addresses
conflicts between several devices (we saw up to four devices using same
IP address).
The root cause is probably a buggy operating system/configuration of
decices, but this patch add a configuration workaround on server side
when fixing clients is impossible.
Signed-off-by: Charles Daymand <charles.daymand@wifirst.fr>
Signed-off-by: Florent Fourcot <florent.fourcot@wifirst.fr>
But make auth-server required when any auth-zones are defined.
The "glue record" field in auth-server is needed to synthesise
SOA and NS records in auth zones, so the --auth-server has to
be specified. If makes sense, however to define one or more
auth-zones that appear within the normal recursive DNS service
without actually acting as an authoritative DNS server on
any interface. Hence making the interface field optional.
The option was already described in the original manual page but was not
replicated in the french translation.
Reviewed-By: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
The use of "peut-être" should be spelled "peut être" (without the
hyphen) unless it can be replaced by "sans doute".
It is roughly the same difference between "maybe" and "may be".
As for "doit-être", it should always be spelled "doit être".
Reviewed-By: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Various typos were present along with spelling mistakes and grammar
errors. Some sentences were missing a few words to be easily
understandable.
Many of them probably remain though.
Reviewed-By: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
