I did some packet captures with a test box to see how this works in our environment.
For the AD authentication source I use a domain name (e.g ads.domain.name) that points to about a dozen domain controllers.
I logged in to a cisco switch that is using RADIUS pointing to the clearpass server (PAP request). This was the first authentication for this test CP server in over 15 hours. The packet capture shows for this PAP request:
1) DNS lookup on ads.domain.name and it returns DC#1. Then it does a LDAPbind request using the account that is setup for the AD auth source followed by a LDAP serach request on the username for the request (I think to verify username exists). Both of these requests used DC#1.
2) DNS lookup on ads.domian.name and it retuns DC#2. It does a LDAP bind on username to authenticate user. Uses DC#2 for this auth.
3) DNS lookup on ads.domain.name and it returns DC#3. Does a LDAP search request on user and retrieves attributes for authorization (if you don't have fetching of attributes for authorization set, this step is probably not done). Uses DC#3 for this step.
Then the RADIUS accept is sent. So there are three separate LDAP steps and in my case it was using three separate domain controllers based on DNS lookups.
I then did a MSCHAP auth request a few seconds after the PAP request. The difference here was in step 2 instead of doing an LDAP bind to auth the user, it did a Samba/Winbind request against the server that is specified in the password server list I had set up in the AD domain config for the CP server (Note this password server list had no impact on which servers were used for LDAP queries). For this second request (different user) no DNS requests were made and the same DC servers were used for steps #1 and #3. IOW DC#1 was used for step #1 calls and DC#3 was used for step #3 calls. I'm sure at some point a DNS lookup will happen for each of these steps but don't know how that works.
Also if I authenticate using the same username in short order, step #3 (fetching attributes) does not happen on the subsequent auths. If I clear the cache in the auth source then it does for the first call, so the attributes for the user must get cached.
So it appears that using a domain name for the hostname in the auth source does spread the load to some degree. It certainly isn't load balancing but it is better then using a FQDN of a a single DC.