Is there a reason why Kea must have an IP address and not a FQDN to specify "next-server"?
A Support customer asks whether there is a reason why "next-server" values must be specified as IP addresses in Kea, as opposed to also allowing fully-qualified domain names, as was possible in ISC DHCP:
With ISC DHCP config, one could specify next-server as FQDN and dhcpd would resolve it on its start up and give clients as an IP.
With KEA, it is not possible as it demands to be an IP address and I was wondering about the reasons for this.
You see, our problem stemming from this is the fact TFTP server IP changes over time for various reasons - HW failures or tech-refresh, VM or containers moved from one hypervisor to another, etc.
With those changes we also have to somehow track this from KEA config stand point and make corresponding changes to subnet configs, which is tedious task as it would require a lot of changes as we have a lot of subnets in our KEA instances.
I know that ISC DHCP way was not perfect either as it required a dhcpd restart on IP changes, but at least it did not require a config change
I can foresee some problems with this, perhaps the most obvious being ambiguity if the FQDN does not resolve to a single address, but is there a literal requirement that constrains us here or is this just a design choice?
Alternatively (and probably preferably if we have a practical alternative to offer) what would we counsel the operator to do instead if we choose not to relax the current constraint?