DNSCurve: Usable security for DNS

You're running a small company and decide to move to another building. You'll have to change the IP addresses of your mail and web servers. Before the move, you reduce the TTLs on your DNS records to a few minutes, so that caches check back with you frequently. On the day of the move, you install servers in the new building, change your DNS records to point to the new IP addresses, and then move servers out of the old building.

An attacker buys the old IP addresses, sets up his own fake servers on those addresses. and forges DNS responses for your domain pointing to those addresses. Clients around the world that want to deliver mail to you, or to see your web pages, now connect to the attacker's fake server.

Would DNSSEC protect you in this situation? No! Before the move, the attacker saves your DNS responses, including your DNSSEC signatures on the old IP addresses. After the move, the attacker forges DNS responses with the same signatures on the same IP addresses. The signatures are still valid.

DNSSEC tries to limit the damage by including an expiration time in each signature, normally a month after the signing time. Any signature past its expiration time is rejected; the client is assumed to have a secure local clock. But the attack continues to work for a month! Did you keep servers running on the old IP addresses for a month?

The expiration time also means that your DNS server needs new signatures before the end of the month. If it doesn't have new signatures, you'll be a victim of "DNSSEC suicide": from the perspective of any client that supports DNSSEC, your domain will drop off the Internet. It's possible to reduce the month to a shorter period, but very short periods create severe usability problems and reliability problems.

Client differentiation

The www.redhat.com web site, like www.amd.com and many other Internet web sites, is actually published by Akamai, a company that operates thousands of servers around the world. Akamai dynamically spreads copies of the www.redhat.com pages across many of its servers, adapting to changing Internet loads. When a user asks for the address of www.redhat.com, Akamai quickly computes a short list of nearby servers that contain copies of www.redhat.com, and returns that list in its DNS response.

An attacker watches a www.redhat.com query from a user in Porto Alegre, records the response, and replays the same response for a user in Berlin. The user in Berlin now tries to connect to Akamai's faraway Porto Alegre servers and suffers from a slow, unreliable connection. Perhaps the web page does show up eventually, but it's in Portuguese rather than German.

Would DNSSEC stop this attack? No! The most aggressive possible expiration times, flirting with complete DNSSEC meltdown, would merely force the attacker to consume a tiny bit more traffic checking for new Porto Alegre responses.

How does DNSCurve help?

DNSCurve protects packets communicated between two parties, a client and a server. The server authenticates and encrypts a response to the client that asked the question, using the server's secret key and the client's public key. The client verifies the response using its secret key and the server's public key. A packet sent to one client can't be replayed to another. DNSCurve's nonces mean that an attacker can't even replay an old packet to the same client.

For comparison, because DNSSEC insists on precomputing signatures, it has only the server's key. It cannot use client keys to guarantee client differentiation, and it cannot use client nonces to guarantee freshness.

Version

This is version 2009.06.24 of the replays.html web page.