-
-
Notifications
You must be signed in to change notification settings - Fork 5
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
Check DNSsec results #3
Comments
In #37 (comment) @gnarea suggested a design, which I mostly like. I don't really believe in remote validation for dnssec, so I'd like the default to be local validation, unless there's some reason not to. |
If we integrate dnssec-js, I'd suggest to default to remote validation for a while just to allow enough time for the library to be (a) battle-tested in the wild (we'll be using it in Vera, which should be released to production in Q1/Q2 2023) and (b) independently audited by a reputable team (which our funder will be commissioning soon). Until then, as a user of this library, I'd feel safer sticking to Cloudflare or Google. Another thing to bear in mind is that client-side validation could be much slower than remote validation depending on the user's connection. So if client-side validation becomes the default, I'd consider making a major release to make it more likely for developers to check the release notes. |
Your stated approach works for me. We will mark the option's default as likely to change so that people know to be explicit if they want consistent behavior. |
👍🏾 BTW, in addition to the docs, there's one more thing I want to do before integrating dnssec-js in the dohdec CLI. |
Process RRSIG results, etc.
The text was updated successfully, but these errors were encountered: