DNS/FCP/5

5 Conclusions and Defenses

We showed how an off-path attacker can efficiently exploit fragmented DNS responses to poison DNS caches.

Most DNS responses are short, and hence not fragmented; our attacks exploit DNSSEC records, which often result in fragmented responses.

We also showed that fragmented responses can be exploited by off-path attackers to force the resolvers to query name servers of attacker’s choice.

The attacks are effective against valid implementation of the DNS and IP specifications; furthermore, we have confirmed effectiveness against several domains, using real network scenarios and common resolvers (Unbound 1.4.1 and Bind9).

We  want  to  caution  against  drawing  the  conclusion that DNSSEC should not be used.

In fact, the best defense is to apply DNSSEC correctly in all resolvers and domains 
(without using NSEC3 opt-out);
this will certainly prevent many of our poisoning attacks, 
and even defend against more powerful Man-in-the-Middle adversaries.

However,  incremental  DNSSEC  deployment  is vulnerable to our cache poisoning attacks, and complete
adoption of DNSSEC may take considerable time,
since it depends on adoption by both name server and resolver.

Furthermore,  this  will  not  prevent  the  server  blocking attacks.

Hence,  we  also  discuss  some  other  defenses,
which can be utilised by only one of the parties (unilaterally), and can also prevent the DNS response blocking attacks.

The vulnerability which allowed us to launch the poisoning attacks against recursive resolvers, is due to the fact that

  the esolver advertises a large EDNS buffer, which is usually larger than the MTU, e.g., 1500 bytes.

Although support of large DNS responses is critical to facilitate DNSSEC enabled DNS responses, or public-key certificates [34], such long responses can be (temporarily) sent over TCP, using path MTU discovery and avoiding fragmentation - unfortunately, at significant performance costs.

Another countermeasure, possible at resolver, name server or even at intermediate gateway (firewall), is to set a maximal EDNS buffer value to at most 1500, or even less, to avoid fragmentation.

In fact, resolvers may implement a simple protocol similar to path MTU discovery, then set the value of the EDNS buffer accordingly to the minimal MTU en route between the resolver and the DNS server.

When sending responses,
 the name server should also set the DF bit in the IP header to 1, i.e., do not fragment.

Another short-term defense, which administrators of resolvers can apply, is to reduce the maximal number of fragments cached; e.g., currently 64 by default in Linux (per (source IP , dest IP , protocol) triplet). Of course, reduction in this parameter may also increase packet loss.

Yet another possible defense for name servers, is to always add a random RR
to any packet over certain size (i.e.,  which may be fragmented).

A simple type A resource record, containing random IP address for some fictitious domain name, would suffice.

The TTL of such an RR should be set to zero to prevent the resolver from caching that record.

This would prevent the attacker from being able to predict and (correctly) adjust the checksum value. If there are multiple vulnerable fragments, such a random RR should appear in each fragment.

Finally, we suggest to be careful when deploying the proposal in [25, 36] (for server selection) which recommends to avoid querying non-responsive servers. Resolvers that do not conform to that recommendation, e.g., Bind9, are not vulnerable to our server-pinning attacks.