ipaddr, ipv4addr ipv6addr

[Brian Julin]

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.