-
Notifications
You must be signed in to change notification settings - Fork 40
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
Leverage DNSSEC for resolver validation #1
Comments
Forgot a couple of points:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So I've had this floating around my mind for quite some time, but have never gotten around to thinking it through or doing a design suggestion. And probably won't for some time, so here's a bunch of notes to get started.
This starts with something you can't really get around, when you want to add a secure layer on anything:
Right now this is, in part, solved by having an authoritative list of DNSCrypt resolvers on GitHub, with changes happening through pull requests.
Users are also free to use servers outside this list by supplying the needed info to the DNSCrypt client manually. In this case it is entirely up to the user to figure out to make sure the info they got has not been altered during transport.
This issue is also widely solved by using PKI and CA's, which the authoritative is self bases it self upon (GitHub has been validated by a CA, etc, etc).
Perceived issues:
So what if we could get around all of this?
The rough idea:
What do you think?
The text was updated successfully, but these errors were encountered: