[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