[Dnsmasq-discuss] dnsmasq rejects TCP queries originating from Kubernetes pods

[Sławomir Zborowski]

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?

An if not, I assume that workaround should be placed elsewhere?

-- 
Best Regards, Sławomir Zborowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20251203/881b7c80/attachment.htm>