[Dnsmasq-discuss] DHCP lease hostname with multiple hosts of the same name

Simon Kelley simon at thekelleys.org.uk
Mon Jul 5 20:25:42 UTC 2021


On 05/07/2021 12:49, Petr Menšík wrote:
> Hi,
> 
> more below.
> 
> On 7/2/21 6:18 PM, Simon Kelley wrote:
>> On 02/07/2021 15:42, Petr Menšík wrote:
>>> Hi,
>>>
>>> current dnsmasq has a bug [1] in handling hostname setting. When two
>>> hosts request equal hostname, dnsmasq will reset name in previous lease
>>> and change registered name to the most recent requestor adddress.
>>>
>>> It does not work well with lease-script used by libvirt, because when
>>> lease name is reset, such change is not propagated to script. It changes
>>> only when dnsmasq is restarted. It does not load leases the same way,
>>> only one of leases would contain name.
>>>
>>> I have attached simple fix to propagate change to lease script. It would
>>> make lease handler report correct state and it works nice with libvirt.
>>>
>>> I am not sure current algorithm is the best one for leases reservation.
>>> Replacement of previous lease hostname works even without restart after
>>> attached change.
>>>
>>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1910621
>>>
>>>
>> Patch applied, that's clearly the correct thing to do, thanks.
> You're welcome.
>> As to why the handling of names is the way it is, it's been a very long
>> time since that was designed, but it was designed. It takes into account
>> that the most likely case is that a host gets unplugged from a network
>> and plugged into a new one. (or changes SSID), or changes from a wired
>> to a wireless network (and hence changes MAC address). The most sensible
>> thing to do in that case is to assume that the old lease is defunct (at
>> least as far as naming is concerned, the address reservation persists)
>> and give the name to the new one.
> 
> I have noticed it behaves different way with IPv6 leases with DUID
> present. I think it may protect clients who sent DUID even over IPv4. If
> lease_tmp were registered also with client id, we can expect the same
> host would send DUID also from another interface with another hw address.
> 
> It might then prevent clients with different DUID from stealing the
> name. It would not allow the same machine to keep the name with dualboot
> for example. Might be also issue on netboot, if DUID does not match. Who
> needs name registration on netboot? Does it ever send hostname during
> netboot? Would it make sense for IPv4 leases to implement the same
> algorithm as on IPv6 and set both IP addresses on the name, until
> previous lease expires?
> 
> It would work fine with any application supporting happy eyeballs
> algorithm and would indicate there is clash for the name. It would allow
> connecting to both wired and wireless interface at the same time. I
> think there is no way to set higher priority of wired interface lease in
> a DHCP request. It just fights for the name now. With short lease time
> it would make name address constantly changing.
> 
>> It's not secure, but assigning DNS names based information supplied by
>> DHCP is inherently insecure anyway. We do take care to honour explicit
>> assignment of names to MAC addresses or client-ids in the dnsmasq
>> configuration, so that random hosts can't hijack names in that case.
> 
> True. I just never considered DHCP registered names are still without
> any guarantee just like mDNS. Maybe even worse, because mdns has a
> protocol to avoid and solve conflicts. Even when there is a server,
> which can act as an arbiter, it is not protected. Not even by first
> come, first acquired solution. No one demands change anyway, this is
> just my thinking whether current implementation is the best one.
> 


Change, and risk breaking some installation somewhere that's been
working since 2005, or leave alone, and don't work as well for new
applications. The joys of a 20+ year-old codebase!


Simon.



More information about the Dnsmasq-discuss mailing list