4 ms·

DNSSEC is mentioned in the FAQ [1]. Short answer: if DNSSEC is implemented strictly, it seemingly gets you most of the way there. Not clear if a configuration c

DNSSEC is mentioned in the FAQ [1]. Short answer: if DNSSEC is implemented strictly, it seemingly gets you most of the way there. Not clear if a configuration change or update to the protocol could completely mitigate the attack. BTW, there are nearly 13 million DNSSEC signed zones; the trend is certainly up [2]. Does DNSSEC mitigate the attack? Yes and no, the server must implement strict DNSSEC check (i.e., refuse the responses that break the trust chain) to prevent the off-path attacks. However, since DNSSEC is still under development and servers need to accept such responses (i.e., only DNSSEC aware but not DNSSEC validate) when visiting a misconfigured domain. [1]: https://www.cs.ucr.edu/~zhiyunq/SADDNS.html https://www.cs.ucr.edu/~zhiyunq/SADDNS.html [2]: https://stats.dnssec-tools.org https://stats.dnssec-tools.org

tptacek 6y ago
The trend is in fact not up in North America; the last time I checked, it was slightly down. The paper we're commenting on also has some grim stats in it. Nobody is debating whether DNSSEC addresses this attack --- it does, for server-to-server connections. But DNSSEC is an extremely expensive way to stop this attack, and because there are cheaper ways that don't require collaboration between unrelated parties on the Internet, those are the mitigations --- ICMP policy changes, 0x20 encoding, DNS cookies, etc --- that will happen.
- arminiusreturns 6y ago
  I haven't been keeping up, do you know if DNSCURVE also prevents this attack? I remember digging into it a bit a while back (~2015) and coming away thinking I liked DNSCURVE a lot better, but that in the end I expected both to be used in conjuction in the future.
  - tptacek 6y ago
    DNSCURVE is a dead letter, due to DoT and DoH, but all 3 address this attack the same way: a transaction between two speakers of these protocols can't be cache-poisoned directly (but a transaction between your DoH-speaking cache and a non-DoH speaker can in theory be cache-poisoned, and the point of poisoning the cache is that your subsequent lookups will get the faulty data). DNSCURVE was explicit about the idea of doing bottom-up protection of the whole DNS, so that servers would use it with other servers. You can, of course, do that with DoH as well, but it's not an "indicated use" yet. So the short answer is: DoH & friends break this attack completely against home router forwarders (the first target in the paper), but not for major public resolvers like 8.8.8.8; they'll need to take some steps to break it themselves.

tptacek 6y ago

The trend is in fact not up in North America; the last time I checked, it was slightly down. The paper we're commenting on also has some grim stats in it. Nobody is debating whether DNSSEC addresses this attack --- it does, for server-to-server connections. But DNSSEC is an extremely expensive way to stop this attack, and because there are cheaper ways that don't require collaboration between unrelated parties on the Internet, those are the mitigations --- ICMP policy changes, 0x20 encoding, DNS cookies, etc --- that will happen.

arminiusreturns 6y ago
I haven't been keeping up, do you know if DNSCURVE also prevents this attack? I remember digging into it a bit a while back (~2015) and coming away thinking I liked DNSCURVE a lot better, but that in the end I expected both to be used in conjuction in the future.
- tptacek 6y ago
  DNSCURVE is a dead letter, due to DoT and DoH, but all 3 address this attack the same way: a transaction between two speakers of these protocols can't be cache-poisoned directly (but a transaction between your DoH-speaking cache and a non-DoH speaker can in theory be cache-poisoned, and the point of poisoning the cache is that your subsequent lookups will get the faulty data). DNSCURVE was explicit about the idea of doing bottom-up protection of the whole DNS, so that servers would use it with other servers. You can, of course, do that with DoH as well, but it's not an "indicated use" yet. So the short answer is: DoH & friends break this attack completely against home router forwarders (the first target in the paper), but not for major public resolvers like 8.8.8.8; they'll need to take some steps to break it themselves.