On Mon, 13 Jul 1998, Henrik Nordstrom wrote:
> You should do new DNS query if all known IP numbers are bad. Manual
> action should not be required when a host changes address.
The way it's currently working, there is no manual action *required*
-- if all the addresses remain bad for the entire span of the ipcache
time-to-live value, default of six hours, then the host will be
dropped and a new DNS lookup will take place. If you want a new
lookup to take place sooner than that, then the purge could be used.
The problem with doing a new DNS lookup each time all addresses are
bad, with the way the IP cache is currently set up, is illustrated by
the following scenario:
1. Host with 14 addresses becomes unreachable due to router problem.
2. Next request for this host results in all addresses marked bad,
and entry is dropped from cache.
3. Next request results in new DNS lookup, with all 14 addresses
marked as "OK".
4. All 14 addresses are retried again, all marked bad, and entry is
dropped.
5. Repeat step 3-4 for all requests for that host until it becomes
available again or a valid set of addreses is returned.
As you can see, this has the potential to turn into a really
degenerate case, yeilding a lot of DNS lookups and connection attempts
thrashing against an unavailable host. If several hosts fall into
this state at once, it could develop into a real big mess. Can you
think of other state information that we could store with the host
that could avoid this kind of case?
The only time I've run into a need for immedate refreshing of a host's
address is when a locally-controlled webserver switched service
providers, and in that instance I simply restarted Squid. The <2%
miss-rate of a RETRY_PATCH-enabled IP cache is a significant benefit
that may make it worth the default six hour positive_dns_ttl wait for
it to recognize an address change automatically.
-Mike Pelletier.
Received on Tue Jul 29 2003 - 13:15:51 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:49 MST