DNSCurve: Usable security for DNS
The dnssecamp toolInstalling DNSSEC turns a server into the Internet equivalent of a remote-controlled machine gun. The dnssecamp tool allows administrators and users to evaluate the amplification danger posed by the current pool of DNSSEC servers.
This page explains how to use dnssecamp. Prerequisites: typical Linux; e.g., Ubuntu.
Collecting estimatesDownload the dnssecamp tool:
wget http://dnscurve.org/dnssecamp-20101224.tar.gz tar -xzf dnssecamp-20101224.tar.gz cd dnssecamp-20101224No compilation is necessary; the tool consists of a few simple scripts.
Collect a list of IP addresses of DNSSEC servers, along with the DNSSEC domain names handled by those servers:
./findservers > findservers.outThis tool relies on a database collected by DNSSEC proponents, secspider.cs.ucla.edu. The tool begins by mirroring the database (warning: over a gigabyte!) and then extracts the IP addresses and domain names from that database. As a cheap alternative you can use a recent ./findservers output included in the dnssecamp package:
cp findservers.out.example findservers.outThis also has the obvious advantage of being immune to changes in the secspider.cs.ucla.edu database. It has the obvious disadvantage of not being quite up to date.
For each DNSSEC server, find the domain name with the largest estimated amplification factor (by querying the server), and record that domain name:
./bestamp < findservers.out > bestamp.outThis is not parallelized; it might take an hour or two, depending on your network latency.
A recent run finds
Verifying estimatesHere is how to measure the actual DNSSEC amplification, verifying the estimates produced above.
Install dnssecamp on two quiet machines on different networks: a sender machine without egress filtering, say 220.127.116.11, and a receiver machine, say 18.104.22.168. If you're on a network with egress filtering, you have two choices:
Start a network-traffic monitor on the receiver machine:
./measurenet > measurenet.out &
Also start a network-traffic monitor on the sender machine:
./measurenet > measurenet.out &
On the sender machine, as root, configure the receiver address as a local address:
ifconfig eth0:1 22.214.171.124 netmask 255.255.255.255Note that this will prevent normal communication between the sender machine and the receiver machine.
On the sender machine, generate 1 query per second to each of the DNSSEC servers, with responses directed to the receiver machine:
./measureamp 126.96.36.199 < bestamp.out &After a minute, check the recent traffic loads printed by ./measurenet on each machine:
tail -30 measurenet.outIf background noise is making the loads hard to see, run several parallel copies of ./measureamp to increase the number of queries per second and the number of bytes sent to the receiver machine. A typical recent test showed the sending machine generating 13236 bits per second and the receiving machine receiving 678695 bits per second, a stunning amplification factor of 51.
On the sender machine, when you're done with the amplification measurements, remove the receiver's address as a local address:
ifconfig eth0:1 downAlso stop the ./measurenet and ./measureamp processes.
Future workImagine an administrator whose site can handle at most a 10 Gbps flood. The administrator's first question is whether the remote-controlled DNSSEC machine guns are capable of generating 10 gigabits of traffic per second. The administrator's second question is how much capacity the attacker needs to trigger those machine guns.
dnssecamp reports the number of DNSSEC servers but does not attempt to measure their bandwidth. The bandwidth is obviously important to answer the first question. For example, if 2500 DNSSEC servers each have 40 Mbps connections to the Internet then an attacker can abuse them to generate a 100 Gbps flood, enough to disable practically any site on the Internet. If they have only 1 Mbps connections on average then they can generate only a 2.5 Gbps flood, enough to disable most sites but not large sites.
By reporting an average amplification factor of over 50, dnssecamp makes clear that the attacker can trigger a 100 Mbps flood using only 2 Mbps, can trigger a 1 Gbps flood using only 20 Mbps, etc. However, dnssecamp does not make clear how far this pattern goes. The overall power of the DNSSEC machine-gun pool is still an open question.
Of course, deploying DNSSEC on twice as many servers would mean increasing the power of the machine-gun pool by a factor of 2, and deploying DNSSEC on ten times as many servers would mean increasing the power of the machine-gun pool by a factor of 10.
VersionThis is version 2010.12.25 of the dnssecamp.html web page.