Defense against a client?

Phil Mayers p.mayers at imperial.ac.uk
Tue Jan 17 09:47:07 UTC 2012


On 01/17/2012 05:13 AM, Mark Andrews wrote:

>> If one sets up a infrastructure such that a large number of end users "share
>> the same fate" through having the same source address... then one should not
>> be surprised when these end users actually do share the same fate...
>>
>> -DMM
>
> Assuming that there is a single client on a single address has
> *never* been a valid assumption.  Security policies that assume
> that are *broken*.  Even with IPv6 this will not be a valid assumption
> though you may get to a single machine per address.  machine is
> still not client.

Surely the answer is "it depends"?

As far as I could see, the original poster didn't specify whether the 
server he was suffering load problems on was authoritative i.e. publicly 
accessible or recursive i.e. a known client base, although the 
circumstances suggest the latter.

If it's an authoritative server then he's got a hard problem to solve, 
but if it's recursive, then unless he's running a massive public access 
DNS system (unlikely, I feel) then he can probably state with some 
degree of assurance whether CGNs are between him and his clients.

In fact, I've been amazed to see this discussion progress without any 
references to the circumstances of the original poster, who stated quite 
clearly that the load from the malfunctioning clients was sometimes so 
high as to deny service for other clients.

Arguing the toss over whether per-IP rate-limiting is going to cause 
problems for legitimate users is a bit pointless when the DENIAL OF 
SERVICE his server is experiencing is ALREADY causing problems for all 
users, legitimate or not.

Per-IP rate-limiting can indeed cause problems for legitimate users. So, 
what would you suggest as an alternative? I suggest that, in front of an 
enterprise recursive server, it's appropriate and unlikely to cause 
harm, if the limit is set high enough to let all legit traffic through.

In the case of authoritative service for popular zones, or publicly 
accessible recursive services, per-IP limiting is unlikely to be 
appropriate. But likewise, those kinds of services are unlikely to 
suffer the same resource and architecture constraints - their operators 
can probably just deal with it, or implement some more sophisticated 
QNAME/IP/time window rate-limits.

Cheers,
Phil



More information about the bind-users mailing list