DNSCurve: Usable security for DNS
Amplification via cachesAmplification attacks exploiting DNS caches became popular a few years ago. Attackers would send a short query to a cache, which would generate many kilobytes of data trying to find the answer to the query. A low-volume series of queries would cause the cache to overload its own network.
There are several recommended steps that administrators can take against these attacks. Administrators can limit the IP addresses that are permitted to query their caches (a feature advertised, and enabled by default, in djbdns starting in 1999). Query IP addresses can be forged, but it is easy to prevent outside packets from reaching a single-machine cache running on 127.0.0.1. Administrators can also avoid amplification-friendly server configurations, such as out-of-bailiwick glue and "anti-spam" reverse DNS lookups.
Amplification via serversAmplification attacks exploiting DNS servers are relatively difficult to control. Typical DNS servers have to be open to requests from anywhere around the Internet.
The following interesting example was pointed out by Bert Hubert:
dig +bufsize=4096 +dnssec any se @a.ns.sesends a 31-byte UDP packet to one of the top-level Sweden servers. That server sends back a 3974-byte UDP packet, mostly consumed by DNSSEC data. If the original UDP packet has a forged sender address of 18.104.22.168 (sorry, not a standard dig option!) then the Sweden server will send its 3974-byte UDP packet to 22.214.171.124.
dig +bufsize=4096 +dnssec any br @a.dns.brtriggers a 1621-byte UDP packet. If the original 31-byte UDP packet has a forged sender address of 126.96.36.199 then the Brazil server will send its 1621-byte UDP packet to 188.8.131.52.
dig +bufsize=4096 +dnssec any isc.org @ams.sns-pb.isc.orgtriggers a 3995-byte UDP packet. If the original 36-byte UDP packet has a forged sender address of 184.108.40.206 then the ISC server will send its 3995-byte UDP packet to 220.127.116.11.
An attacker can generate an overwhelming volume of data to 18.104.22.168—one of the Internet's root servers—by collecting many DNSSEC servers and sending each of them a much lower volume of queries. Challenge for the reader: Can you generate more bytes of data in a response from a.dns.br? What is the maximum flood you can generate from a single 10Mbps connection, or from 100 different machines each having a 10Mbps connection? You may find it useful to start from the list of DNSSEC servers at http://secspider.cs.ucla.edu.
What about DNSCurve?DNSCurve's cryptographic protection expands response packets, but only in response to expanded queries. The overall amplification ratio for DNSCurve is smaller than the overall amplification ratio for normal DNS. DNSCurve also expands each DNS server name by about 50 bytes, leading to somewhat larger glue packets than before, but selected non-glue packets provide much larger amplification ratios. In other words, sensible attackers won't use DNSCurve for amplification.
VersionThis is version 2009.06.30 of the amplification.html web page.