[c-nsp] rate limit dns

[MIke]

On 12/27/2013 12:24 AM, Dobbins, Roland wrote:
> On Dec 27, 2013, at 10:55 AM, Mike<mike-cisconsplist at tiedyenetworks.com>  wrote:
>
>>     Can anyone suggest how we might tighten this up and either have a seperate rate limit list or somehow exclude my small list of resolver IP's from the above limiting?
> Using any QoS mechanism, let alone an old, obsolete, unmaintained one like CAR, to deal with DDoS isn't a good idea - programmatically-generated attack traffic can 'crowd out' legitimate traffic.

I am reasonably sure that for this one application - dropping floods of 
dns traffic - is a reasonable step. The only mechanisiam I think I have 
at the moment, is to assert that dns from the internet to my subscribers 
on my network is likely to have a reasonable peak flow of about 1mbps 
and that if I see 15mbps or more it's likely an attack. My customers 
_should use_ my resolvers, which I would exclude from this limiting, and 
anyone who has trouble with off-network resolvers during these floods 
are well-advised to use my resolvers instead.

> Why are you allowing DNS responses from outside your network to your subscribers at all, excepting Google DNS, OpenDNS, and anything specifically arranged for specific customers (the assumption is that you're running a consumer broadband access network)?

Open internet. I don't want to dictate to anyone which port numbers or 
protocols they are limited in using, and I want to impose only the 
absolute minimum of controls in order to deliver as much of an 
unfiltered / unrestricted service as I can. I try to find reasonable 
compromises. Hell, I myself run an openvpn server listening on udp port 
53 for exactly the reason of being able to vpn thru restrictive 
firewalls because it's important to me.

> Also, you should have sufficient layer-3 hierarchy in your network to have the ability deploy policies/mitigation tools at your transit edge which do not affect your customer aggregation edge, and vice versa.  If you don't currently have separation of these topological roles, then implementing same should be a priority.
>
>

That may be a wonderful design goal in theory, but our 'transit edge' as 
you call it, is a pair of linux boxen that do not have any effective 
interface for implementing policies or mitigation tools. Since the 
broadband aggregation is just one hop away from the transit edge , I 
think it makes sense to implement the controls here anyways. My real 
goal is to protect the interior network from 400+mbps floods when those 
links themselves don't have more than 100mbps each, which would result 
in wider problems as they got saturated. There is no other way for 
internet sourced traffic to hit these links with that level of traffic 
anyways since there's no internet facing ip addresses other than 
customer point to point addresses. If I really had my druthers, I would 
be limiting customer rates at the broadband aggregation point but that 
would take a lot more work.

Mike-