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

[Simon Kelley]

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
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss