[dns-operations] responding to spoofed ANY queries

[Mark Andrews]

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
> https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03
> 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
trains.

> 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
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org