5 ms·
Naive question: Is there any reason, given that my registrar allows me to turn on DNSSEC, that I shouldn't? Any negative consequences or things I need to accoun
by notafraudster 8y ago
Naive question: Is there any reason, given that my registrar allows me to turn on DNSSEC, that I shouldn't? Any negative consequences or things I need to account for? Or is this a no duh move?
- tptacek 8y agoYes: if you DNSSEC-sign your domain but don't keep up maintenance of it, your domain will vanish off the Internet for users behind strict-validating DNS caches. That happened to HBO NOW for all Comcast users the week they rolled out. (You'd also be participating in a government-run PKI but I'm not assuming your politics preclude you from doing so).
- regecks 8y ago> but don't keep up maintenance of it Not sure about this phrasing. It's not on the domain owner to maintain anything, you just need to not forget you have DNSSEC enabled if you move your zone to different NS. It's up to your DNS host to handle things like key rollovers and most people aren't writing and running their own authoritative DNS servers. Regardless, the risk vs reward is still heavily in favor of not signing. It is so sparsely deployed that it can't be relied upon for anything (like DANE) and it seems like DoH (both for clients and between resolvers) may end up being the better way forward.
- tptacek 8y agoIn addition to DoH, there's already a direct-to-domain-registrar protocol in the works for the CA problem. DNSSEC is, I think, pretty much dead.
- peterwwillis 8y agoAm I incorrect that the same thing happens when you let your domain registration or TLS certificate expire? Perhaps with a slightly worse outcome, but still. If the current iteration of DNSSEC is intolerable, why not propose a new version with less warts? A sort of DNSSEC-lite? Almost everyone will adopt it as long as it's not as difficult to use as the original, but USG can continue rolling out the original in the public sector the same as they do now.
- tptacek 8y agoNo: when your TLS certificate expires, you don't vanish off the Internet. Your browser tells you specifically what went wrong. When DNSSEC fails, you (in the general case) vanish without a trace. Why bother with a new version of DNSSEC? We've worked around basically all the problems of insecure DNS at this point.
- peterwwillis 8y agoMaking DNSSEC more attractive will help all the people that the workarounds won't. Two reasons for a better DNSSEC: 1) People will continue to [erroneously] assume their DNS transactions are secure. They won't be, and then they'll get screwed. For users, this means being smart enough to know if their application is resistant to DNS attack, and if not, smart enough to implement a workaround. For organizations, this means waiting until they are attacked, then adding the workarounds. Organizations and users who make this assumption - which will be most of them - will continue to be more vulnerable than is necessary. 2) There are many applications and protocols on the internet other than HTTP[S], and assuming the above point, these apps/protocols would eventually need to implement the workarounds that web clients/servers have. Many of these are legacy, and many of them are also critical, including uses by the financial industry, medical industry, public utilities, government/military, web businesses, etc. The public sector is already implementing DNSSEC because they see that not doing so is unnecessarily risky (and they don't have to pay for it). But for all the private orgs that either don't see the need or don't want to bear the cost, a less odorous solution that doesn't require "workarounds" would net them significant benefits, even if it's at the fringes of today's real world security problems. Basically, we will all at some point be involved (at the least, indirectly) in something that isn't an HTTPS transaction, and so we will all at some point have a need to trust DNS to some extent. The workarounds aren't going to work by default for everyone everywhere, and so there will be people left in the lurch.