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

Petr Menšík pemensik at redhat.com
Mon Jul 5 11:49:30 UTC 2021


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.

> Cheers,
>
> Simon

Cheers,

Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210705/7babdf83/attachment-0001.sig>


More information about the Dnsmasq-discuss mailing list