[Dnsmasq-discuss] Support of labels in --interface

Petr Menšík pemensik at redhat.com
Wed Feb 22 21:52:04 GMT 2017

Simon Kelley píše v Út 21. 02. 2017 v 18:50 +0000:
> > Labels are now supported and dnsmasq is able to bind only to
> > secondary IPv4 interface with different address. (Since 2.67!) It
> > works well with --bind-interfaces. However it has inconsistent
> > behavior with and without that option.
> > 
> > Let's say my configuration is: 4: virbr0:
> > <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
> > group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> > ff:ff:ff:ff:ff:ff inet brd scope
> > global virbr0 valid_lft forever preferred_lft forever inet
> > scope global secondary virbr0:1 valid_lft
> > forever preferred_lft forever
> > 
> > 
> > $ dnsmasq -i virbr0 will respond to queries to both addresses. It
> > might be useful backward compatibility feature. However $ dnsmasq
> > -i virbr0:1 Will respond only on address Ok, call
> > it a feature.
> > 
> > Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
> >, as I would expect.
> > 
> > $ dnsmasq -i virbr0:1 -z Behaves the same way, as without -z.
> > 
> > I think different behavior is an error. It might be a feature, but
> > even then, it has to be documented. Opinions?
> The different behavior is certainly undesirable, and can be fixed.
> Unfortunately, I can only see how to easily fix it so that the
> --bind-interfaces case works the same way as the default.
I would suggest a new option then. For example --bind-interfaces-exact. 
It would listen just like --bind-interfaces, but would allow you to
listen only on virbr0, when ignoring any addresses with labels. Current
behavior in other words, but documented as a new feature. It would
allow previous behavior at the same time also.
> The problem is that the sockets API tells you the interface that the
> packet arrived on, and that's what's checked with -i. In your
> example,
> queries send to and both arrive at
> interface virbr0, so there's no easy way to tell them apart, except
> by
> looking at the address they were sent to and correlating that with
> the
> list of interfaces and their addresses .
> That requires an up-to-date list of all interfaces, which means, if
> you're going to behave well in the face of interfaces and addresses
> coming and going, enumerating the list for every packet received,
> which will likely kill performance.
I think this already happens if you listen on virbr0:1.

Another option might be getting interface address of by index. If they
would not match with destination of packet, return failure from
iface_check (and let it be accepted by label_exception). You would not
have to enumerate all addresses of all interfaces, only one for current
interface. It adds one more syscall, but it should be faster than
getifaddrs(). ioctl SIOCGIFADDR is already used in dhcp.c.
> My feeling is that consistency is good, so I'll certainly make a
> change, the question is, is the current behaviour of -i <interface
> name> as encompassing _all_ addresses associated with the interface
> OK?
I think it is unexpected and should be mentioned in manual page. But it
acted like that before, so it would be not break backward compatibility
at least. If it is fixed in default wild mode, we should note that -i
virbr0,virbr0:* is now required for previous behavior in manual.
> Cheers,
> Simon.
> > 
> > [1]
> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42
> > c4d
> 7e7dba32b6e64a3687d43928bc8e
> > 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com  PGP: 65C6C973
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20170222/afc40cb1/attachment-0001.sig>

More information about the Dnsmasq-discuss mailing list