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

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 15/02/17 17:38, Petr Mensik wrote:
> Hi!
> 
> 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 [1] 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,

Simon.




> 
> [1]
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d
7e7dba32b6e64a3687d43928bc8e
>
>  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 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrIvyAAoJEBXN2mrhkTWiWzgP/RKGiOwyCG+IU2MZ5Ax453rM
ALXKz6tyFX/TszMPBLScH65en3IgzL+PrjXDbZu2fXpZXgg957D20wBPfCDHfPxJ
fnBRdWUQpB0W/M8+INJMSrYX+JS5iHfxmm8/5X/zUhedMfB1zhmskOAiHBbcjxCy
vGSvczc9FTNv5Q0/WD9v08EJiEJOfNyOLAGIQILSzVa7HkYpD5nLsJ0rCavoKtFk
OFyK1pA5Kx9QwSlkn7vMco/OU5iTOF9bQ+a7sYJp3mRhXtNdW41HMTEE8J57+tlP
OMkDaKCWnlXDzVfVD0q1cK36aof5IUXukGuuhOx6mEFKSLtpmoZWP7qAhX73KZYk
SKgnnWwZrNgDo5TFYdhCeSIco7bFnQtSgSHgX9VNv/QcLZzZxUfrxbpgyzLO4fvK
TO1YOq8RyHDfHxjS7L8QrPceRck/558L0mNgB09G8y75vIHMNPGghHzCL4AkL1VO
krFCiDrr4GEsGEWx/J2HWagFsRzavFzWAHdkgr2tQ3i7ATThV7+p3tcU164hYoOu
b7fbQk3O+GIpkvuzdG4UWZ4SmrbQ4kl6Q6MMgMsZfXGXqX7SrYXoobn0vPulZxm2
y6SfCTgbjUqTjfkNBNZM3wZyoM77pNhzIZiibHTr388fgbt/5L1xSavlwJqmR5VV
VXeTleBo8BUem7W6BV1B
=pWPX
-----END PGP SIGNATURE-----