Search squid archive

Re: DNS timeouts - unable to reduce timeout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



DNS lookups are done by the resolver.
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.

Try "time nslookup -debug -d2 83.231.150.45" and see what
your nameserver is doing.

Marcus

Nick Cairncross wrote:
Don't know if it's if use but could dnsmasq speed this up?


On 19 Nov 2010, at 19:41, "declanw@xxxxxxxxxxxx" <declanw@xxxxxxxxxxxx> 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




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux