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

[Petr Mensik]

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.

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?

[1] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d7e7dba32b6e64a3687d43928bc8e

Cheers,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: ***@redhat.com PGP: 65C6C973

[Simon Kelley]

Post by Petr Mensik
Hi!
<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

Quick question from the lazy: how do you set the "secondary" flag on
the second address?

ip addr add <address> dev virbr0 label virbr0:1

doesn't seem to.

Dunno if it matters, just want to replicate this exactly........


Cheers,

Simon.

[Petr Mensik]

I think it is automatic if there is already IP from the same subnet on that interface.

$ ip a add 192.168.122.1/24 dev virbr0
# no secondary flag yet, first address of 192.168.122.0/24
$ ip a add 192.168.122.254/24 dev virbr0 label virbr0:1
# secondary flag present, it is second address of 192.168.122.0/24 on that device
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: ***@redhat.com PGP: 65C6C973

----- Original Message -----
From: "Simon Kelley" <***@thekelleys.org.uk>
To: dnsmasq-***@thekelleys.org.uk
Sent: Friday, February 17, 2017 1:16:59 PM
Subject: Re: [Dnsmasq-discuss] Support of labels in --interface

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

Post by Petr Mensik
Hi!
<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

Quick question from the lazy: how do you set the "secondary" flag on
the second address?

ip addr add <address> dev virbr0 label virbr0:1

doesn't seem to.

Dunno if it matters, just want to replicate this exactly........


Cheers,

Simon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYpum7AAoJEBXN2mrhkTWi74gP/A1nDuRres/jwNlJBBa1Ooa1
GFS3gGsMTxlZpank4bsH9MUnezzLMwkTa/F3Pz2jztnVzGwSplmZqtqFQErYaLWR
wyJXGGeNNlRt/u2dChLMWTO/qyf2AVfa+Ght66npzwJ0laVVkBishPHDcCKPhLIY
Rv5+WSsgqFgUwMFpjj8xj0WJJU7iNjCG4G9dwlmHu9kElwnW9xiL9dC6dDZuLOrd
GHlDodp7c5L5R7UQkvnfmlLWCOgz6/21Z1LkLBlsDyjpQcX+e7G5shb7r2UEEX0o
5RX2+3utnyGAGysiaVF9logiGCN7Hx/dBhvwtrvdcDSxa944GavLtHVSftuwIGZG
RDZIMea2DixSJUuOjGJ0MIfLg6IeoigSGIlNgLP++EupOz6fqxT2iJbaQ0M4Mqtm
H6haQkMT7Xj5OUfdfptXmR89idQRoPP7WIGU8CPQrs70vLpdGwKoF7nbT3KqeVpK
C+9CvHAxFKtWoElIzVPn7Oa2Zz/alXBBXdIfRg5TEP0QrJZCgPBixZ9Yy5F2fVxE
fP88SazdH7Yq6HDlS6KfPPq6N+0IklD0Y6GoBcchxxPpJpKFCkhXAS8EKFb04QLg
ZgPOzu73LFmed9YAXSFggR+eMmxN2M5ImPidiW8/xLCvHgtvn3/EOEi3VcU2gOS6
wczS9ivnbdarmpyPP4i/
=8wXW
-----END PGP SIGNATURE-----

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-***@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Simon Kelley]

Post by Petr Mensik
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.

Post by Petr Mensik
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.
<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.

Post by Petr Mensik
[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d

7e7dba32b6e64a3687d43928bc8e

Post by Petr Mensik
Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Brüns, Stefan]

Post by Simon Kelley
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?

You can get the destination address for datagrams from the IP_PTKINFO
auxiliary data:

man 7 ip
IP_PKTINFO (since Linux 2.2)
              Pass an IP_PKTINFO ancillary message that contains a
pktinfo structure that supplies some information about the incoming
packet.
              This only works for datagram oriented sockets.  The
argument is a flag that tells the socket whether the IP_PKTINFO message
should be passed or not. The message itself can only be sent/retrieved
as control message with a packet using recvmsg(2) or sendmsg(2).

    struct in_pktinfo {
        unsigned int   ipi_ifindex;  /* Interface index */
        struct in_addr ipi_spec_dst; /* Local address */
        struct in_addr ipi_addr;     /* Header Destination address */
    };

Kind regards,

Stefan

[Simon Kelley]

Post by Brüns, Stefan
You can get the destination address for datagrams from the
man 7 ip IP_PKTINFO (since Linux 2.2) Pass an IP_PKTINFO ancillary
message that contains a pktinfo structure that supplies some
information about the incoming packet. This only works for datagram
oriented sockets. The argument is a flag that tells the socket
whether the IP_PKTINFO message should be passed or not. The message
itself can only be sent/retrieved as control message with a packet
using recvmsg(2) or sendmsg(2).
struct in_pktinfo { unsigned int ipi_ifindex; /* Interface index
*/ struct in_addr ipi_spec_dst; /* Local address */ struct in_addr
ipi_addr; /* Header Destination address */ };

