Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
None
Description
Configuring a server, client or Listen* with a DNS name seem to result in either the A or the AAAA record being used.
For servers, this might be problematic if either of the families (typically IPv6) doesn't work reliably between radsecproxy and the server and that family happens to get picked (i.e. when a server has both A and AAAA records).
For clients, only clients connecting over the network family which happened to be picked will match. I guess -- this hasn't been verified.
For Listen*, we might bind to only one of the families when the operator think s/he's using the other, or both.
This has been discussed in the thread "radsecproxy behavior with IPv6 (hosts with AAAA and A)" https://postlister.uninett.no/sympa/arc/radsecproxy/2012-04/msg00000.html
For servers, this might be problematic if either of the families (typically IPv6) doesn't work reliably between radsecproxy and the server and that family happens to get picked (i.e. when a server has both A and AAAA records).
For clients, only clients connecting over the network family which happened to be picked will match. I guess -- this hasn't been verified.
For Listen*, we might bind to only one of the families when the operator think s/he's using the other, or both.
This has been discussed in the thread "radsecproxy behavior with IPv6 (hosts with AAAA and A)" https://postlister.uninett.no/sympa/arc/radsecproxy/2012-04/msg00000.html