In the most common case, an IPv6 address doesn't have a peer and the
IFA_ADDRESS netlink attribute contains the address itself.
But if the address has a peer (typically for point to point links),
then IFA_ADDRESS contains the peer address and IFA_LOCAL contains the
address [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c?h=v5.17#n5030
Fix the parsing of IPv6 addresses with peers, as currently dnsmasq
unsuccessfully tries to bind on the peer address.
A simple reproducer is:
dnsmasq --conf-file=/dev/null -i dummy1 -d --bind-dynamic &
sleep 2
ip link add dummy1 type dummy
ip link set dummy1 up
ip addr add dev dummy1 fd01::1/64 peer fd01::2/64
ip addr add dev dummy1 fd01::42/64
sleep 2
ss -lnp | grep dnsmasq | grep fd01
Before the patch:
dnsmasq: failed to create listening socket for fd01::2: Cannot assign requested address
dnsmasq: failed to create listening socket for fd01::2: Cannot assign requested address
udp UNCONN 0 [fd01::42]:53 [::]:* users:(("dnsmasq",pid=23947,fd=14))
tcp LISTEN 0 [fd01::42]:53 [::]:* users:(("dnsmasq",pid=23947,fd=15
After:
udp UNCONN 0 [fd01::42]:53 [::]:* users:(("dnsmasq",pid=23973,fd=16))
udp UNCONN 0 [fd01::1]:53 [::]:* users:(("dnsmasq",pid=23973,fd=14))
tcp LISTEN 0 [fd01::42]:53 [::]:* users:(("dnsmasq",pid=23973,fd=17))
tcp LISTEN 0 [fd01::1]:53 [::]:* users:(("dnsmasq",pid=23973,fd=15))
This change also removes a previous bug
where --dhcp-alternate-port would affect the port used
to relay _to_ as well as the port being listened on.
The new feature allows configuration to provide bug-for-bug
compatibility, if required. Thanks to Damian Kaczkowski
for the feature suggestion.
Fix a bug found on OpenWrt when IPv4/6 dual stack enabled:
The resolv file is located on tmpfs whose mtime resolution
is 1 second. If the resolv file is updated twice within one
second dnsmasq may can't notice the second update.
netifd updates the resolv file with method: write temp then move,
so adding an inode check fixes this bug.
This allows hosts get a domain which relects the interface they
are attached to in a way which doesn't require hard-coding addresses.
Thanks to Sten Spans for the idea.
On machines with many interfaces, enumerating them
via netlink on each packet reciept is slow,
and unneccesary. All we need is the local address->interface
mapping, which can be cached in the relay structures.
Some systems strips even root process capability of writing to different
users file. That include systemd under Fedora. When
log-facility=/var/log/dnsmasq.log is used, log file with mode 0640
is created. But restart then fails, because such log file can be used
only when created new. Existing file cannot be opened by root when
starting, causing fatal error. Avoid that by adding root group writeable flag.
Ensure group is always root when granting write access. If it is
anything else, administrator has to configure correct rights.
There are two functional changes in this commit.
1) When searching for an in-flight DNSSEC query to use
(rather than starting a new one), compare the already
sent query (stored in the frec "stash" field, rather than
using the hash of the query. This is probably faster (no hash
calculation) and eliminates having to worry about the
consequences of a hash collision.
2) Check for dependency loops in DNSSEC validation,
say validating A requires DS B and validating DS B
requires DNSKEY C and validating DNSKEY C requires DS B.
This should never happen in correctly signed records, but it's
likely the case that sufficiently broken ones can cause
our validation code requests to exhibit cycles.
The result is that the ->blocking_query list
can form a cycle, and under certain circumstances that can lock us in
an infinite loop.
Instead we transform the situation into an ABANDONED state.
Previously, hash_questions() would return a random hash
if the packet was malformed, and probably the hash of a previous
query. Now handle this as an error.
The 2.86 upstream server rewrite severely broke re-reading
of server configuration. It would get everyting right the first
time, but on re-reading /etc/resolv.conf or --servers-file
or setting things with DBUS, the results were just wrong.
This should put things right again.