[Dnsmasq-discuss] Support of labels in --interface
simon at thekelleys.org.uk
Tue Feb 21 18:50:26 GMT 2017
-----BEGIN PGP SIGNED MESSAGE-----
On 15/02/17 17:38, Petr Mensik wrote:
> I am new maintainer of dnsmasq package in RHEL. I am looking for
> potential problems with upgrade from dnsmasq 2.66 to version 2.76.
> And I have found something. Commit  changed behaviour of
> --interface eth0:0 behavior.
> The first problem is, manual page is not updated. It tells you
> cannot use labels, but you can. Also it does not tell you you can
> use -i eth0,eth0:0,eth0:1,lo, but that is minor change.
Documentation point taken.
> 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 192.168.122.1/24 brd 192.168.122.255 scope
> global virbr0 valid_lft forever preferred_lft forever inet
> 192.168.122.254/24 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 192.168.122.254. Ok, call
> it a feature.
> Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
> 192.168.122.1, 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.
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 192.168.122.1 and 192.168.122.254 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.
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?
> Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
> http://www.redhat.com/ email: pemensik at redhat.com PGP: 65C6C973
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Dnsmasq-discuss