Amos Jeffries wrote
> ==> ORIGINAL_DST is should *only* ever be used on MISS or
> REFRESH/revalidate traffic. Never on a HIT. Thus zero (0%) hit-ratio is
> the expected behaviour.
>
> For the same reason that a report of the log traffic using "grep -v HIT"
> will show zero cache ratio.
I have des
On 09/11/2016 10:23 AM, Amos Jeffries wrote:
> The only visible problem is why that 2% exists.
>
> ==> ORIGINAL_DST is should *only* ever be used on MISS or
> REFRESH/revalidate traffic. Never on a HIT. Thus zero (0%) hit-ratio is
> the expected behaviour.
It is possible that a terminology clash
On 12/09/2016 3:04 a.m., Omid Kosari wrote:
>
> I refer to following messages .i have same problem
>
The "problem" is misunderstanding of the log entry meaning.
>
> FredT wrote
>> Hi Amos,
>>
>> We have done additional tests in production with ISPs and the ORIGINAL_DST
>> in tproxy cannot be c
Antony Stone wrote
> On Thursday 08 September 2016 at 12:27:42, Omid Kosari wrote:
>
>> Hi Fred,
>>
>> Same problem here . Do you found any solution or workaround ?
>
> Please clarify which message you are reply / referring to.
>
> Thanks,
>
>
> Antony.
>
> --
> Archaeologists have found a
On Thursday 08 September 2016 at 12:27:42, Omid Kosari wrote:
> Hi Fred,
>
> Same problem here . Do you found any solution or workaround ?
Please clarify which message you are reply / referring to.
Thanks,
Antony.
--
Archaeologists have found a previously-unknown dinosaur which seems to hav
Hi Fred,
Same problem here . Do you found any solution or workaround ?
Regards
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/TProxy-and-client-dst-passthru-tp4670189p4679422.html
Sent from the Squid - Users mailing list archive at Nabble.com.
On 4/07/2015 8:02 p.m., Stakres wrote:
> Hi Amos,
>
> We did tons of tests with the latest Squid versions and this is not the
> behaviour with the "host_verify_strict off" and "client_dst_passthru off".
> With those 2 options OFF, we see a lot of ORIGINAL_DST that we should not
> see if we follow
Hi Amos,
We did tons of tests with the latest Squid versions and this is not the
behaviour with the "host_verify_strict off" and "client_dst_passthru off".
With those 2 options OFF, we see a lot of ORIGINAL_DST that we should not
see if we follow your explainations, so it seems there is a bug some
On 4/07/2015 3:21 a.m., Stakres wrote:
> Amos,
> OK, got your points.
>
> What I don't understand is:
> - The dns records do not match. Squid does the dns request by itself,
Reverse those two.
> downloads the object,
... from the ORIGINAL_DST (*not* its own DNS lookup)
> delivers it to the cli
Amos,
OK, got your points.
What I don't understand is:
- The dns records do not match. Squid does the dns request by itself,
downloads the object, delivers it to the client and flags with an
ORIGINAL_DST, right ?
- Same request from another client, same way, it'll be the same object and
flagged OR
On 4/07/2015 1:21 a.m., Stakres wrote:
> Amos,
> You told the Squid will check the original dns from the headers, then it'll
> do its own dns resolution to verify they both match.
> So, if no match, Squid does the request to internet based on the dns it
> found.
> If I'm right, that the current way
Amos,
You told the Squid will check the original dns from the headers, then it'll
do its own dns resolution to verify they both match.
So, if no match, Squid does the request to internet based on the dns it
found.
If I'm right, that the current way, correct ?
What we could do is the same way but a
On 4/07/2015 12:05 a.m., Stakres wrote:
> Hi Amos,
> Can we expect a workaround to allow the object to the cache if the dns
> record is corrected by Squid instead that having an ORIGINAL_DST ?
> If Squid corrects the request, it mean the URL will be good, so we should be
> able to cache the object
Hi Amos,
Can we expect a workaround to allow the object to the cache if the dns
record is corrected by Squid instead that having an ORIGINAL_DST ?
If Squid corrects the request, it mean the URL will be good, so we should be
able to cache the object
Fred
--
View this message in context:
http:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Fred,
I'm talkin not about localhost installation.
My squid serves business-center. With hundreds of users.
In this environment, we use also transparent DNS interception onto DNS
cache. DNS cache itself uses clean sources for resolving, using dn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Fred,
I'm talkin not about localhost installation.
My squid serves business-center. With hundreds of users.
In this environment, we use also transparent DNS interception onto DNS
cache. DNS cache itself uses clean sources for resolving, using dn
Hi Yury,
In your installation, with your devices... At home, I do the same like you,
but I'm not an ISP.
Here the issue is that end users could use different dns the ISPs cannot
control.
Home/Entreprise, the admin can control the used DNS servers with devices. In
an ISP environment, we cannot con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In my installation I use caching DNS (unbound) in conjunction with Squid.
This cachind DNS directly on squid box and solves many problem with DNS.
Unbound cache itself uses custom TTL setting (maximal) for DNS records,
which is overrides provider
Hi Amos,
"/You can get around it somewhat by having the ISP resolvers use each other
same as proxy chains do./"
This is impossible to do in a multi-level ISPs archi, because each ISP could
use any DNS servers (google, level3, etc...). From the original end user to
the latest ISP step the dns heade
On 2/07/2015 11:05 p.m., Stakres wrote:
> Hi Amos,
>
> 216.58.220.36 != www.google.com ???
> Have a look: http://www.ip-adress.com/whois/216.58.220.36, this is google.
www.google.com did not resolve to 216.58.220.36 when Squid checked.
Otherwise caching would have been allowed and ORIGINAL_DST
Hi Amos,
216.58.220.36 != www.google.com ???
Have a look: http://www.ip-adress.com/whois/216.58.220.36, this is google.
Depending the DNS server used, the IP can change, we know that especialy due
to BGP.
In the case the client is an ISP providing internet to smaller ISPs with
different DNS wit
On 2/07/2015 6:32 p.m., Stakres wrote:
> Hi,
>
> I'm back to this post because it still does not work.
> You explain "OFF - Squid selects a (possibly new, or not) IP to be used as
> the
> server (logs DIRECT).", sorry to say this is not the reality in the Squid.
> We have set the pass-thru directi
Hi,
I'm back to this post because it still does not work.
You explain "OFF - Squid selects a (possibly new, or not) IP to be used as
the
server (logs DIRECT).", sorry to say this is not the reality in the Squid.
We have set the pass-thru directive to OFF and here is the result:
TCP_MISS/206 72540
Hi Amos,
We have done additional tests in production with ISPs and the ORIGINAL_DST
in tproxy cannot be cached.
In normal mode (not tproxy), ORIGINAL_DST can be cached, no problem.
But once in tproxy (http_port 3128 tproxy), no way, it's impossible to get
TCP_HIT.
We have played with the client_d
On 4/03/2015 8:19 p.m., Stakres wrote:
> Hi Eliezer,
>
> Well, we have done many tests with Squid (3.1 to 3.5.x), disabling
> "client_dst_passthru" (off) will stop the DNS entry as explained in the
> wiki, the option directly acts on the flag "ORIGINAL_DST".
You literally have that backwards.
Th
Hi Eliezer,
Well, we have done many tests with Squid (3.1 to 3.5.x), disabling
"client_dst_passthru" (off) will stop the DNS entry as explained in the
wiki, the option directly acts on the flag "ORIGINAL_DST".
As you know, ORIGINAL_DST switches the optimization off (ex: StoreID) then
it's not poss
Hey Fred,
It is unclear what doesn't work for you.
What would you expect to work and how it works or doesn't work from a
user perspective rather then an admin?
Is there any trouble from the user side about this issue?
Eliezer
On 04/03/2015 00:14, Stakres wrote:
Hi All,
Does someone know why
Hi All,
Does someone know why the "*client_dst_passthru*" does not work in TProxy
mode ?
From the Squid wiki, we can read that:
"/Regardless of this option setting, when dealing with intercepted
traffic Squid will verify the Host: header and any traffic which
fails Host verification will be treat
28 matches
Mail list logo
