On Mon, 25 Feb 2008, Henrik Nordström wrote: > > sön 2008-02-24 klockan 03:54 +1100 skrev Tim Connors: > > I am having trouble on two machines on two completely different networks, > > both using squid -- for months now, a reasonably portion of the time, > > squid fails to get through to google.com.au for the first minute. A > > tcpdump revealed that it was failing when trying to contact the same > > 72.14.203.104 host. After a minute, squid would try the next host in the > > cached DNS result. Since both machines have 4 addresses in their cached > > result of google.com.au, and both included 72.14.203.104, one in 4 > > searches would take a minute to get a result. > > And google set the TTL of their DNS response to only 5 minute so after 5 > minutes Squid's memory of the bad IP is gone.. Odd. Something has gone wrong with the TTL on 2 seperate DNS servers then. I shall look into this... > > In the event that a hostname resolves to n>1 IPs, and one or more of them > > m<=n-1 are timing out (or connection refused and certain other error > > conditions), I think squid should cache this result for a configurable > > time (of the order of days or until a restart, or until DNS has > > refreshed its list of IPs for that host), and then not try that IP > > again until it has exhausted its supply of IPs corresponding to this name. > > It caches the bad status until the DNS entry expires or a user forces a > reload. So it's already meant to be doing this (by caching bad status, I presume you mean it doesn't keep trying that ip?)? Is that perhaps in the 3.x branch? One host that has this wrong is an ancient distribution with 2.5.STABLE14 on it (sigh), but the other is a 2.6.18-1+b1 in debian's versioning scheme. -- Tim Connors
