Recently, two papers independently outlined new attacks against DNS, undermining some of the security features protecting us from DNS spoofing.

As Dan Kaminsky showed [1], 16 bit query IDs are an insufficient protection against DNS spoofing. As a result, DNS servers started to randomize the source port of DNS queries in order to make DNS spoofing harder. This was never meant to "fix" DNS spoofing, but worked well enough for DNSSEC to be pushed back yet again.

Overall, to successfully spoof DNS, the attacker has to overcome various challenges:

• reply before the valid reply arrives: This can easily be done starting to flood replies even before the query was sent.
• Guess the DNS Query ID and the source port of the query: Currently, this challenge is considered the major stumbling block.
• Once the valid query arrives, the attacker is "locked out" from attempting another spoofing attempt until the TTL of the record expires (Dan Kaminsky showed how this can be overcome by asking for non existing records)

The new attacks are using two more modern DNS features:

Reply Rate Limiting (RRL)

DNS spoofing isn't the only DNS problem we need to defend against. DNS servers may be abused as reflectors in denial of service (DoS) attacks. Even if a DNS server is only answering queries for which it is authoritative, it may still be abused by asking for records for which it is authoritative for. Modern DNS servers (e.g. BIND 9) implemented a feature to limit how many responses a DNS server will send. If the limit is reached, the DNS server may either not respond at all, or reply with an empty truncated reply. The empty truncated reply will force the source of the query to return via TCP. If the query was spoofed, then this will not happen. BIND by default skips every second reply in this scenario. 

The problem arrises if the attacker floods an authoritative DNS server to prevent it from sending responses. This will provide more time to send spoofed responses back. Researchers have shown that this can lead to DNS spoofing. But it requires a lot of packets (100 MBit for 8 hrs) to be successful as the Query ID and the source port needs to be brute forced. [2]

To defend against this attack, while still maintaining a RRL, it is sufficient to adjust the slip value which governs how frequently the DNS server will skip a DNS reply while under distress. A slip value of  "1" will not skip any replies.

Fragmented EDNS0 replies

Originally, DNS replies were limited to 512 bytes to avoid fragmentations. Any larger responses had to be requested via TCP. However, TCP requires significant higher overhead and the query needs to be sent twice. Modern DNS tends to use larger replies with IPv6 and DNSSEC records, as well as the use of DNS for load balancing. In response, a new feature, EDNS0, was introduced. If enabled, the DNS server may signal a maximum response size that is larger then 512 bytes. A typical value is 4096 bytes. As a result, these responses are frequently fragmented.

If the response is fragmented, all values used to "authenticate" the response are in the first fragment (query id and udp ports). It is now possible for an attacker to spoof the additional fragments. All the attacker has to guess is the fragment offset and the fragment ID. The fragment offset can be guessed assuming that the MTU is 1500 bytes (or it can be derived from the MSS if a TCP packet from the DNS server is received by the attacker). The fragment ID (or IP ID) is frequently incremented from packet to packet, so it can be easily guessed. If it is random, it is still only 16 bit long. [3]

There is no decent defense against this attack so far. Disabling EDNS0 may work, but it will lead to problems with DNSSEC which requires EDNS0. Your operating system may allow you to randomize the query ID and this should probably be a minimum protecting for now.

DNSSEC of course remains the only REAL protection against these attacks.

[1] http://dankaminsky.com/2008/07/24/details/
[2] http://www.ssi.gouv.fr/en/the-anssi/publications-109/scientific-publications/conference/abusing-anti-ddos-mechanisms-to-perform-dns-cache-poisoning.html
[3] http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter