On 29/04/11 22:02, Jannis Kafkoulas wrote:
Unfortunately I couldn't find any directives in squid.conf relating to any dns
matter.
But I have an idea why squid has to set up a nslookup:
We use also ip addresses with acls for destinations.
So if squid receives an URL name it has to get it resolved first in order to be
able to check it against the ip address acl.
Um, that would be one of those DNS ACLs you just said you couldn't find.
So probably we can only do without nslookup if we don't use any ip addresses.
Does anyone know that?
"src" IP address is given by TCP and fine to check.
"dst" IP address requires DNS lookups.
----- Ursprüngliche Mail ----
Von: Amos Jeffries
On 29/04/11 01:56, Jannis Kafkoulas wrote:
Of cource Eliezer, thanks a lot!
Yes, of course, I mean dns lookup by resolve.
(It has been set up by an external company)
The chain is very simple, just one after the other:
clients (FF) ---> Squid1 (LAN) ----> Squid2 (somewhere in between) --->
Squid3
(at the Internet)
This chain is being used by the users when accessing the Internet.
It's the same behaviour for any possible URL.
I took just a rare one so I could find it easily in the tcpdump output.
I just checked the squid1 and squid 3 (squid 2 same as squid1).
Squid one contacts the internal dns server which forwards to the root
servers.
But the dns answer to the query is not given to the next proxy in the chain,
so
it's then useless.
The squid 3 accesses the dns root servers directly and then it forwards the
http
request to the final server.
The problem might be that the squid 1 also is being used for internal "direct
access", i.e without a parent.
My question is now, is it possible for the squid to decide when to use a dns
lookup?
Yes. DNS "should" not be needed until the stage of setting up the DIRECT
TCP connection. It sounds like squid1 has some ACLs or such which are
testing DNS things about the request. Find and avoid those and DNS will
go away on the chained requests.
Amos
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.7 and 3.1.12.1
