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
{{ message }}
This repository has been archived by the owner on Dec 31, 2020. It is now read-only.
Mandatory DNSSEC could be used to authenticate a Tent endpoint.
Especially when people start to self-host their Tent instances, it's important to know that the server you're talking to is actually the server of your contact.
Technical implications:
a) Pod-hosted: Everything related ot the zone signing could be handled by the 'Pod' server, which probably has a DNS server running anyway. The DNS server would publish DS records for all the users on the pod or sign the user-subzones itself.
b) Self-hosted: The self-hosted server needs a DNS record somewhere (for the A record that is also probably updated dynamically for changing IPs). With DNSSEC, the self-hosted server could host its own DNS (the published A record would instaed be a NS record pointing to another A record) and publish the signatures.
The text was updated successfully, but these errors were encountered:
Note: It would be almost impossible to introduce such a hard requirement later on, which would lead to legacy handling of not-yet-secured sites, adding complexity and weakening security. The choice for/against DNSSEC should come soon and decisively.
Personally, I would consider mandatory DNSSEC a /huge/ improvement.
The problem is that the vast majority of users (even the ones running their own servers) won't have access to name servers that support DNSSEC, let alone understand how to set it up.
You would hope that BIND 9 is starting to become widespread :/
The good thing is, this could all be handled completely transparent to the user; Tent servers can use their 'own' implementation of a DNS recursive resolver instead of falling back to the one provided by the OS (caching is lost, however) to provide DNSSEC-enabled lookup. The dnsruby gem, for example, works great in that regard, no matter which environment you are in. Example gist: https://gist.github.com/3504294, should output SECURE.
The DNS servers would be another thing. For hosted platforms, running their own DNS server and a cronjob to update the signatures should not be a problem. For self-hosted platforms, their DNS needs to be stored somewhere anyway. A solution to that problem would solve the DNSSEC problem as well.
Mandatory DNSSEC could be used to authenticate a Tent endpoint.
Especially when people start to self-host their Tent instances, it's important to know that the server you're talking to is actually the server of your contact.
Technical implications:
a) Pod-hosted: Everything related ot the zone signing could be handled by the 'Pod' server, which probably has a DNS server running anyway. The DNS server would publish DS records for all the users on the pod or sign the user-subzones itself.
b) Self-hosted: The self-hosted server needs a DNS record somewhere (for the A record that is also probably updated dynamically for changing IPs). With DNSSEC, the self-hosted server could host its own DNS (the published A record would instaed be a NS record pointing to another A record) and publish the signatures.
The text was updated successfully, but these errors were encountered: