Tightened DNS security question re: DNS amplification attacks.

Paul Vixie vixie at isc.org
Wed Jan 28 13:30:05 CST 2009

> Pretty soon we need an RBL for DNS-oriented DDoS attacks. =)

in the classic sense, you're wrong.  in a neoclassic sense: "maybe".  let me
explain.  the original RBL was designed to reject TCP/25 (SMTP) transactions
based on source address reputation.  we had a false start where we blackholed
these addresses as destinations, figuring that if they couldn't hear our ACK
then we would never get into TCP with them.  then we decided to reject inside
the SMTP server and that's what the world has settled on.  but throughout, we
have been able to bind a reputation to an IP address and act in some way based
on that reputation because TCP more or less requires that a real IP address
be used.  we're seeing cracks at the edges of this model now, because so many
core routers have login: cisco; password: cisco, and it's now trivial for any
spammer to inject BGP that either lights up unallocated space or cuts out a
piece of somebody else's allocated block.  this makes it possible to very
temporarily and untraceably speak TCP from addresses that have no reputation
(if they're unallocated) or that have a good reputation (if they're cutouts).

DNS-oriented attacks are of a completely different kind.  today's attacks were
precisely described in <http://www.icann.org/en/committees/security/sac004.txt>
(which wasn't news in october 2002 but somebody had to write it down so i did).
the important statement out of that 4-page document is: "Source addresses that
appear at Border or Interior connections are nonrepudiable by nature..." and
that statement bears on the question of RBL for DNS-oriented DDoS attacks since
the address we'd have to assign a reputation to is the victim, so all we can
do is make an attack worse (by denying service to the victim's real traffic.)

i've pondered whether a network reputation service based on morality rather
than behaviour could possibly work.  in other words an RBL-like entity that
did not prevent attacks, but rather, which denied service to collaborators.
if someone claims they can't deploy BCP38 and if their network or nameserver
is then used as a launch point for spoofed packets toward reflectors and
amplifiers, then would anyone be willing to deny service to them -- to paint
them as having a negative reputation even though their "sin" is laziness or
cluelessness rather than malevolent intent?  and if someone claims they can't
turn off open recursion and they get used as an amplifier, would anyone here
be willing to deny that recursive server access to their authority server, not
on the basis that it might attack them, but strictly to pressure an upgrade?

note, i'm speaking as a concerned internet citizen here, not as an ARIN
trustee or as ISC's president.  i really want to know if folks would be
willing to shun eachother not on the basis of evil but rather complacency.

More information about the NANOG mailing list