[Dnsmasq-discuss] server= with interface parameter changes behavior over time

[Michael Bruck]

For the scenario described in the patch it ends up using
SO_BINDTODEVICE until ifindex is filled in by unrelated events. So
those users may see inconsistent behavior.

At the time that patch was added allocate_sfd() contained a hardwired
lookup before the call to local_bind():

if (intname && strlen(intname) != 0)
  ifindex = if_nametoindex(intname); /* index == 0 when not binding to
an interface */

That is gone now. In 2.90 a lookup seems to happen only in
enumerate_interfaces().
Presumably that lookup doesn't happen in my case and ifindex is not
filled in. If this is relevant: I am using --bind-interfaces.

Regards,

Michael


Am Mo., 4. Mai 2026 um 22:58 Uhr schrieb Simon Kelley <simon at thekelleys.org.uk>:
>
> 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
> >
>