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

[Nicolas Cavallari]

On 12/3/25 23:55, Sławomir Zborowski wrote:
>  > 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 <http://10.44.0.51/32> dev pod-veth
> # ip route add default dev pod-veth
> # ip route add 169.254.1.1/32 <http://169.254.1.1/32> dev pod-veth
> # exit
> # ip route add 10.44.0.51/32 <http://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 <http://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.

So basically, dnsmasq receives a TCP connection from 10.44.0.51 to [redacted] 
through the host-veth interface, but the host-veth interface only have a ipv6 
link-local and no ipv4.  [redacted] is actually configured on eth0.

It is quite difficult for a TCP server to know from which an interface a request 
comes from. Finding the interface where the destination address was configured 
only works on systems with a strong host model, but linux uses a weak host model 
and your setup rely on it.

A weak host model system will accept packets from 10.44.0.51 to [redacted] 
regardless of the interface the packet came from.  And replies are sent to 
whatever interface the FIB says should be used and the interface may change over 
time.

A workaround would be to use RTM_GETROUTE on the source address and consider 
that as the interface the request came from, but that could cause other problems.