[Dnsmasq-discuss] server= with interface parameter changes behavior over time
Simon Kelley
simon at thekelleys.org.uk
Mon May 4 20:58:30 UTC 2026
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 at EXTVRF0
> server=62.109.121.18 at 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
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
More information about the Dnsmasq-discuss
mailing list