Silamael wrote:
>
> Amos Jeffries wrote:
>> ...
>> anything resolving to 127.0.0.1 on this host is not necessarily
>> resolving to 127.0.0.1 on any other host (ie the parent proxy)
>>
>> NP: having a DNS server resolve 127.0.0.1 for anything public is very
>> nasty.
>
> Hi Amos,
>
> Thank you for your help. Meanwhile i did some more testing and found
> something strange. The test system cannot resolve any internet domains
> itself so its nameserver uses a forwarder. If i silently drop the DNS
> request packets through the packet filter, everything works fine. There
> is no delay on any requests.
> But, if i just remove the forwarder in DNS, so that every request for
> external domains result in a NXDOMAIN DNS reply, a request takes about
> 90 seconds until it's finally processed.
> The point i don't understand is, why Squid forwards the request without
> any DNS reply but seems to do some timeout handling if NXDOMAIN is replied?
> I also checked if there is any communcation between local squid and the
> parent proxy but there isn't any in the latter test case.
>
> Greetings,
> Matthias
That seems very strange. Very strange.
Squid using internal DNS resolver sends out UDP packets and waits for a
reply positive or negative. Using that.
The NXDOMAIN results make sense if we assume they come back with some
TTL so short Squid needs to run through the DNS timeouts on every request.
The silent drop case is a head scratcher of a puzzle. That is the one
that should be getting very long timeouts while Squid waits for a reply
that will never arrive.
Anyway, getting rid of the "dst" ACL and making sure the peer is
configured with an IP address should prevent any DNS lookups.
IIRC your config already has the log_fqdn setting turned off.
Amos
-- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19 Current Beta Squid 3.1.0.13Received on Mon Sep 21 2009 - 11:34:07 MDT
This archive was generated by hypermail 2.2.0 : Mon Sep 21 2009 - 12:00:02 MDT