Alan Dekok wrote:
Too bad. If the address doesn't resolve, then you shouldn't be listing the clients in DNS.
RADIUS depends on IP addresses.
Going way out on the limb of conjecture here, when I get back to working on DDDS, the part I haven't even begun to tackle yet is that the server is expected to dynamically determine IPs from DNS. This will require a rather extensive rewire of the internals, which gets a bit messy when you have ongoing EAP conversations during a DNS change that alters either the availability or weightings of servers in a server pool, since some sort of server affinity mechanism needs to override the DNS for existing conversations for a grace period. However, once that's done, what I wrote on the DNS side as far as the config options/functionality is not all-or-nothing DDDS, it also degrades nicely to non-DDDS uses, down to a the case of a single hostname that may change. For home servers, the conjectural behavior when DNS fails for all servers in the pool would be an empty pool would be brought up, so the server would still start, but would behave as if it had no non-dead servers in that pool. Then things would start working when DNS started working again. Also as far as AAAA/A records it would try both unless told otherwise, so worst case there is we end up load balancing needlessly between the A and AAAA sockets on the same server, or having a useless marked-dead home server hanging around for one of the address records if ipv4 or ipv6 were broken. For clients I haven't thought much into that, because validation of incoming requests in the use case for DDDS relies on PKI/realms.