[dns-operations] responding to spoofed ANY queries
marka at isc.org
Thu Jan 10 23:43:07 UTC 2013
In message <201301102157.r0ALvdAh025741 at calcite.rhyolite.com>, Vernon Schryver writes:
> > From: Mark Andrews <marka at isc.org>
> > As far as I can tell there is no way to stop reflection attacks as
> > long as ISP's allow spoof traffic to enter their networks. The
> > attackers will just go broad spectrum (millions of reflectors) and
> > no single reflector will be able to see that it is part of a attack.
> A problem with using a million reflectors is that it is a lot more
> hassle. The goal need not be preventing all reflection attacks but
> only making reflection attacks less rewarding and more costly than
> other attacks, such as simple UDP floods from a modest botnet.
The other part of the goal is to not lose resourse. Reflection
attacks help there.
> > It is possible to detect current reflection attacks and mitigate
> > them using RRL but this is only a stop gap measure which causes the
> > attackers to choose different refectors.
> I agree, with the reservation that eventually RRL could eventually
> cause attackers to choose different attacks.
> > What we can do is turn off amplification attacks. We know a number of
> > methods of how to do this.
> > * set TC=1 on all UDP query replies and force the client to TCP.
> which would kill busy DNS servers.
Indeed. RRL does this selectively.
> > * do a handshake over UDP before sending amplified replies.
> What qualifies as amplification? An unsigned (no DNSSEC) A request/response
> is good for at least 3X. 10X or 20X is impressive but merely eases
> the attacker's job by allowing fewer reflectors.
We can go from 1X upwards.
> Would you turn off all DNS/UDP without a DNS cookie by augmenting
> with some kind of minimal "try again with a cookie" response similar
> to but different from a minimal TC=1? I like DNS cookies, but they
> would take many more years to deploy widely enough to matter than have
> already passed since the I-D expired.
If we had a code point we could see 10% deployment within a year
especially if it pushed out in maintanence releases of older code
> If cookies, ttcp, or some other DNS protocol change is The Answer,
> then in the years before The Answer is deployed, you're stuck with
> making reflection attacks less attractive than alternatives,
> which will slow The Answer.
> Vernon Schryver vjs at rhyolite.com
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations