You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
there are two sides of the coin:
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.
The text was updated successfully, but these errors were encountered: