[dns-operations] responding to spoofed ANY queries
Vernon Schryver
vjs at rhyolite.com
Thu Jan 10 21:57:39 UTC 2013
> 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.
> 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.
> * 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.
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 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
More information about the dns-operations
mailing list