On 09/23/2016 02:43 PM, Martin Wilck wrote:
On Fri, 2016-09-23 at 11:56 -0400, Laine Stump wrote:
Martin's patch tries to solve the problem with "dhcp-authoritative"
which, as far as I understand, tells dnsmasq "you are the keeper of
*all* lease information on this network, so if you think the address
is
unused, it really is unused"; dnsmasq uses this information to
freely
grant a guest any address it asks for, as long as there is no
current
lease for it. This sounds troublesome to me - If client A's lease
has
expired (because it's turned off for a bit), is it okay for client B
to
come barging in and insist on grabbing the address that client A has
just lost even though there are many other addresses still
available?
Sure, technically it's legal, but it seems unnecessarily disruptive.
I am not sure what you mean. What scenario would be "disrupted" by this
approach?
Disruptive may not have been the best word. What I mean is that an
unfriendly guest with proper information could take advantage of this "give
any currently-unused address to anyone who asks for it" policy by
purposefully taking over an IP address that it knew had previously been
leased to a different guest (and who was expecting on getting the address
back the next time it booted). Of course 1) it would take a lot of inside
knowledge / good timing / luck to make this happen, and 2) you can argue
that any guest who relied on a dhcp address remaining unchanged deserves
what it gets (and the same for any other machine trying to contact that
guest via the IP address).
Without dhcp_authoritative, client A will not get its lease back,
Is that true even if dnsmasq isn't restarted, and even if leasefile-ro isn't
used? The Openstack discussion on this topic implies that the behavior only
exists because they aren't saving a leasefile, not just because the lease is
expired.
whether or not B applied for it in the meantime, and B wouldn't get the
lease, either. The user wouldn't be able to ping either one. If
dhcp_authoritative is used, at least one of them will get what it needs
(and serving both is impossible - it's hard to tell what's the Right
Thing in the situation you describe!).
Well, I guess it's a policy decision, but I would tend toward *not* allowing
B to demand a particular IP address that it has never before been given.
Anyway, unless the virtual network is really crowded (in which case it
might make sense for the admin to use a class B network instead) the
probability of such clashes should be rather minimal in the real world.
It's much more likely that A itself tries to reacquire the lease, and
that situation is fixed by dhcp_authoritative.
Yeah, as long as the guests are all friendly. My concern is with unfriendly
guests.
I think the *real* solution is to fix the lease handling so that
dnsmasq
remembers leases after they've expired (assuming that can be done
once
leasefile-ro is set). They would be marked as "expired", and
probably
not even reported externally, but all their info would still be
there
internally for dnsmasq's use when considering what to do with
incoming
requests for specific IP addresses.
Is that possible at all with the current leasehelper setup?
"maybe"? See Nehal's recent email - we weren't notifying dnsmasq of expired
leases, and that could be the source of the problem (or not, I didn't
understand if he's verified whether doing so actually causes dnsmasq to
accept the requests for expired addresses). If that works, then the problem
is solved. If not, then we may need to consider using dhcp-authoritative.