Request: Elevate access level of isAuthenticated to public #390

Activity

1. ibauersachs commented on Jul 17, 2025

   

   ibauersachs

   on Jul 17, 2025

   Member

   More actions

   Is there a reason for the access level to be package? The information is publicly available through toString() already.

   Yes, the flag is not properly tested. I added it while implenting the CVE fixes from 3.6.0 because I thought I needed it, turns out it wasn't. I left it to work on it again, but this hasn't happened so far. I don't want to expose it in the API before I'm confident enough it can stay in this form for a long time.
2. craigraw commented on Jul 28, 2025

   

   craigraw

   on Jul 28, 2025

   Last edited by craigraw

   More actions

   +1

   I would also like to access this field. The documentation recommends against using ValidatingResolver standalone, but it's unclear how to reliably determine if the LookupResult from LookupSession is authenticated. In fact, it doesn't appear the field is set correctly, and there's no way that I can see to determine if the answer is authenticated when using LookupSession.
3. ibauersachs commented on Aug 2, 2025

   

   ibauersachs

   on Aug 2, 2025

   Member

   More actions

   I would also like to access this field. The documentation recommends against using ValidatingResolver standalone, but it's unclear how to reliably determine if the LookupResult from LookupSession is authenticated.

   There wouldn't be a reply if the ValidatingResolver determines that the result is invalid, similar to how you wouldn't get a response from getaddrinfo. At best there's a SERVFAIL response.

   In fact, it doesn't appear the field is set correctly, and there's no way that I can see to determine if the answer is authenticated when using LookupSession.

   That's exactly why the field isn't public.
4. ibauersachs

   added

   enhancement

   on Aug 2, 2025
5. craigraw commented on Aug 4, 2025

   

   craigraw

   on Aug 4, 2025

   More actions

   There wouldn't be a reply if the ValidatingResolver determines that the result is invalid, similar to how you wouldn't get a response from getaddrinfo. At best there's a SERVFAIL response.

   This is not my experience. I created a TXT record on a domain without any DNSSEC records. A lookup with a LookupSession configured with a ValidatingResolver returned successfully, and there was no way to access the AD flag to find out that no validation had occurred.

   For anyone else who runs into this, I solved it by wrapping ValidatingResolver in another resolver which checks the flag after execution of sendAsync.