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. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
