DNSCurve: Usable security for DNS


Introduction
DNS users:
Why DNSCurve?
Installing DNSCurve
DNS data managers:
Why DNSCurve?
Installing DNSCurve
DNS implementors:
Caches
Forwarders
Protocol designers:
Cryptography
DNS integration
Attackers:
Forgery
Negative forgery
Replays
Query espionage
Database espionage
+ nsec3walker
CPU flooding
Amplification
+ dnssecamp

DNS amplification

Amplification via caches

Amplification 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 servers

Amplification 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.se
sends 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 198.41.0.4 (sorry, not a standard dig option!) then the Sweden server will send its 3974-byte UDP packet to 198.41.0.4.

Similarly,

     dig +bufsize=4096 +dnssec any br @a.dns.br
triggers a 1621-byte UDP packet. If the original 31-byte UDP packet has a forged sender address of 198.41.0.4 then the Brazil server will send its 1621-byte UDP packet to 198.41.0.4.

Similarly,

     dig +bufsize=4096 +dnssec any isc.org @ams.sns-pb.isc.org
triggers a 3995-byte UDP packet. If the original 36-byte UDP packet has a forged sender address of 198.41.0.4 then the ISC server will send its 3995-byte UDP packet to 198.41.0.4.

An attacker can generate an overwhelming volume of data to 198.41.0.4—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.

Version

This is version 2009.06.30 of the amplification.html web page.