GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Request: Elevate access level of isAuthenticated to public · Issue #390 · dnsjava/dnsjava

Request: Elevate access level of isAuthenticated to public #390

New issue
Copy link
New issue
Copy link
Open
Open
Request: Elevate access level of isAuthenticated to public#390
Copy link
Labels
enhancement

Description

@torbenfreise
torbenfreise
opened on Jul 17, 2025
Issue body actions

dnsjava/src/main/java/org/xbill/DNS/lookup/LookupResult.java

Lines 53 to 54 in 4b84d92

@Getter(AccessLevel.PACKAGE)
private final boolean isAuthenticated;

I would like to be able to access this to test that the resolver is setting the Authentication bit / the result is authenticated.

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

Thank you!

Activity

  1. ibauersachs commented on Jul 17, 2025

    @ibauersachs
    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
    craigraw
    on Jul 28, 2025
    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
    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
    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancement

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.