On 1/08/2012 7:16 p.m., James Harper wrote:
On 1/08/2012 6:01 p.m., Dmitry Melekhov wrote:
Hello!
I switched to 3.HEAD-20120627-r12185 from 2.6 two days ago and now I
see in log something like:
2012/08/01 08:25:48 kid1| Failed to select source for
'http://izavia.su/favicon.ico'
2012/08/01 08:25:48 kid1| always_direct = DENIED
2012/08/01 08:25:48 kid1| never_direct = DENIED
2012/08/01 08:25:48 kid1| timedout = 0
2012/08/01 08:28:47 kid1| Failure Ratio at 1.017
2012/08/01 08:28:47 kid1| Going into hit-only-mode for 5 minutes...
Yes, this is situation described in FAQ, but this is just wrong url-
user mistake, not DNS or connectivity problem.
Is there any way to avoid this?
It *is* a DNS problem. Out of *all* recent requests 101 out of the last
102 requests failed to resolve or did resolve and TCP conection to them
failed. Regardless of the reason being users pounding your Squid at high
speed with non-existent URLs or connectivity being down - you have a
problem outside of Squid to fix.
So just to get this straight... my users could DoS my squid by sending lots of requests for invalid dns entries? In what versions does this exploit exist?
"users" in this case are other proxies requesting ICP lookups. Squid
"HIT-only mode" is where ICP protocol responsds with ICP_MISS_NOFETCH to
prevent this proxy being used as a cache_peer by a downstream
client/user proxy unless the request can actually be served from the
local cache. The mode is also used automatically during startup while
the cache_dir are being loaded. It only affects ICP responses, not HTTP
requests delivered there by other cache selection methods or direct clients.
So no, its not that easy. For downstream clients to create a DoS you
must be using a multi-teir proxy hierarchy with ICP as the *only*
selection mechanism between the proxies, AND the gateway proxy
configured with never_direct to blocking DNS from being used as a backup
by the gateway proxy.
Which makes me notice, it can be ignored completely for proxies with
icp_port disabled.
Amos
