-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An API to tell if a query was DNSSEC verified or not #154
Comments
Thanks for taking the time to suggest this enhancement @singpolyma! I can see how a more granular failure result can be helpful in some cases, but can you please elaborate on what you're trying to achieve? From a DNSSEC standpoint, there could be four possible outcomes. "there was DNSSEC and it passed" and "there was no DNSSEC" correspond to This sounds like a good idea in principle, but as a high-level where the primary functionality is DoH and DNSSEC is secondary, I need to be careful we're not making things too complicated, which is why learning about your specific use case can be helpful. |
I can see how a more granular failure result can be helpful in some cases,
but can you please elaborate on what you're trying to achieve?
Sure. There are cases where DNSSEC being present and valid is necessary
(such as TLSA records) and also cases where DNSSEC being present is
sufficient (such as to know the IP you got really do belong to the target
server) but where a valid DNSSEC-less result can be used in conjunction with
a fallback verification mechanism (such as CA certified TLS certificate).
|
Thanks. Apologies for the delay. Those are two very different use cases. The first use case seems straightforward. We could introduce a new exception (e.g., doh-jvm/src/main/kotlin/tech/relaycorp/doh/DoHClient.kt Lines 84 to 87 in ee1b053
We'd welcome a PR for that. If you'd like to proceed with it, please make sure to follow the current coding conventions and add a unit test for every new code execution branch (I think this will just introduce an The second use case deserves further consideration and, if I'm reading it correctly, we'd be talking about a different feature request: offer the option to disable DNSSEC verification (as a new optional parameter in If DNSSEC verification fails, you wouldn't get an answer (e.g., Also, if we're introducing a flag to disable DNSSEC verification, we should consider the other DNSSEC-related flag that someone might want to include in the query: whether to include the |
I have no interest in disabling verification. If DNSSEC verification fails then that should be either an error or no result, of course. I'm only interested in knowing if DNSSEC existed and was verified or else was not present. I don't want not present to be an error, just to know when it happened. |
So I think maybe your other feature you mentioned (returning RRSIG records if present) would be the thing to do here? If there are no RRSIG then we know there was no DNSSEC. |
Describe the problem
I would like to know if a DNS result was DNSSEC verified.
Describe the solution you'd like
I'd like a property on the Answer or similar that tells me if it was DNSSEC verified.
Describe alternatives you've considered
I know if the DNSSEC fails then a verifying resolver will just return an error, but I'm interested in telling the difference between "there was DNSSEC and it passed" and "there was no DNSSEC"
The text was updated successfully, but these errors were encountered: