Hi,

with dnsmasq 2.90 I try to perform lookups from within a separate VRF:

server=62.109.121.17@EXTVRF0
server=62.109.121.18@EXTVRF0

As expected %EXTVRF0 is set for the ports:

# nslookup google.at 127.0.0.1 & ss -aneup | grep dnsmasq
UNCONN 0      0                     0.0.0.0%EXTVRF0:24227
0.0.0.0:*    users:(("dnsmasq",pid=20890,fd=21)) ino:131069 sk:301f
cgroup:/ <->
UNCONN 0      0                     0.0.0.0%EXTVRF0:30488
0.0.0.0:*    users:(("dnsmasq",pid=20890,fd=22)) ino:131070 sk:3021
cgroup:/ <->

But later %EXTVRF0 goes missing:

# nslookup google.de 127.0.0.1 & ss -aneup | grep dnsmasq
UNCONN 0      0                             0.0.0.0:8647
0.0.0.0:*    users:(("dnsmasq",pid=14818,fd=22)) ino:131106 sk:1021
cgroup:/ <->
UNCONN 0      0                             0.0.0.0:28338
0.0.0.0:*    users:(("dnsmasq",pid=14818,fd=21)) ino:131105 sk:1022
cgroup:/ <->

The first case works with net.ipv4.udp_l3mdev_accept=0, i.e. the
return packets being contained inside the VRF device. The second only
works with net.ipv4.udp_l3mdev_accept=1.

Skimming over the code I see local_bind() in network.c use
SO_BINDTODEVICE when it has no ifindex but
IP_UNICAST_IF/IPV6_UNICAST_IF once it obtained an ifindex.
IP_UNICAST_IF seems to only affect outgoing packets (unlike
SO_BINDTODEVICE), which would match the observed behavior.

It looks like the change in behavior can be triggered by touching the
interface that dnsmasq listens on (ip l s X down/up).
Presumably the interface change indirectly causes the ifindex to be
stored in the server struct.

I think it needs to use either
a) SO_BINDTODEVICE/SO_BINDTOIFINDEX or
b) IP*_UNICAST_IF with a ifindex lookup when index is unknown
but not a mix of these. Maybe even a way to pick a/b, since they both
may be useful for different setups (and apparently the second requires
fewer privileges).

Unrelated, but this looked suspicious: add_update_server may reuse an
existing entry and overwrite serv->interface without resetting
serv->ifindex.

Regards,
Michael Bruck

_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss