5 ms·

Here's the full list of DNS attacks DNSSEC protects against: * Resolver cache poisoning * MitM upstream from resolver That's it. That is all that DNSSEC d

Here's the full list of DNS attacks DNSSEC protects against: * Resolver cache poisoning * MitM upstream from resolver That's it. That is all that DNSSEC does. Meanwhile, here's some attacks or concerns that are actually seen in the real-world and which DNSSEC does nothing for: * Passive data collection * Malicious DNS resolvers * Registrar account compromises * Local network MitM against endpoints And these are the real-world attacks which are enabled or made worse by DNSSEC: * DNS Amplification DDoS * DNS server denial of service (on-the-fly signing or validating signed responses adds non-trivial overhead) * Zone enumeration (NSEC and NSEC3 are hilarious) * DNS server compromise through RCE exploits (not exclusive to DNSSEC, but handling signed responses adds a lot of complexity to servers and almost all DNS RCE exploits we've seen recently have been in the DNSSEC handling part) Add to this the complexity of key handling and the risk of breaking your own zones and the calculation is pretty clear - on the whole, DNSSEC is actively making things worse and not providing a clear benefit for anyone.

teddyh 3y ago
> Meanwhile, here's some attacks or concerns that are actually seen in the real-world and which DNSSEC does nothing for: DNSSEC also does not press your suit or iron your shirt. How is this a criticism against DNSSEC? A security technology can not possibly solve all problems, and not solving some specific problems should never be a strike against it.
teddyh 3y ago
> made worse by DNSSEC: > * DNS Amplification DDoS Not really; with SPF, huge TXT records are all over the place, and can be used instead of having to use RRSIG records. > * DNS server denial of service (on-the-fly signing or validating signed responses adds non-trivial overhead) People said this about HTTPS, too. They were wrong. > * Zone enumeration (NSEC and NSEC3 are hilarious) Firstly, NSEC5. Secondly, no secret data should be in DNS. It’s not designed for it. > * DNS server compromise through RCE exploits (not exclusive to DNSSEC, but handling signed responses adds a lot of complexity to servers and almost all DNS RCE exploits we've seen recently have been in the DNSSEC handling part) Not on the authoritative server side, surely? Sounds like a DNS resolver problem.
- tptacek 3y ago
  NSEC5 is a research paper, not a deployed standard. But thanks for calling this out, because it gives us an opportunity to reflect on the fact that, confronted with the problem of enumerable sensitive DNS labels, the best cryptographic minds of the IETF DNS working group came up with a 1990s password file. One of the ways you can tell that DNSSEC advocates are operating in bad faith is by catching them attempting to argue that nothing in the DNS is secret to begin with. First, that's obvious gaslighting; disabling public zone transfers has been a security best practice since the mid-1990s, and no network security audit would fail to flag you for enabling them. Second, if the DNSSEC advocates actually believed that, they wouldn't have done NSEC3, whitelies, and (now, apparently, at some point in the distant future, NSEC5). Can't have it both ways on this.
  - teddyh 3y ago
    I am simply not going to respond to accusations that I am arguing in bad faith and gaslighting. Please do better.
    - tptacek 3y ago
      "DNS names aren't supposed to be secret" is not a good faith argument. It's not your argument: it is a popular trope of DNSSEC advocates. I don't mean to imply anything about you personally --- you're an anonymous abstraction to me, so there's nothing I could reasonably say about you as a person. But the argument you're making is what it is, and I've characterized it, I believe, accurately. Later I edited this slightly to make clear that I'm characterizing a trope, not an HN thread.
      - teddyh 3y ago
        > "DNS names aren't supposed to be secret" is not a good faith argument. Yes it is. Here I am, making it. It’s not even about DNSSEC; it has been the truth ever since the DNS itself was designed. Having secret data in DNS is doomed to fail in any number of ways, since DNS was never designed for it. And you can’t get away with claiming “Oh, I wasn’t calling you a bad faith gaslighter, only other people. Who are making the same argument as you. And I am saying this in a reply to your comment for no reason in particular.” Since you are, incredibly, doubling down on calling my argument a bad faith argument (instead of responding to it), I have no recourse but to leave it at that.
redprince 3y ago
> That's it. That is all that DNSSEC does. Thus providing an interesting foundation to build upon, for example DANE or SSHFP. Not very known or common things, but they show the potential of what is possible when there's a way to publish cryptographically authenticated records in DNS.
- peanut-walrus 3y ago
  In both cases what it boils down to is that "it's an alternative to the current CA system". Sure, alternatives are good, but why does it need to be coupled to DNS? If I have a .ly domain, do I really want to be forced to trust the Libyan government for my security?
  - deleted 3y ago
    [deleted]
  - teddyh 3y ago
    What do think a ccTLD is, if not a TLD controlled by a country, meaning the government of that country? In what world would it be reasonable for you to have a .ly domain and not trust the Libyan government not to do whatever they like to your domain? Like, you know, everybody already does with every .com and the U.S. government?
    - peanut-walrus 3y ago
      But that is exactly the point: in the world we are in right now, I DON'T have to trust the TLD operator to make sure my services are secure. Sure, there is a risk that the TLD operator will shut down my domain completely, but that is a different risk from the TLD operator MitM-ing my services. If my CA misbehaves? I can use a different CA. Not trivial, but doable. What if my TLD operator misbehaves or TLD changes ownership (like the .org case a few years ago) - change my domain?
      - teddyh 3y ago
        > What if my TLD operator misbehaves or TLD changes ownership (like the .org case a few years ago) - change my domain? That already happens all the time. And when it does happen, the new owner can get a legitimate certificate for it.
viraptor 3y ago
> MitM upstream from resolver And even this part is also mostly solved by DoH. (Unless someone can mitm you and spoof certificates, which means you're targeted by some organisations with serious resources...)
- dingaling 3y ago
  The problem with DoH is that it reinforces the certificate hegemony. Anyone can set up DNSSEC and run it without applying for authorisation from another party. But DoH requires a certificate signed by a CA trusted globally.
  - tptacek 3y ago
    And those certificates are so expensive!
jedisct1 3y ago
> * Resolver cache poisoning > * MitM upstream from resolver Only for clients that do DNSSEC validation. Ignoring the additional latency it comes with, virtually no home routers nor operating systems do.
- tptacek 3y ago
  This is a super important point! The parent post, which is quite good, forgets the qualifier that in practice DNSSEC is exclusively a server-to-server protocol: it's what your DNS server uses to attempt to authenticate records from other servers. But when you get the records, you don't get the signatures; you just get a single bit in the header that says "I pinky swear that I checked the signatures". It's wild that we're even considering rolling more of this out in 2023.
  - donttellmypeers 3y ago
    > But when you get the records, you don't get the signatures; you just get a single bit in the header that says "I pinky swear that I checked the signatures". Clients absolutely do get RRSIGs (and relevant NSEC/NSEC3) however they don't necessarily validate them.

teddyh 3y ago

> Meanwhile, here's some attacks or concerns that are actually seen in the real-world and which DNSSEC does nothing for: DNSSEC also does not press your suit or iron your shirt. How is this a criticism against DNSSEC? A security technology can not possibly solve all problems, and not solving some specific problems should never be a strike against it.

teddyh 3y ago

> made worse by DNSSEC: > * DNS Amplification DDoS Not really; with SPF, huge TXT records are all over the place, and can be used instead of having to use RRSIG records. > * DNS server denial of service (on-the-fly signing or validating signed responses adds non-trivial overhead) People said this about HTTPS, too. They were wrong. > * Zone enumeration (NSEC and NSEC3 are hilarious) Firstly, NSEC5. Secondly, no secret data should be in DNS. It’s not designed for it. > * DNS server compromise through RCE exploits (not exclusive to DNSSEC, but handling signed responses adds a lot of complexity to servers and almost all DNS RCE exploits we've seen recently have been in the DNSSEC handling part) Not on the authoritative server side, surely? Sounds like a DNS resolver problem.

tptacek 3y ago
NSEC5 is a research paper, not a deployed standard. But thanks for calling this out, because it gives us an opportunity to reflect on the fact that, confronted with the problem of enumerable sensitive DNS labels, the best cryptographic minds of the IETF DNS working group came up with a 1990s password file. One of the ways you can tell that DNSSEC advocates are operating in bad faith is by catching them attempting to argue that nothing in the DNS is secret to begin with. First, that's obvious gaslighting; disabling public zone transfers has been a security best practice since the mid-1990s, and no network security audit would fail to flag you for enabling them. Second, if the DNSSEC advocates actually believed that, they wouldn't have done NSEC3, whitelies, and (now, apparently, at some point in the distant future, NSEC5). Can't have it both ways on this.
- teddyh 3y ago
  I am simply not going to respond to accusations that I am arguing in bad faith and gaslighting. Please do better.
  - tptacek 3y ago
    "DNS names aren't supposed to be secret" is not a good faith argument. It's not your argument: it is a popular trope of DNSSEC advocates. I don't mean to imply anything about you personally --- you're an anonymous abstraction to me, so there's nothing I could reasonably say about you as a person. But the argument you're making is what it is, and I've characterized it, I believe, accurately. Later I edited this slightly to make clear that I'm characterizing a trope, not an HN thread.
    - teddyh 3y ago
      > "DNS names aren't supposed to be secret" is not a good faith argument. Yes it is. Here I am, making it. It’s not even about DNSSEC; it has been the truth ever since the DNS itself was designed. Having secret data in DNS is doomed to fail in any number of ways, since DNS was never designed for it. And you can’t get away with claiming “Oh, I wasn’t calling you a bad faith gaslighter, only other people. Who are making the same argument as you. And I am saying this in a reply to your comment for no reason in particular.” Since you are, incredibly, doubling down on calling my argument a bad faith argument (instead of responding to it), I have no recourse but to leave it at that.

redprince 3y ago

> That's it. That is all that DNSSEC does. Thus providing an interesting foundation to build upon, for example DANE or SSHFP. Not very known or common things, but they show the potential of what is possible when there's a way to publish cryptographically authenticated records in DNS.

peanut-walrus 3y ago
In both cases what it boils down to is that "it's an alternative to the current CA system". Sure, alternatives are good, but why does it need to be coupled to DNS? If I have a .ly domain, do I really want to be forced to trust the Libyan government for my security?
- deleted 3y ago
  [deleted]
- teddyh 3y ago
  What do think a ccTLD is, if not a TLD controlled by a country, meaning the government of that country? In what world would it be reasonable for you to have a .ly domain and not trust the Libyan government not to do whatever they like to your domain? Like, you know, everybody already does with every .com and the U.S. government?
  - peanut-walrus 3y ago
    But that is exactly the point: in the world we are in right now, I DON'T have to trust the TLD operator to make sure my services are secure. Sure, there is a risk that the TLD operator will shut down my domain completely, but that is a different risk from the TLD operator MitM-ing my services. If my CA misbehaves? I can use a different CA. Not trivial, but doable. What if my TLD operator misbehaves or TLD changes ownership (like the .org case a few years ago) - change my domain?
    - teddyh 3y ago
      > What if my TLD operator misbehaves or TLD changes ownership (like the .org case a few years ago) - change my domain? That already happens all the time. And when it does happen, the new owner can get a legitimate certificate for it.

viraptor 3y ago

> MitM upstream from resolver And even this part is also mostly solved by DoH. (Unless someone can mitm you and spoof certificates, which means you're targeted by some organisations with serious resources...)

dingaling 3y ago
The problem with DoH is that it reinforces the certificate hegemony. Anyone can set up DNSSEC and run it without applying for authorisation from another party. But DoH requires a certificate signed by a CA trusted globally.
- tptacek 3y ago
  And those certificates are so expensive!

jedisct1 3y ago

> * Resolver cache poisoning > * MitM upstream from resolver Only for clients that do DNSSEC validation. Ignoring the additional latency it comes with, virtually no home routers nor operating systems do.

tptacek 3y ago
This is a super important point! The parent post, which is quite good, forgets the qualifier that in practice DNSSEC is exclusively a server-to-server protocol: it's what your DNS server uses to attempt to authenticate records from other servers. But when you get the records, you don't get the signatures; you just get a single bit in the header that says "I pinky swear that I checked the signatures". It's wild that we're even considering rolling more of this out in 2023.
- donttellmypeers 3y ago
  > But when you get the records, you don't get the signatures; you just get a single bit in the header that says "I pinky swear that I checked the signatures". Clients absolutely do get RRSIGs (and relevant NSEC/NSEC3) however they don't necessarily validate them.