DNS queries limitation by host ?

[Kevin Darcy]

Ladislav Vobr wrote:

>>Nobody else was. The OP was talking about query rate limiting hooks
>>for BIND. There was no mention of dynamic rate limiting. Until you
>>raised this non sequitur.
>>    
>>
>
>hmm, jim imho he was talking about rate limiting of hosts which he 
>doesn't know, which is basicaly dynamic, in this case your solution to 
>use router where you have to hardcode the customer ip is not really 
>helpfull, believe it or not.
>
>  
>
>>This is utterly irrelevant to the original discussion. DNS service is
>>not an application in the same sense as an HTTP or SMTP server is an
>>application. The same goes for the respective protocols. And as I
>>already said, BIND does not have hooks for limiting inbound
>>queries. For DNS queries That job is best done by a router in front of
>>the name server.
>>    
>>
>
>hmm, just think about it jim, it is about the same thing, not to let one 
>  random guy to overload the service and make it non-responsive for 
>others, router doesn't help it (be it http or smtp or dns, udp or tcp. 
>Router does only overall traffic, which is useless since the service is 
>basically non-responding for the rest of users during the flood. Best 
>job for dns queries imho is dynamic rate limiting, which routers don't do.
>
>  
>
>>    Ladislav> 	hmm, what is small for you, do you know that today
>>    Ladislav> almost everybody has at least isdn,dsl,cable ? Do you
>>    Ladislav> know that to fill the recursive-client queue on bind is
>>    Ladislav> a piece of cake even for analog dial-up user? Do you
>>    Ladislav> know, that bind doesn't even bother to log this or give
>>    Ladislav> you a hint why and who doing this?
>>
>><scarcasm mode>
>>No. What's dsl? Do you mean to say a name server needs to be
>>configured and tuned for the environment where it gets deployed?
>>Fancy that!
>></scarcasm mode>
>>    
>>
>
>It's not really difficult to fill up recursive-client queue today, even 
>from the slowest line, believe it or not, and tuning for such cases is 
>curretly zero, there are two ways, either be quiet about it, or try to 
>do something about it.
>
My 2 cents: the simple brute-force DNS (D)DoS attacks are probably 
better foiled using some sort of dynamic rate-limiting in the router, 
since then you drop the packets as soon and efficiently as possible. 
However, there are more sophisticated DNS (D)DoS attacks possible, 
including:
1. Querying a wide range of long-TTL names with the aim of filling up 
the cache with junk, or
2. Querying names which are known to have unreachable nameservers, 
broken delegations, or other forms of DNS nastiness, with the aim of 
busying out the victim resolver with retries, error recovery, logging, etc.

These kinds of (D)DoS attacks might give more "bang for the buck" per 
query and thus allow the attack to succeed even as it flies under the 
radar of a router-based rate-limiting scheme. It might be impossible in 
some scenarios (because the routers don't have access to the resolver's 
state information) or at the very least cost-prohibitive, to put code in 
the routers to foil such attacks and therefore might be better to put it 
in the resolver code.

- Kevin