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().
Cope with cached and configured CNAMES for all record types we
support, including local-config but not cached types such as TXT.
Also, if we have a locally configured CNAME but no target for the
requested type, don't forward the query.
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>
Some REFUSED answers to DNSSEC-originated queries would
bypass the DNSSEC code entirely, and be returned as answers
to the original query. In the process, they'd mess up datastructures
so that a retry of the original query would crash dnsmasq.
In a reply proving that a DS doesn't exist, it doesn't matter if RRs
in the auth section _other_ than NSEC/NSEC3 are not signed. We can't
set the AD flag when returning the query, but it still proves
that the DS doesn't exist for internal use.
As one of the RRs which may not be signed is the SOA record, use the
TTL of the NSEC record to cache the negative result, not one
derived from the SOA.
Thanks to Tore Anderson for spotting and diagnosing the bug.
If the cache size is very large, the malloc() call will overflow
on 32 bit platforms and dnsmasq will crash. Limit to an order of
magnitude less.
Thanks to Lili Xu for spotting this.
- aligned the handling of UBus connections with the DBus code as it
makes it a bit easier to comprehend;
- added logging to the various UBus calls to aid debugging from an
enduser point of view, but be careful to not flood the logs;
- show the (lack of) support for UBus in the configuration string.
