On Sat, 10 Mar 2007, Douglas Otis wrote:
> The higher gain attacks leverage a large RR not normally found in
> most authoritative DNS.
This assertion isn't true. Several examples were given of common large
record types frequently found on authority servers.
> Recursive servers can be easily located without any scanning
Really? How?
Some millions more authority servers are easily found without scanning.
Querying them for large records is not suspicious.
By contrast, searching for recursors is (unless you've discovered some
interesting new way of finding them without scanning---I'm very
interested to hear about that) some that can be detected, so that
the abusers can be identified.
> and then asked to obtain an answer referencing problematic RRs(which
> may be poorly considered SPF RRs).
RRs which come from authority servers. If you are the attacker, why not
simply hit the authority servers? Why not use the root servers in the
attack?
> Preventing access to recursive servers significantly reduces the
> possible sources relied upon by a distributed mode of attack.
Your claim here restates your premise without proof. Repeating your
claim does not make it true. I have shown that it is far easier to find
a very large number of authority servers than it is to scan for
recursors.
There are many authority servers with large records, including the root
servers, that have access to very high bandwidth connections, making
them ideal for use in a DOS attack.
Why would a DOS attacker try to search out recursors, which can be
mitigated, when the attacker could launch a much more devastating attack
with much less work?
Further, 'closing' the recursors creates additional problems, including
opportunity for additional DOS attacks. You haven't addressed any of
these harms. As I said, your proposed solution is worse than the
original problem.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
