Skip to content
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

DNSSec support #236

Closed
hannesm opened this issue Aug 7, 2020 · 2 comments
Closed

DNSSec support #236

hannesm opened this issue Aug 7, 2020 · 2 comments

Comments

@hannesm
Copy link
Member

hannesm commented Aug 7, 2020

there are two sides of the coin:

  • the resolver / client should request and verify signatures
  • the authoritative server should sign zones

The latter involves some key management, currently I'd keep the keys online (due to dynamic updates) instead of offline. The different key algorithms should nowadays be implemented in the MirageOS ecosystem. For some protocols, DNSSec is crucial (though the root of trust is in a single key).

For the former, this is crucial if every deploying an open recursive resolver (to not make the ecosystem of open recursive resolvers more brittle), and is connected to #167. My intuition is that a stub resolver with tls (and dns over https) is more suitable at the moment than a recursor.

@hannesm
Copy link
Member Author

hannesm commented Oct 5, 2021

some best practises in respect to nsec3 are discussed in https://kb.isc.org/docs/dnssec-signed-zones-best-practice-guidance-for-nsec3-iterations -- which sound very reasonable.

@hannesm
Copy link
Member Author

hannesm commented Jan 18, 2022

since #251 is merged now, closing this issue. there is likely some work to be done to use dnssec in the client, resolver, servers -- but this meta-issue does not really serve a purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant