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: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
