DNSCurve: Usable security for DNS

Installing 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 estimates

Download the dnssecamp tool:

     wget https://dnscurve.org/dnssecamp-20101224.tar.gz
     tar -xzf dnssecamp-20101224.tar.gz
     cd dnssecamp-20101224

No 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.out

This 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.out

This 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.out

This is not parallelized; it might take an hour or two, depending on your network latency.

A recent run finds

2326 DNSSEC servers with estimated amplification factors above 30, including
1644 DNSSEC servers with estimated amplification factors above 50, including
707 DNSSEC servers with estimated amplification factors above 70.

The largest estimated amplification factor is 95, achieved by eight .fi servers and three .se servers.

Verifying estimates

Here 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 1.2.3.4, and a receiver machine, say 5.6.7.8. If you're on a network with egress filtering, you have two choices:

Use a sender machine and a receiver machine on two different subnets of that network.
Use the same sender machine and receiver machine.

Another possibility is to inject raw packets from a sender machine on the same subnet, but this isn't supported by dnssecamp.

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 5.6.7.8 netmask 255.255.255.255

Note 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 5.6.7.8 < bestamp.out &

After a minute, check the recent traffic loads printed by ./measurenet on each machine:

     tail -30 measurenet.out

If 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 down

Also stop the ./measurenet and ./measureamp processes.

Future work

Imagine 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.

Version

This is version 2017.01.22 of the dnssecamp.html web page.