5 ms·

Can you please explain why DNSSEC was a bad idea in the first place? It worked perfectly fine with the old registrar.

theamk 4y ago
Basically, it is lots of extra work effort for no real security advantages. Other people wrote a lot about it, here is an example: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/
- teddyh 4y ago
  Rebuttal: https://easydns.com/blog/2015/08/06/for-dnssec/ https://easydns.com/blog/2015/08/06/for-dnssec/
Spooky23 4y ago
DNSSEC doesn’t really solve any problems that you have nor does it meaningfully prevent any security risks. It does create a lot of operational risk, as you’ve discovered. It also checks a box if you’re building a system for the US Federal .gov. tptacek has written about this at length on this site and other places.
belorn 4y ago
It like https. A lot of people in the past viewed HTTPS as a terrible idea that just broke things, and every example where someone had their website go down because of broken certificates or mixed content was proof that https as a concept was broken. Usually people brought up x.509 or revocation lists as the definitive proof that https would never be common.
- the8472 4y ago
  From a site reliability perspective HTTPS is still broken. Some 15yo OS can't access any site because it doesn't have the certificates or cipher suites. And as you mentioned we need to update certs, webservers and DNS all the time to keep up to date. We only put up with it because it protects users from from snoopers. But that means we live in an inadequate equilibrium. If we abolished mass surveillance rather than impeding it with technical measures then we wouldn't need encryption for read-only sites, we could have our cake and eat it too.
  - shkkmo 4y ago
    > If we abolished mass surveillance then we wouldn't need encryption for read-only sites, we could have our cake and eat it too. Mass surveillance is not the only reason to have HTTPS everywhere. It protects not just from snoopers, but from MITM attacks.
    - the8472 4y ago
      Did you notice the "read only sites" part? MITM is hardly relevant for those.
      - sunaurus 4y ago
        You should still protect against MITM attacks even with read-only websites - not all attacks are based on stealing user input.
        the8472 4y ago
        What's the threat model here?
        sunaurus 4y ago
        Random examples of MITM attacks I could do on a read-only website: * Inserting malicious JavaScript * Changing content on trusted websites in order to mislead people * Replacing downloadable application binaries with versions that contain malicious code
        the8472 4y ago
        Malicious JS can be served directly, e.g. via ad iframes. Injecting it into a low-stakes (read-only) site doesn't gain much, does it? Points 2 and 3 are the same, they're about integrity which could be had cheaper with content-addressing (hashes uniquely identifying the content) rather than pulling in the full TLS+CA machinery.
        4y ago
- theamk 4y ago
  Eh, except that HTTPS actually has tangible benefits, unlike DNSSEC.
  - belorn 4y ago
    Much of the Internet right now uses DNS as proof of authentication. Having authentication system be a plain text protocol without any integrity or validation is a recipe for abuse. Right now the work-around is to have multiple resolver spread out all over the world and query the name servers multiple times to detect malicious actors, which is a much worse solution that dnssec if you ask me. It doesn't scale well and is a hack on top of an insecure protocol in order to create a sense of security. We could return back to IPsec, or tunnel everything under https as a more modern version of IPsec, but those solutions are all disliked depending on who you ask.
  - kevincox 4y ago
    Without DNSSEC anyone can intercept your email. The TLS cert verified by mail is the domain pointed to by the MX record. Plus with DKIM keys store in DNS people can spoof email (if they can fool the receiver to trust their records). If you can fool DNS resolution for LetsEncrypt (pretty hard since IIRC they fetch DNS from multiple perspectives on the internet to mitigate this) you can get certificates for any hostname. There are other solutions such as MTA-STS and DNS-over-HTTP but the end-to-end validation of DNSSEC is pretty powerful.

Basically, it is lots of extra work effort for no real security advantages. Other people wrote a lot about it, here is an example: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/

teddyh 4y ago
Rebuttal: https://easydns.com/blog/2015/08/06/for-dnssec/ https://easydns.com/blog/2015/08/06/for-dnssec/

Spooky23 4y ago

DNSSEC doesn’t really solve any problems that you have nor does it meaningfully prevent any security risks. It does create a lot of operational risk, as you’ve discovered. It also checks a box if you’re building a system for the US Federal .gov. tptacek has written about this at length on this site and other places.

belorn 4y ago

It like https. A lot of people in the past viewed HTTPS as a terrible idea that just broke things, and every example where someone had their website go down because of broken certificates or mixed content was proof that https as a concept was broken. Usually people brought up x.509 or revocation lists as the definitive proof that https would never be common.

the8472 4y ago
From a site reliability perspective HTTPS is still broken. Some 15yo OS can't access any site because it doesn't have the certificates or cipher suites. And as you mentioned we need to update certs, webservers and DNS all the time to keep up to date. We only put up with it because it protects users from from snoopers. But that means we live in an inadequate equilibrium. If we abolished mass surveillance rather than impeding it with technical measures then we wouldn't need encryption for read-only sites, we could have our cake and eat it too.
- shkkmo 4y ago
  > If we abolished mass surveillance then we wouldn't need encryption for read-only sites, we could have our cake and eat it too. Mass surveillance is not the only reason to have HTTPS everywhere. It protects not just from snoopers, but from MITM attacks.
  - the8472 4y ago
    Did you notice the "read only sites" part? MITM is hardly relevant for those.
    - sunaurus 4y ago
      You should still protect against MITM attacks even with read-only websites - not all attacks are based on stealing user input.
      - the8472 4y ago
        What's the threat model here?
        sunaurus 4y ago
        Random examples of MITM attacks I could do on a read-only website: * Inserting malicious JavaScript * Changing content on trusted websites in order to mislead people * Replacing downloadable application binaries with versions that contain malicious code
        the8472 4y ago
        Malicious JS can be served directly, e.g. via ad iframes. Injecting it into a low-stakes (read-only) site doesn't gain much, does it? Points 2 and 3 are the same, they're about integrity which could be had cheaper with content-addressing (hashes uniquely identifying the content) rather than pulling in the full TLS+CA machinery.
        4y ago
theamk 4y ago
Eh, except that HTTPS actually has tangible benefits, unlike DNSSEC.
- belorn 4y ago
  Much of the Internet right now uses DNS as proof of authentication. Having authentication system be a plain text protocol without any integrity or validation is a recipe for abuse. Right now the work-around is to have multiple resolver spread out all over the world and query the name servers multiple times to detect malicious actors, which is a much worse solution that dnssec if you ask me. It doesn't scale well and is a hack on top of an insecure protocol in order to create a sense of security. We could return back to IPsec, or tunnel everything under https as a more modern version of IPsec, but those solutions are all disliked depending on who you ask.
- kevincox 4y ago
  Without DNSSEC anyone can intercept your email. The TLS cert verified by mail is the domain pointed to by the MX record. Plus with DKIM keys store in DNS people can spoof email (if they can fool the receiver to trust their records). If you can fool DNS resolution for LetsEncrypt (pretty hard since IIRC they fetch DNS from multiple perspectives on the internet to mitigate this) you can get certificates for any hostname. There are other solutions such as MTA-STS and DNS-over-HTTP but the end-to-end validation of DNSSEC is pretty powerful.