[dns-operations] Why would an MTA issue an ANY query instead of an MX query?

[Kyle Creyts]

On Sun, Jun 10, 2012 at 2:33 PM, Paul Vixie <paul at redbarn.org> wrote:
>> I'm afraid we may need more control. If my clients are generating a DDoS
>> attack at 20 responses per second, and I limit this to 5 per second -
>> the C&C can get the same effect by mobilizing four times as many clients
>> to do the job.
>
> no. the client ip is spoofed. the number of spoofers doesn't matter,
> when the reflector is looking at both the apparent client ip and the
> intended response. when most well-provisioned authority servers are
> running with some kind of rate limiting, then the only way to do a
> reflective amplifying ddos will be (a) do it through recursive not
> authority servers, or (b) send a small number of queries to a large
> number of authority servers, or (c) switch to some other wide area udp
> such as ntp or snmp or syslog or whatever.

Someone mentioned that as soon as the spoofed client is blocked, that
a new spoofed client is used... This behavior seems... strange. How
quick is this shift? How would one know when to shift the target? The
modes I _can_ come up with largely involve having some sort of
information about what is reaching the target. (bandwidth or traffic
sources) This just leads to more interesting questions about those
perpetrating the attacks, and their intent. Is there an obvious way of
discerning the time to switch targets that I am missing? Is this a
non-interesting topic?

>
> none of those things is low hanging fruit; they will require enough
> work, even by script kiddies, that most attackers will switch back to
> ddos-for-hire which will work through direct bombing by botnets. this is
> because recursive servers can generally run closed (on-net or on-campus
> only) and the smallish number of open ones can rate limit (as opendns
> and googledns both do today); and because maintaining a catalogue of
> server+qtuple inputs for spoofed-source attacks will be a lot more work
> than "just use ripe.net or isc.org" as happens today; and because ntp
> and snmp generally reflect just fine but don't amplify as well as dns.
>
>> On my wishlist, in addition to rate limiting, is also:
>>
>> - Some way of dynamically blackholing clients, based on one or more of
>> -- Rate limit exceeded
>> -- Asking the *same* question (with a large response) repeatedly
>> -- Asking a *specific* question (e.g. ANY isc.org|ripe.net)
>> -- Input from an external system, e.g. via rndc
>
> all but the last is already done. distributed blackholing of abusive
> source addresses is dangerous, since in udp, the source addresses will
> often be spoofed. this means blackholing is likely to cut off responses
> to legitimate queries from the victims. (vernon and i spent a lot of
> time working on that problem especially.)
>
> paul
> _______________________________________________
> 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



-- 
Kyle Creyts