They’re probably matching about 40% of the time on twitter.com, though 😒
> On 25 Nov 2015, at 11:40 AM, Dan Charlesworth wrote:
>
> Alright, thanks for the hint.
>
> My proxy and clients definitely have the same DNS server (I removed the
> secondary and tertiary ones to make totally sure) but
Alright, thanks for the hint.
My proxy and clients definitely have the same DNS server (I removed the
secondary and tertiary ones to make totally sure) but the results definitely
aren’t matching 99% of the time. Probably more like 90%.
Perhaps it’s 'cause my clients are caching records locally
On 25/11/2015 12:20 p.m., Dan Charlesworth wrote:
> Thanks for the perspective on this, folks.
>
> Going back to the technical stuff—and this isn’t really a squid thing—but is
> there any way I can minimise this using my DNS server?
>
> Can I force my local DNS to only ever return 1 address fro
Thanks for the perspective on this, folks.
Going back to the technical stuff—and this isn’t really a squid thing—but is
there any way I can minimise this using my DNS server?
Can I force my local DNS to only ever return 1 address from the pool on a
hostname I’m having trouble with?
> On 30 Oc
On 10/29/2015 11:29 AM, Matus UHLAR - fantomas wrote:
>> On 10/28/2015 10:46 PM, Amos Jeffries wrote:
>>> NP: these problems do not exist for forward proxies. Only for traffic
>>> hijacking interceptor proxies.
>
> On 29.10.15 09:05, Alex Rousskov wrote:
>> For intercepted connections, Squid shoul
On 10/28/2015 10:46 PM, Amos Jeffries wrote:
NP: these problems do not exist for forward proxies. Only for traffic
hijacking interceptor proxies.
On 29.10.15 09:05, Alex Rousskov wrote:
For intercepted connections, Squid should, with an admin permission,
connect to the intended IP address with
On 10/28/2015 10:46 PM, Amos Jeffries wrote:
> NP: these problems do not exist for forward proxies. Only for traffic
> hijacking interceptor proxies.
For intercepted connections, Squid should, with an admin permission,
connect to the intended IP address without validating whether that IP
address
This is happening when my client and proxy are using the same DNS server. In
this case, a local OS X Server which forwards to my ISP’s DNS servers.
As far as I can tell Google’s DNS isn’t in the equation any more. Even so, if I
run a `dig watch` on the domain, it happily cycles through a pool of
On 29/10/2015 1:16 p.m., Dan Charlesworth wrote:
> It looks like there’s certain hosts that are designed to load balance (or
> something) between a few IPs, regardless of geography.
>
> For example pbs.twimg.com resolves to wildcard.twimg.com which returns two
> different IPs each time, from a p
It looks like there’s certain hosts that are designed to load balance (or
something) between a few IPs, regardless of geography.
For example pbs.twimg.com resolves to wildcard.twimg.com which returns two
different IPs each time, from a pool of 5–6, at random. Basically rolling the
dice whether
22.10.15 15:58, Amos Jeffries пишет:
On 21/10/2015 4:53 p.m., Dan Charlesworth wrote:
I’m getting these very frequently for api.github.com and github.com
I’m using the same DNS servers as my intercepting squid 3.5.10 proxy and they
only return the one IP when I do an nslookup as well …
Any
Ah-ha. Thanks for digging into that a bit Amos.
In my case 8.8.8.8 is the tertiary server, so I’m surprised it’s being used at
all. Could be a local DNS server is forwarding to it, though.
I’ll remove that from the equation tomorrow and see how it fares.
Cheers
> On 22 Oct 2015, at 8:58 PM, Am
On 21/10/2015 4:53 p.m., Dan Charlesworth wrote:
> I’m getting these very frequently for api.github.com and github.com
>
> I’m using the same DNS servers as my intercepting squid 3.5.10 proxy and they
> only return the one IP when I do an nslookup as well …
>
> Any updates from your end, Roel?
I’m getting these very frequently for api.github.com and github.com
I’m using the same DNS servers as my intercepting squid 3.5.10 proxy and they
only return the one IP when I do an nslookup as well …
Any updates from your end, Roel?
> On 8 Oct 2015, at 8:29 PM, Eliezer Croitoru wrote:
>
> Si
Since they are using the same dns server there is no need to run some
trials.
The only test you should in any case test is to see how long is the IP
list from the DNS request for the domain name.
Eliezer
On 08/10/2015 12:12, Roel van Meer wrote:
Eliezer Croitoru writes:
Are the users and pr
Eliezer Croitoru writes:
Are the users and proxy using different dns server?
No, they are using the same server.
Can you run dig from the proxy on this domain and dump the content to verify
that the ip is indeed there?
I'm currently running with 3.5.8 again, so I'll have to find a quiet h
Hey,
Are the users and proxy using different dns server?
Can you run dig from the proxy on this domain and dump the content to
verify that the ip is indeed there?
Eliezer
On 06/10/2015 14:55, Roel van Meer wrote:
Hi everyone,
I have a Squid setup on a linux box with transparent interception
On 8/10/2015 6:41 p.m., Dan Charlesworth wrote:
> Same here—I've been meaning to ask the list about this too. I’m still on
> 3.5.9, by the way.
>
>> On 6 Oct 2015, at 10:55 PM, Roel van Meer wrote:
>>
>> Hi everyone,
>>
>> I have a Squid setup on a linux box with transparent interception of both
Same here—I've been meaning to ask the list about this too. I’m still on 3.5.9,
by the way.
> On 6 Oct 2015, at 10:55 PM, Roel van Meer wrote:
>
> Hi everyone,
>
> I have a Squid setup on a linux box with transparent interception of both
> http and https traffic. Everything worked fine with S
Hi everyone,
I have a Squid setup on a linux box with transparent interception of both
http and https traffic. Everything worked fine with Squid 3.5.6. After
upgrading to version 3.5.10, I get many warnings about host header forgery:
SECURITY ALERT: Host header forgery detected on local=10
20 matches
Mail list logo
