Thanks for this,
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=9d6918d32cafde4cd99c58d5c0c1d46ab328bc5e
and especially its commit message, is relevant.
I'll try and get back to looking at this in a week or so, please prod me
again if I don't.
Cheers,
Simon.
On 27.04.2026 06:43, Michael Bruck wrote:
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
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