Indeed. And that gives you, in one hand, the destination address of
the datagram, and in the other hand, a whitelist of interface labels.
The only way to compare the two is to enumerate all the interfaces
using the netlink interface, which gives you all the addresses of each
interface and their associated labels. If the interface set and
configuration can change arbitrarily, you need to do that for every
datagram, which gets expensive.


Cheers,

Simon.

[Brüns, Stefan]

Post by Simon Kelley

Post by Brüns, Stefan
You can get the destination address for datagrams from the
man 7 ip IP_PKTINFO (since Linux 2.2) Pass an IP_PKTINFO ancillary
message that contains a pktinfo structure that supplies some
information about the incoming packet. This only works for datagram
oriented sockets.  The argument is a flag that tells the socket
whether the IP_PKTINFO message should be passed or not. The message
itself can only be sent/retrieved as control message with a packet
using recvmsg(2) or sendmsg(2).
struct in_pktinfo { unsigned int   ipi_ifindex;  /* Interface index
*/ struct in_addr ipi_spec_dst; /* Local address */ struct in_addr
ipi_addr;     /* Header Destination address */ };

Indeed. And that gives you, in one hand, the destination address of
the datagram, and in the other hand, a whitelist of interface labels.
The only way to compare the two is to enumerate all the interfaces
using the netlink interface, which gives you all the addresses of each
interface and their associated labels. If the interface set and
configuration can change arbitrarily, you need to do that for every
datagram, which gets expensive.

But you can also be notified about interface changes via a netlink
socket, so you can cache the interface information.

Regards,

Stefan

[Simon Kelley]

Post by Brüns, Stefan
But you can also be notified about interface changes via a netlink
socket, so you can cache the interface information.

See my reply to Petr: there is an option for that but it's not the
default for historical reasons.



Cheers,

Simon.

[Petr Menšík]

Post by Simon Kelley

Post by Petr Mensik
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.
<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.

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.

Post by Simon Kelley
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.

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.

Post by Simon Kelley
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.

Post by Simon Kelley
Cheers,
Simon.

Cheers,
Petr

Post by Simon Kelley

Post by Petr Mensik
[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42
c4d

7e7dba32b6e64a3687d43928bc8e
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Simon Kelley]

Post by Petr Menšík
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.

Ugh. There are already _three_ different modes for this.

The default (bind wildcard address), bind-interfaces (bind individual
addresses) and bind-dynamic (bind individual addresses, keep up with
changes in interface config)

On linux, there's actually no sane reason not to use --bind-dynamic,
and it's only not the default for historical reasons. The other two
modes still exist for *BSD where bind-dynamic doesn't exist and you
have the Hobson's choice of the other two: which is least-bad
depending on circumstances.

Since labels are a Linux-only thing, AFAIK, this whole problem may
best be solved by mandating that --bind-dynamic should be used on
linux if you want labels to work, and generating warnings if an label
!= interface name is found in the default mode. Or possibly ignoring
labels entirely in the default mode. And documenting same and that
- --bind-dynamic is needed to use labels. (or maybe --bind-dynamic or
- --bind-interfaces)


Apart from the documentation changes, that would involve removing
label_exception, so pre-2.67 behavior would return for the default
mode, ie --interface must give an interface name and label-aware
behavior would exist in --bind-dynamic ie --interface must give a label.


This stuff is all horrible: it's really difficult to even explain what
it's for and why it needs to be configured.

Cheers,

Simon.

[Petr Menšík]

Hi,

I have prepared two patches with suggestion how to fix it.

Patch 1 warns when a label is used for --interface in default mode.
Patch 2 corrects manual page about real behavior of --interface with
labels. Feel free to change it, I am not very good at complicated
sentences in English.

I think changing it back again to use all addresses including labels
would be wrong. Let's just warn user about unexpected results.

Hope that helps,
Petr

Post by Simon Kelley

Post by Petr Mensik
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.

Post by Petr Mensik
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.
<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.

No, please don't do that. I think current state is the best version we
can prepare now. Just correct the documentation and warn user if he or
she tries to use unsupported combination.

Post by Simon Kelley
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.

Post by Petr Mensik
[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d

7e7dba32b6e64a3687d43928bc8e

Post by Petr Mensik
Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Simon Kelley]

That seems a good solution. Patch applied, with the man=page changes
re-written and expanded.


Cheers,

Simon.

Post by Petr Menšík
Hi,
I have prepared two patches with suggestion how to fix it.
Patch 1 warns when a label is used for --interface in default mode.
Patch 2 corrects manual page about real behavior of --interface with
labels. Feel free to change it, I am not very good at complicated
sentences in English.
I think changing it back again to use all addresses including labels
would be wrong. Let's just warn user about unexpected results.
Hope that helps,
Petr

Post by Simon Kelley

Post by Petr Mensik
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.

Post by Petr Mensik
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.
<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.

No, please don't do that. I think current state is the best version we
can prepare now. Just correct the documentation and warn user if he or
she tries to use unsupported combination.

Post by Simon Kelley
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.

Post by Petr Mensik
[1]
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d

7e7dba32b6e64a3687d43928bc8e

Post by Petr Mensik
Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss