On 12/3/25 12:39, Sławomir Zborowski wrote:
Hello,
In the source code (commit eb601683820723df89858cfa695aa131012f1a63),
in function `do_tcp_connection` client connections are checked. At least
when options like
OPT_NOWILD are not enabled.
The code seems to go through all interfaces reported by the OS and find
matching one
before allowing query to proceed further.
Following piece of code seems to be responsible for finding matching iface:
for (iface = daemon->interfaces; iface; iface = iface->next)
if (iface->index == if_index && iface->addr.sa.sa_family ==
tcp_addr.sa.sa_family)
break;
However, in some Kubernetes setups, at least in these which use Calico for
networking, the network interfaces show up as IPv6, so iface-
>adrrs.sa.sa_family
is AF_INET6, but the traffic that goes through is IPv4, so
tcp_addr.sa.sa_family
is AF_INET.
Unfortunately I'm not well-educated w.r.t. IPv6, so I don't understand
how it's
all realized, but due to that mismatch, TCP connections are abruptly
closed and entire
downstream fails. In our case it's CoreDNS that considers dnsmasq
unhealthy and
bombards it with health checks NS <Root>.
Now, this can be fixed by using bind-interfaces/-z, but that seems to be
bad choice,
as per the manual, which reads:
> About the only time when this is useful is when running another
nameserver
> (or another instance of dnsmasq) on the same machine.
My question is whether the AF_INET/AF_INET6 mismatch is handled correctly?
Shouldn't dnsmasq allow ipv4 queries originating from inet6 ifaces?
There's not really such a thing as an "inet interface" or an "inet6
interface" an interface, represented by an index, can have multiple
addresses, both IPv4 and IPv6.
What I would expect to see here is that the interface had both IPv4
addresses and IPv6 addresses when it was added to the daemon->interfaces
list, so this check will find at least one entry on that list which came
from the arrival interface and has the correct address family.
Your description implies that the TCP connection is over IPv4. Does the
interface is arrives on have an IP4 address?
If it does, did it have an IPv4 address when dnsmasq was started? There
may be problems with dnsmasq tracking changes to network configuration.
If it doesn't, that's very odd and needs more investigation.
As usual, the most useful resource here is the simplest configuration
which demonstrates this problem on the most vanilla kernel network
configuration.
Cheers,
Simon.
An if not, I assume that workaround should be placed elsewhere?
--
Best Regards, Sławomir Zborowski
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
