Hi,
My responses to this group, have to be fitted into any spare time I have from the work I'm actually paid for and so it can be a while before I am able to respond.
In order to answer I have had to look at the code for the detail.
The dnsauth authentication plug-in was developed so the the authentication process can separated from the open source code and also to make use of the distributed database that is DNS to facilitate the look up of user and group information on an array of e2guardian servers. This separation is required as the authentication system may have to use closed-source code in order to access the information required.
Basically, dnsauth allows e2g to look up the user and group information based on the client IP.
This is achieved by creating a private domain which is only accessible by the authentication service and the the e2g system(s) involved. For example my.privatedomain.
After authenticating the user by some means the authentication service inserts a TXT record in DNS with the name, (for example for the client IP address 192.168.34.1,) of 192-168-34-1.my.privatedomain which contains 'user_name,group_number,timestamp' e.g '
phi...@e2guardian.org,4,12345678'. e2g then looks this record up in order to set the user_name and group. The 'timestamp' field is ignored by e2g. If the record does not exist and the dnsauth.conf setting 'redirect_to_auth' is 'yes' the user is redirected to the web authentication page defined in the 'authurl' setting, if 'no' then any other auth methods will be tried, if they all fail then the default group will be applied.
It is the responsibility of the authentication service to remove stale entries to ensure that the correct user and filter group is applied. Also the TTL of the DNS record should be kept short (say 15 secs) to avoid stale records being applied.
As the authentication service is supplied by the the e2g implementer this gives a great deal of flexibility on methods of authentication and on the logic of how the group is determined.
Regards
Philip