Does that mitigate this scenario? In many cases, clients may be talking directly to 1.1.1.1, not servers. At least that is a pattern I have seen people using. Only servers validate DNSSEC. So people using Unbound DNS at home or in their corporate network may be protected from this, but I am not aware of any local OS resolvers that validate DNSSEC. You are right though, people should certainly be using DNSSEC on all their zones.
Absolutely. I do this as well on a couple laptops so I get the same anti-adware my home network has. I've even managed to get a couple other people to try it out.
That solves that one DNSSEC problem for you, but no mainstream operating system deploys a local DNSSEC-validating recursive cache, and something like half of all Internet usage comes from mobile/tablet devices where you can't do that at all. Realistically, to a first approximation, nobody is going to do this.
Probably because DNSSEC is moribund, virtually none of the most popular zones on the Internet are signed despite a decade of deployment effort, the protocol itself doesn't protect end-system lookups (it's a server-to-server protocol), and DNS-over-HTTPS has for the most part eliminated any impetus to deploy it further.
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.
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.
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.
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.
1. Attacks on forwarders are neutralized by things like DoH, and it's not clear how generalizable their results are (it's not clear whether they need insider collaboration to pull off the attacks).
2. It appears to be possible to defeat attacks on the major public DNS caches with just slight tweaks to ICMP unreachable messages. Like, couldn't you just drop a random ICMP packet or two within the rate window and completely jank this attack up?
For #2; I would think you could reasonably disable sending ICMP port unreachable (possibly for UDP only) for these machines. Or at least for the IPs they use for sending queries.
It's not strictly required, and leaks information. I don't know what an dns server would do with an icmp unreachable to its reply anyway.
Random drop would work too of course. I think there's a general concern about these rate limits leaking information, but it's hard to address because of many concerns. Alternatively a big push to use lots of IPv6 addresses would increase the search space and make it harder to spoof (contingent on IPv6 support in authoritative and recursive severs and their networks)
I had the same first impression, and it's not like ICMP unreachables weren't already a security issue (they're how you do UDP port scans in the first place). I assume there's a reason they're kept enabled. But you could keep them enabled and approximately 100% functional while breaking this attack just by dropping a couple now and then.
If your goal is to maximize the amount of information DNS reveals about your Internet usage, to the maximum number of DNS authority servers, running your own local Unbound instance is definitely a good way to accomplish that.
I just have it set up to forward most zones to my ISP DNS, but you could just as easily do that with 8.8.8.8 or whatever and still minimize the number of requests you make to them. you’ll notice the lower latency too.
21 comments
[ 2.9 ms ] story [ 63.4 ms ] threadIf you worry about DNS cache poisoning, sign your domains and validate the responses you get.
I run it on an old laptop running FreeBSD and have my other machines use it as their DNS server.
See https://sockpuppet.org/blog/2015/01/15/against-dnssec/ for more.
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
[2]: https://stats.dnssec-tools.org
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.
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.
1. Attacks on forwarders are neutralized by things like DoH, and it's not clear how generalizable their results are (it's not clear whether they need insider collaboration to pull off the attacks).
2. It appears to be possible to defeat attacks on the major public DNS caches with just slight tweaks to ICMP unreachable messages. Like, couldn't you just drop a random ICMP packet or two within the rate window and completely jank this attack up?
It's not strictly required, and leaks information. I don't know what an dns server would do with an icmp unreachable to its reply anyway.
Random drop would work too of course. I think there's a general concern about these rate limits leaking information, but it's hard to address because of many concerns. Alternatively a big push to use lots of IPv6 addresses would increase the search space and make it harder to spoof (contingent on IPv6 support in authoritative and recursive severs and their networks)