When dhcp-host options can have many IPv6 addresses, we need
to deal with one of them being declined by a client. The other
addresses are still valid.
It seems that this logic never worked, even with only one address, since
the DECLINED flag was never tested.
Route lookup in Linux is bounded by `ip rules` as well
as the contents of specific routing tables. With the
advent of vrf's(l3mdev's) non-default tables are regularly being
used for routing purposes.
dnsmasq listens to all route changes on the box and responds
to each one with an event. This is *expensive* when a full
BGP routing table is placed into the linux kernel, moreso
when dnsmasq is responding to events in tables that it will
never actually need to respond to, since dnsmasq at this
point in time has no concept of vrf's and would need
to be programmed to understand them. Help alleviate this load
by reducing the set of data that dnsmasq pays attention to
when we know there are events that are not useful at this
point in time.
Signed-off-by: Donald Sharp <donaldsharp72@gmail.com>
Errors encountered if building with 'NO_DHCP6' introduced by
commit 137286e9ba
option.c: In function 'dhcp_config_free':
option.c:1040:24: error: 'struct dhcp_config' has no member named 'addr6'; did you mean 'addr'?
for (addr = config->addr6; addr; addr = tmp)
^~~~~
addr
option.c: In function 'one_opt':
option.c:3227:7: error: 'struct dhcp_config' has no member named 'addr6'; did you mean 'addr'?
new->addr6 = NULL;
^~~~~
addr
Wrap new code in ifdef HAVE_DHCP6
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Dnsmasq needs to close all the file descriptors it inherits, for security
reasons. This is traditionally done by calling close() on every possible
file descriptor (most of which won't be open.) On big servers where
"every possible file descriptor" is a rather large set, this gets
rather slow, so we use the /proc/<pid>/fd directory to get a list
of the fds which are acually open.
This only works on Linux. On other platforms, and on Linux systems
without a /proc filesystem, we fall back to the old way.
Make the existing "insecure DS received" warning more informative by
reporting the domain name reporting the issue.
This may help identify a problem with a specific domain or server
configuration.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Instead, check only local configured entries are answered without
rdbit set. All cached replies are still denied, but locally configured
names are available with both recursion and without it.
Fixes commit 4139298d28 unintended
behaviour.
When dnsmasq forks a child to handle a TCP connection, that
child inherits the netlink socket that the main process has open.
The child never uses that socket, but there's a chance that when the
main process uses the netlink socket, the answer will go to a child
process which has a copy of the socket. This causes the main process
to block forever awaiting the answer which never comes.
The solution is for the child process to close the netlink socket it
inherits after the fork(). There's a nasty race because the error
decribed above could still occur in the window between the fork()
and the close() syscalls. That's fixed by blocking the parent awaiting
a single byte sent though the pipe the two processes share. This byte
is sent by the child after calling close() on the netlink socket.
Thanks to Alin Năstac for spotting this.
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 previous code here, which started fast-RA whenever that local
address associated with a DHCP context changed, is very vulnerable
to flapping due to dynamically created addresses in the same net.
Simplify so that if a context which has never found an interface now
finds one, that gets advertised, but not for other changes. That satisfies
the original intention that prefixes not in place when dnsmasq starts
should be recognised.
Also totally ignore all interfaces where we are configured not to do DHCP,
to preclude flapping of they have prefixes in common with interfaces
where we do DHCP.
Fail on overlarge files (block numbers are limited to 16 bits)
Honour tftp-max setting in single port mode.
Tweak timeouts, and fix logic which suppresses errors if the
last ACK is missing.
Hello,
My home network has a DNS search domain of home.arpa and my machine's dnsmasq
instance is configured with:
server=/home.arpa/192.168.0.1
server=//192.168.0.1
stop-dns-rebind
rebind-domain-ok=home.arpa
rebind-domain-ok=// # Match unqualified domains
Querying my router's FQDN works as expected:
dnsmasq: query[A] gateway.home.arpa from 127.0.0.1
dnsmasq: forwarded gateway.home.arpa to 192.168.0.1
dnsmasq: reply gateway.home.arpa is 192.168.0.1
But using an unqualified domain name does not:
dnsmasq: query[A] gateway from 127.0.0.1
dnsmasq: forwarded gateway to 192.168.0.1
dnsmasq: possible DNS-rebind attack detected: gateway
The attached patch addresses this issue by checking for SERV_NO_REBIND when
handling dotless domains.
>From 0460b07108b009cff06e29eac54910ec2e7fafce Mon Sep 17 00:00:00 2001
From: guns <self@sungpae.com>
Date: Mon, 30 Dec 2019 16:34:23 -0600
Subject: [PATCH] Check for SERV_NO_REBIND on unqualified domains
Calling lease_update_file() _can_ result in a call to periodic_ra()
Since both the DHCPv6 and RA subsystems use the same packet buffer
this can overwrite the DHCPv6 packet. To avoid this we ensure the
DHCPv6 packet has been sent before calling lease_update_file().
