[dns-operations] DNS deluge for x.p.ctrc.cc

[Lutz Donnerhacke]

* Paul Vixie wrote:
> the only hint of a solution i've seen in all this so far is automated
> shunning of known-open-recursive + known-recent-abused name servers, in
> order to push these attacks toward other UDP-based services like
> (authority name servers) which are more limited in number and thus may be
> a more tractible battlefield.

The current amplification attack is based on four preconditions:
  1. spoofing possibilities
  2. a protocol without sender verification
  3. an amplification service
  4. servers running the service without rate limits

In order to mount the attack you only need dense deployment of point 2, the
protocol.

Sparse occurences of condition 1 (spoofing injection points) are sufficient,
so BCP38 does not help.

The abused service (point 3) itself is irrelevant, because it is easy to
exchange. You only need a single idea which service to abuse, but there are
millions. So changing or cutting the service (DNS-extensions like EDNS,
IPv6, DNSSEC) is a long term self lart, but stops the attack only for days.

Condition 4, the running servers, is fullfilled, if they are sparsly
distributed. Sometimes (like authoritive DNS server) they can't be rate
limited.

So consequently if you really want to solve the problem, you need to drop
the UDP protocol everywhere and filter it. This is the only requirment with
dense distribution characteristics.

Of course dropping UDP is not a solution, therefore the hard task starts:
Reducing the area of sparse requirments: Close injection points and close
unecessary servers with open or un rate-limited configurations. Boths tasks
has to be done.

Unfortunely due to the ease of change in requirment 3, the servers are a
moving target. Next month we will fight on other servers for other services
based on UDP.

So let's do the hard job and stop hitting ourself by changing protocols and
useful extensions.

>From my personal point of view the more important problem with large DNS
answers is qmail. We run DNSSEC and IPv6 in productive enviroment which
guarantees third party qmail implementations to break. In each case qmail
was dropped.