When squid is started, the following might appear in cache.log:
Configuring Parent www-cache.demon.co.uk/8080/3130
WARNING: DNS lookup for 'www-cache.demon.co.uk' failed!
From this point on the cache is dead in the water. It can also put itself
into this state at any time, apparently if a dns lookup takes longer than
it would like. A client trying to access the web while squid is in this
state continually receives a page similar to the following:
The requested URL could not be retrieved
========================================
While trying to retrieve the URL: http://www.google.com/
The following error was encountered:
Unable to determine IP address from host name for www.google.com
The dnsserver returned:
Server Failure: The name server was unable to process this query
This means that:
The cache was not able to resolve the hostname presented in the URL.
Check if the address is correct.
Your cache administrator is ...
========================================
The trouble is that squid never seems to recover from this situation, even
though if it attempted the dns lookup again it would probably work ok.
The whole web is unavailable to any clients using the cache, and the only
way out is to restart squid. I have tried playing around with
configuration options for both squid and bind, but have not found any
combination that works satisfactorily.
So I guess my question is: Is it possible to configure squid (or bind) to
be more tolerant of this kind of situation?
resolv.conf
-----------
nameserver 127.0.0.1
options timeout:120
squid.conf
----------
http_port 8080
cache_peer www-cache.demon.co.uk parent 8080 3130 no-query default
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 21 443 563 70 210 1025-65535
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
acl local_clients src 192.168.0.0/255.255.0.0
http_access allow local_clients
http_access deny all
icp_access allow local_clients
icp_access deny all
miss_access allow all
cache_mgr webm...@troika.net
append_domain .troika.net
acl local_servers dstdomain .troika.net
acl demon_servers dstdomain .demon.net www.demon.co.uk ftp.demon.co.uk
always_direct allow local_servers
always_direct allow demon_servers
never_direct allow all
--
Bob Firth <fi...@troika.demon.co.uk>
Troika International
1 Little Mount Sion, Tunbridge Wells, Kent TN1 1YS, UK
Phone: +44-1892-543373 Fax: +44-1892-545585
and delete (if it is the first entry)
nameserver localhost || nameserver localhost
cu
--
cu@all Mounteverest
Sie haben den Mauszeiger bewegt! Möchten sie Windows jetzt neustarten um die
Änderungen wirksam zu machen?
This is Linux-Country. In a quiet night you can hear Windows reboot.
nameserver localhost || nameserver 127.0.0.1
cu
I think you may be being bitten by DNS timeout, not the squid-dns timeout
which you can control. You can lengthen the timeout a bit and make your
system a little more tolerant by
a) running a caching name server
this way your more frequently used info will be in the loacl dns
cache
b) setting up your name server to forward to your ISPs server
put a forwarders line with your ISP's server(s) in there severaL
times, eg (bind 8 syntax)
forwarders {
1.2.3.4
1.2.4.8
1.2.3.4
1.2.4.8
};
forward only;
This way when the first server doesn't answer in time your dns
will query the next one and so on. You might be able to stretch
the timeout to long enough for one of them to answer.
c) don't start squid if the link isn't up
On Mon, 25 Jun 2001, Bob Firth wrote:
> I am running squid-2.3.STABLE1-5 on a Linux server (RH6.2), with a dialup
> link (56k modem) controlled by diald. The link takes 30-40 seconds to
> come up, occasionally longer if the first attempt fails for some reason.
> The link is typically brought up by a dns lookup, and at busy times this
> can take considerably longer on top of the connect time. Squid does not
> seem to be very tolerant of dns taking such a long time.
Colin