On 6/09/2016 9:14 p.m., Omid Kosari wrote: > It is tproxy cache . Is there a way to force caching them . No, and trying to do so is a VERY bad idea. I cannot stress enough how bad it is. Allowing remote attackers to completely (and invisibly) bypass almost all other security measures you might have in your network, just for starters. I fully realise that not being able to cache a fairly large chunk of CDN hosted traffic is extremely annoying and also can be costly. But the risks of this particular vulnerability outweight that price tag. > current configs: > host_verify_strict off > client_dst_passthru on > > dns_nameservers x.y.160.172 > dns_nameservers 217.218.155.155 > dns_nameservers 217.218.127.127 > dns_nameservers 8.8.8.8 > dns_nameservers 8.8.4.4 > dns_nameservers 208.67.222.222 > dns_nameservers 208.67.220.220 > dns_nameservers 208.67.222.220 > dns_nameservers 208.67.220.222 > > The first dns server is our caching dns server and its parents dns servers > are the others which appears in this config . Users dns traffic intercepted > to x.y.160.172 . > > So the problem seems the cdn dns round-robin . Is there a way to solve that > ? Use only that first DNS server in your squid.conf. Using it as an aggregation point reduces the impact, but only if it is also the sole point of resolving for Squid. NP: this is not a fix, just a workaround to reduce impact until Squid DNS system can be updated to do things better. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
