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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
