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

Wed Dec 3 22:55:12 UTC 2025

> 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.

You're right. That was imprecise mental shortcut.

> 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.

The thing is it only has the IPv6 address. This is how Calico (or the OS
- I'm not entirely sure) configures it.

> Your description implies that the TCP connection is over IPv4. Does the
> interface is arrives on have an IP4 address?

Destination is a regular eth0 iface on the server with IPv4 address only.
The connection originates from a Pod that is connected through veth pair.
That veth pair has only IPv6 address in the system.

> As usual, the most useful resource here is the simplest configuration
> which demonstrates this problem on the most vanilla kernel network
> configuration.

I'm not sure if that's the most vanilla way out there, but I believe that
Calico does something along following. I'm not sure if the proxy_arp
thing is necessary. With following I was able to reproduce the problem.

# ip netns add fakepod
# ip link add host-veth type veth peer name pod-veth
# ip link set pod-veth netns fakepod
# ip link set host-veth up
# echo 1 | sudo tee /proc/sys/net/ipv4/conf/host-veth/proxy_arp
# ip netns exec fakepod bash
# ip link set lo up
# ip link set pod-veth up
# ip addr add 10.44.0.51/32 dev pod-veth
# ip route add default dev pod-veth
# ip route add 169.254.1.1/32 dev pod-veth
# exit
# ip route add 10.44.0.51/32 dev host-veth

Now, start dnsmasq on the host:
# sudo ./src/dnsmasq -d --log-debug 2>&1 | tee /tmp/dnsmasq.log

And trigger the behavior:
# ip netns exec fakepod dig duckduckgo.com. A +tcp @[REDACTED: server eth0
physical IPv4 address]
;; communications error to [REDACTED: server eth0 physical IPv4
address]#53: end of file

;; communications error to [REDACTED: server eth0 physical IPv4
address]#53: end of file

This is, by the way, how the iface shows up in the system:
266: host-veth at if265: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
    link/ether d6:35:97:b9:51:f0 brd ff:ff:ff:ff:ff:ff link-netns fakepod
    inet6 fe80::d435:97ff:feb9:51f0/64 scope link
       valid_lft forever preferred_lft forever

And dnsmasq will recognize it as IPv6. I added some debug prints
to verify that it happens. Incoming TCP addr sa_family is 0x2, iface
sa_family is 0xA.

I think the IPv6 address that is attached to the veth host end is added
by the OS.

Hopefully all of the above is helpful.

On Wed, Dec 3, 2025 at 10:34 PM Simon Kelley <simon at thekelleys.org.uk>
wrote:

>
>
> 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
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20251203/5bb20d8d/attachment-0001.htm>