DNS/毒盛/2020/saddns.net/8.1

• cookie の評価はおかしい。

8.1 Defenses

The proposed attack is fundamentally an off-path attack and therefore can be mitigated by additional randomness and cryptographic solutions.

cookie

Besides DNSSEC and 0x20 encoding, there is also an emerging feature called DNS cookie that is standardized in RFC 7873 [1] in 2016.

At a high level, it requires both client and server to exchange some additional secrets unknown to an off-path attacker; it therefore has the potential to defeat most (if not all) off-path DNS attacks.

Note that this feature requires both resolvers and authoritative name servers to upgrade in order to see benefits. As of now, only BIND has implemented this feature and have it turned on by default in 9.11.0 forward [28] (released in 2016).

We find about 5% of the open resolvers that we measured have enabled this feature by default. However, as any other unproven technology (the lesson regarding 0x20 [16]), it remains to be seen if issues such as compat- ibility will prevent it from being widely adopted.

Interestingly, we already found both DNSPod (operated by Tencent) and a resolver in a private company drop queries with DNS cookie options, likely for compatibility concerns.

source port

In addition, our attack relies on the two fundamental components:

• (1) inferring source port of a DNS query; (2) extending attack window.

Each of them can be a security threat on its own and therefore we discuss how to address both.

For (1), the simplest mitigation is to disallow outgoing ICMP replies altogether (as is done by many servers), at the potential cost of losing some network troubleshooting and diagnostic features.

Otherwise, we need to address the global rate limit.

As with patches on TCP global counters [51], we suggest a randomized ICMP global rate limit, including possibly randomizing the max allowable burst (currently 50), minimum number of tokens recovered each time (currently 20), minimum idle time to recover tokens (currently 20ms), and number of token recovered per time unit (currently 1 per millisecond). When the side channel is mitigated, we also recommend resolvers adopt the use of connect() on their UDP sockets so that their source ports will not be public-facing and directly scannable.

For (2), we have discussed best practices to use RRL to prevent an attacker from muting authoritative name servers easily.

Other simple mitigation strategies include: (1) setting the timeout of DNS queries more aggressively (e.g., always below 1s). This way, the source port will be short-lived and disappear before the attacker can start injecting rogue responses. The downside, however, is the possibility of introducing more retransmitted queries and overall worse performance. (2) Employing anycast to make it harder for an attacker to DoS a specific authoritative name server used by a victim resolver.