4 ms·

I agree with everything Thomas has said here, but I also think that it might be a good idea to explain why proponents believe DNSSEC is a good idea for those wh

by dsacco 12y ago

I agree with everything Thomas has said here, but I also think that it might be a good idea to explain why proponents believe DNSSEC is a good idea for those who don't have a good handle on it. 1. DNS is vulnerable to man in the middle attack. Any authority with access to a root server or another router in the DNS resolution chain can tell a computer that a web page goes anywhere they want. This actually happens - for example, Turkey tried to go this with Twitter, and redirected Twitter's domain name to a government IP address instead for anyone within the country. 2. There is a dangerous vulnerability called DNS cache poisoning where UDP packets can be used to manipulate DNS servers to incorrectly respond when queried for a domain's IP address until their cache expires. This attack was described in 2008 by Dan Kaminsky, and on the whole, a methodology of preventing this sort of vulnerability would be good enough motivation for repairing the failings of present-day DNS. The motivation is great, but DNSSEC is largely the wrong tool for the job - it's a blunt instrument with no support for nuance and it will make DNS harder. What Thomas explains in greater technical detail is that DNSSEC is a move towards even further internet centralization that will make implementation more difficult without really solving the principal issues.

colmmacc 12y ago
It's worth keeping in mind that the Turkish government hi-jacked DNS resolvers; as-deployed DNSSEC would in no way have helped. The 2008 attack was not novel and was described by DJB about 7 years prior to Kaminsky, and DJB's utilities included a mitigation: randomized source ports. At present there is an equivalent vulnerability: UDP/IP fragments can be spoofed in such a way that poison records can be injected to resolvers. It is possible to mitigate this, but many DNSSEC proponents - including the Bind maintainers - refuse to consider mitigations because they feel that people should be moving to DNSSEC instead. It bears repeating that as-deployed; DNSSEC doesn't help protect against cache poisoning towards stubs - only towards caching resolvers.
- nmc 12y ago
  > It's worth keeping in mind that the Turkish government hi-jacked DNS resolvers; as-deployed DNSSEC would in no way have helped. Entirely false! ! ! Please get your facts right. [Not talking about the 2nd part of your comment] Yes, the Turkish government hijacked the Turkish DNS resolvers, so they were returning incorrect IPs for the twitter.com domain. Yes, DNSSEC would have helped. The Turkish government does not have any of: - The keys for the root zone - The keys for the .com TLD - The keys for the twitter.com domain As a result, the Turkish government had no way to forge signatures for the twitter.com domain. All they could do was send a fake AD bit. Using DNSSEC to validate answers for twitter.com from Turkey during the hijack would have failed. That is the exact purpose of DNSSEC.
  - colmmacc 12y ago
    My facts are right. As-deployed, clients don't validate DNSSEC; so the resolvers can pass on any response and the stubs/browsers will accept it. The signatures aren't being checked. Edit to update: The Turkish Government forged DNS to block twitter. Even if clients did start validating DNSSEC - if the failure mode is that it still be blocked, but for a different reason, is that really useful? A Government could simply drop all queries for twitter.com too. How does DNSSEC meaningfully help?
    - nmc 12y ago
      The signatures should be checked client-side. As I pointed out in another comment on this page (https://news.ycombinator.com/item?id=8896318 https://news.ycombinator.com/item?id=8896318), recent studies find that more and more resolvers send the RRSIGs to the clients, who then should check them. In the case of the Turkish hijacking, of course hijacked resolvers would not send RRSIGs. This should prompt the client to request another resolver.
    - xorcist 12y ago
      It depends on what you mean by clients. The most popular Firefox plugin to validate DNSSEC does in fact validate responses properly, and would have caught the Turkish MITM.
- tptacek 12y ago
  DNSSEC was also the reason why source ports weren't randomized, and thus the reason that Kaminsky's attack was briefly so viable. Somewhere there's a NANOG post with the BIND maintainers talking about the "scoreboarding resolver" they'd implemented but wouldn't release, because (even back in 1997) the real answer was DNSSEC. I'm not sure I agree about the novelty of Kaminsky's attack. Ruefully: I remember arguing with him about that on Twitter, him getting me on the phone to explain how his attack refined the older cache poisoning attacks, me conceding it, and then bad stuff happening a few months later.
  - yuhong 12y ago
    And DNSSEC probably did look good back in 1997, before the day of gTLDs and URL shorteners for example.
  - sarciszewski 12y ago
    > and then bad stuff happening a few months later. Are you referring to http://www.gonullyourself.org/ezines/ZF0/zf0%205.txt http://www.gonullyourself.org/ezines/ZF0/zf0%205.txt perchance?
    - tptacek 12y ago
      No.

by dsacco 12y ago

colmmacc 12y ago

It's worth keeping in mind that the Turkish government hi-jacked DNS resolvers; as-deployed DNSSEC would in no way have helped. The 2008 attack was not novel and was described by DJB about 7 years prior to Kaminsky, and DJB's utilities included a mitigation: randomized source ports. At present there is an equivalent vulnerability: UDP/IP fragments can be spoofed in such a way that poison records can be injected to resolvers. It is possible to mitigate this, but many DNSSEC proponents - including the Bind maintainers - refuse to consider mitigations because they feel that people should be moving to DNSSEC instead. It bears repeating that as-deployed; DNSSEC doesn't help protect against cache poisoning towards stubs - only towards caching resolvers.

nmc 12y ago
> It's worth keeping in mind that the Turkish government hi-jacked DNS resolvers; as-deployed DNSSEC would in no way have helped. Entirely false! ! ! Please get your facts right. [Not talking about the 2nd part of your comment] Yes, the Turkish government hijacked the Turkish DNS resolvers, so they were returning incorrect IPs for the twitter.com domain. Yes, DNSSEC would have helped. The Turkish government does not have any of: - The keys for the root zone - The keys for the .com TLD - The keys for the twitter.com domain As a result, the Turkish government had no way to forge signatures for the twitter.com domain. All they could do was send a fake AD bit. Using DNSSEC to validate answers for twitter.com from Turkey during the hijack would have failed. That is the exact purpose of DNSSEC.
- colmmacc 12y ago
  My facts are right. As-deployed, clients don't validate DNSSEC; so the resolvers can pass on any response and the stubs/browsers will accept it. The signatures aren't being checked. Edit to update: The Turkish Government forged DNS to block twitter. Even if clients did start validating DNSSEC - if the failure mode is that it still be blocked, but for a different reason, is that really useful? A Government could simply drop all queries for twitter.com too. How does DNSSEC meaningfully help?
  - nmc 12y ago
    The signatures should be checked client-side. As I pointed out in another comment on this page (https://news.ycombinator.com/item?id=8896318 https://news.ycombinator.com/item?id=8896318), recent studies find that more and more resolvers send the RRSIGs to the clients, who then should check them. In the case of the Turkish hijacking, of course hijacked resolvers would not send RRSIGs. This should prompt the client to request another resolver.
  - xorcist 12y ago
    It depends on what you mean by clients. The most popular Firefox plugin to validate DNSSEC does in fact validate responses properly, and would have caught the Turkish MITM.
tptacek 12y ago
DNSSEC was also the reason why source ports weren't randomized, and thus the reason that Kaminsky's attack was briefly so viable. Somewhere there's a NANOG post with the BIND maintainers talking about the "scoreboarding resolver" they'd implemented but wouldn't release, because (even back in 1997) the real answer was DNSSEC. I'm not sure I agree about the novelty of Kaminsky's attack. Ruefully: I remember arguing with him about that on Twitter, him getting me on the phone to explain how his attack refined the older cache poisoning attacks, me conceding it, and then bad stuff happening a few months later.
- yuhong 12y ago
  And DNSSEC probably did look good back in 1997, before the day of gTLDs and URL shorteners for example.
- sarciszewski 12y ago
  > and then bad stuff happening a few months later. Are you referring to http://www.gonullyourself.org/ezines/ZF0/zf0%205.txt http://www.gonullyourself.org/ezines/ZF0/zf0%205.txt perchance?
  - tptacek 12y ago
    No.