[c-nsp] rate limit dns

[Mack McBride]

'Other mechanisms' is a beautiful catch phrase for hire a DDoS mitigation vendor.

Many reflection attacks do use authoritative servers because of the amount of throughput
those servers have.  Most are quite capable of a full gig of traffic.  I know ours certainly are.
SPF records (ie. TXT) are a favorite target since they can be fairly large.
And with signed records it is even worse.

And I agree that open resolvers are a major issue.
However, I think limiting my customer's choices of resolvers is bad as well.

I am aware of your credentials, however, I disagree with blocking DNS choice to customers.
For example many of our BGP customers are also customers of other companies.
Why would a company that requires maximum uptime want to depend on our DNS servers
when they have bandwidth from a number of other companies?

I would say this is getting way off topic and we will have to agree to disagree on this point.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbride at viawest.com | www.viawest.com | LinkedIn | Twitter | YouTube



-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dobbins, Roland
Sent: Tuesday, December 31, 2013 2:34 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] rate limit dns


On Jan 1, 2014, at 4:13 AM, Mack McBride <mack.mcbride at viawest.com> wrote:

> Recursive servers have to be able to receive responses from anywhere on the internet.

Hence 'external resolvers', mentioned in my post.

<https://app.box.com/s/72bccbac1636714eb611>

> Nor can RTBH stop a true DDoS.

S/RTBH can, up to the point that the number of sources becomes unmanageable.  Hence, 'other mechanisms', mentioned in my post.

>  That is the 'distributed' part that is the first D. Nor will it stop a reflection attack, which is even more damaging because then you are blocking important authoritative DNS servers.

Again, hence 'other mechanisms', mentioned in my post.

Also, if you're on the designated-target leg of a DNS reflection/amplification attack, in most (not all; directly-spoofed ANY attacks and the like, which don't involve open recursors, are the exception) cases, you're receiving traffic from open recursors, not authoritative severs, and the sources you end up blocking are open recursors, not authoritative servers.

If your external resolvers are open recursors and are being abused, then you need to remediate them.

> As an ISP operator, I can tell you that your solution will only work for someone whose customers can't leave for another provider.

As someone who's worked with many ISPs to successfully mitigated many extremely large-scale and complex DNS-related DDoS attacks, including 100gb/sec+ reflection/amplification attacks, I can assure you that I do in fact understand the issues involved and how to deal with them.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/