On Sun, 2020-01-26 at 20:01 +0100, Oliver Freyermuth wrote: > I also like this new approach. "Wasting" 4 addresses for one host > seems to be the only way > to solve this while conforming to RFCs. > > However, there's one issue I can't find a good solution for in this > scheme - > how to solve the "DNS problem" if dnsmasq is only used for DHCP, but > DNS is provided by other means? > > The "range reservation", as highlighted, means the final address is > not well predictable (may depend on hardware, > other parts of the boot process etc.). > When dnsmasq is also doing the DNS part, that's not a problem, since > it will use the final / "most recently leased" address for DNS. > Does anybody have a good proposal for the case when DHCP is provided > by dnsmasq but DNS is maintained separately > (i.e. the "final address" needs to be fixed)? > > Cheers, > Oliver
I think adding tag support for dhcp-host entries as follow up. The idea would be to have a config like this: # OPTION_CLIENT_ARCH_TYPE (61) dhcp-match=set:efi6,option6:61,0007 dhcp-match=set:efi6,option6:61,0009 dhcp-match=set:efi6,option6:61,0011 # User class is iPXE dhcp-userclass=set:ipxe6,iPXE dhcp-host=tag:efi6,tag:ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb00/126],host2 dhcp-host=tag:!efi6,tag:!ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb05],host2 The "temporary addresses" in [fd12:3456:789a:1::bb00/126] are only used when architecture type is one of the UEFI types or the userclass option have "iPXE". The dhcp client in the final OS should always end up with fd12:3456:789a:1::bb05. Another possible solution would be to use a dhcp-script which run's nsupdate to dynamically update the dns server. -- Harald _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss