Re: [squid-users] DNS timeouts - unable to reduce timeout

On Sun, 21 Nov 2010 16:07:28 +0000, declan wrote:
> On Sun, Nov 21, 2010 at 11:18:02AM -0200, Marcus Kool wrote:
>> DNS lookups are done by the resolver.
>
> They are done by the (libc) resolver if the program use the resolver
API.
> Squid does not use the resolver API, so it does not use this resolver.

Both right. luckily Marcus did not say which resolver ;)

The resolver in question being the recursive nameserver(s) which Squid
uses to offload the recursion and DNSSEC parts of DNS. They can be
configured with anything needed.

>
>> Options on Linux can be set in /etc/resolv.conf (see also man
>> resolv.conf).
>> The default timeout is only 5 seconds and any program, including Squid,
>> that does a nameserver query should get an answer (including an error)
>> in 5 seconds.
>> In my case I have 3 nameservers in /etc/resolv.conf and the total
>> timeout is 15 seconds.
>
> Squid looks in the resolv.conf for the list of nameservers if you didn't
> tell it any. That's all it uses the file for. As I understand it, the
> rest is ignored.

Depends on your Squid. nameserver, ndots, domain and search path are all
used by the current releases unless the squid.conf contains contrary
settings which overrides them.
Your 3.1.9 will use everything appropriate that it can find.

>
> Squid cannot use the standard resolver API as it blocks, and Squid
cannot
> hang around waiting for an answer like that, so it slings its own raw
DNS
> packets and does other work while waiting for any returning packets.
>
>> Try "time nslookup -debug -d2 83.231.150.45" and see what
>> your nameserver is doing.
>
> The problem is not the nameserver - the problem is the client waiting so
> long
> for the answer that it defeats its primary purpose of proxying.
>
> I don't know how 'dns_timeout' isn't solving this, but a real-world test
> doesn't lie.

This is the strange part. With the early 3.1.x release squid used double.
dns_timeout for each of AAAA and A lookups. The 3.1.9 is supposed to
account for both packets inside the timeout. And yes, Squid is supposed to
drop the line of lookup and move on to another server at dns_timeout.

While one of these requests is hung you could run "squidclient mgr:idns"
to get a view of what the DNS queue thinks of the query state.

Amos

>
>> Marcus
>>
>> Nick Cairncross wrote:
>> >Don't know if it's if use but could dnsmasq speed this up?
>
> No. By definition an internet web proxy has raw internet access, so it
> has no use for NAT or masquerading when doing its own DNS lookups.
>
> DW
>

>> >
>> >On 19 Nov 2010, at 19:41, "declanw_at_is.bbc.co.uk"
<declanw_at_is.bbc.co.uk>
>> >wrote:
>> >
>> >>Hullo.
>> >>
>> >>I have a squid 3.1.9, which has an acl that needs to know the DNS
>> >>domain
>> >>name of a target IP (yes, I know it slows things down, but it has to
>> >>stay)
>> >>
>> >>I have a lot of users viewing Flash streams hosted by Akamai, but
>> >>Akamai's
>> >>reverse DNS servers for e.g. 83.231.150.45 are currently completely
>> >>dead.
>> >>
>> >>Squid is taking 90 seconds to give up on the reverse DNS lookup for
>> >>http://83.231.150.45/fcs/ident2 and proceed with making the
connection.
>> >>Unfortunately, the Flash Player only seems to wait 30 seconds before
it
>> >>declares the content stream broken.
>> >>
>> >>I cannot find a setting to make squid timeout DNS faster.
>> >>I have tried increasing 'negative_dns_ttl', but it didn't seem to
have
>> >>any effect.
>> >>'dns_timeout 10 seconds' had no effect either, which suprised me.
>> >>
>> >>The only DNS option I am using is 'dns_nameservers 127.0.0.1' which
>> >>points
>> >>at a caching BIND. I am not using an external DNS resolver.
>> >>
>> >>Confused.
>> >>
>> >>DW
>> >
>> >The information contained in this e-mail is of a confidential nature
>> >and
>> >is intended only for the addressee. If you are not the intended
>> >addressee, any disclosure, copying or distribution by you is
prohibited
>> >and may be unlawful. Disclosure to any party other than the
addressee,
>> >whether inadvertent or otherwise, is not intended to waive privilege
or
>> >confidentiality. Internet communications are not secure and therefore

>> >Conde Nast does not accept legal responsibility for the contents of
>> >this
>> >message. Any views or opinions expressed are those of the author.
>> >
>> >The Conde Nast Publications Ltd (No. 226900), Vogue House, Hanover
>> >Square,
>> >London W1S 1JU
>> >
>> >
Received on Mon Nov 22 2010 - 01:07:20 MST