Re: Ranting on ipcache bogosity

oskar@is.co.za writes:

>Eric Wieling wrote:
>
>(Hi Duane - Are we off on a tangent? Should I take a long hard look at the
>source? Should I just bugger off? ;)

There seems to be some misconceptions around, let me try to clear
things up a little.

The dnsservers do not cache addresses. They are simply loops around
gethostbyname() and now also gethostbyaddr() for v1.1.

The IP caching occurs in the squid process. The IP cache is hashed
by hostname. Web objects are hashed by URLs and is very separate.
One important reason for the IP cache is just that Squid ends up
looking up the IP address numerous times for one request.

In my opinion there are two things which need to be fixed in
the IP cache. We need to rotate through all addresses for a host.
This should only occur after a connect() call. We need to disable
an IP address if a connect() fails.

If somebody wants to write a new dnsserver which uses res_query()
instead of gethostbyname() please do. Then we could pass back the real
TTL info from the DNS.

Duane W.

>I have removed the general mailing list from this to keep the friends that
>I have ;) Maybe we need a "developers" list and an announce list -
>If I were only interested in announcements, I would have unsubscribed
>a while ago...
>
>Basically the main question is as follows:
>When squid connects, and downloads a page, and saves it to a directory,
>does it index the directories by URL or by IP?
>
>> The Netscape way of load blanacing would be a problem. However, the
>> only problem I can see with the "correct" way of doing things is
>> making sure that Squid stores the host name associated with the oject
>> is actually a host name, rather than an IP address. Of course, that
>> would require additional DNS lookups at various places.
>Hmm - There shouldn't be a problem with this, assuming that:
>They have set up squid so that it will talk to a local DNS server
>to resolve names.
>That DNS server is set up to recurse - so that it will cache the
>actual returned values, not refer it to a remote server.
>
>My thinking is that (we for example) do most of our access through
>a satellite link, which increases send/ack times substantially,
>and each DNS lookup that refers to a machine as squid's major DNS,
>would have a large turnaround time. On a slow link, this could
>be up to 2 seconds - 2 seconds before the cache even returns an answer...
>(No, that's not how long our lookups take! ;)
>
>(This is why all of our access lists are based on IP addresses, not on
>domain name, especially since so many IP's don't have reverse addresses!
>
>Oskar
>
>>
>> Some time ago Oskar Pearson said:
>> > What about the following too:
>> >
>> > When multiple dns entries are returned, cache them all identically,
>> > my reasoning is as follows - when the new version of Netscape came out,
>> > they had a random load balancing system to keep their servers sane.
>> >
>> > BUT - they had about 20 servers, so, while one of our users downloaded
>> > netscape from ftp1, 19 other people were downloading it from the
>> > other servers... This problem can only get worse :(
>> >
>> > Fixing this is going to be hard to implement because:
>> > Netscape does it's load balancing in a strange way: they set a very
>> > low TTL on their records, and then rotate their records on their
>> > name server. (ie - if you find out the address for ftp.netscape.com now,
>> > it may give you two records, but if you do it five minutes later, you
>> > will get a different address...
>> >
>> > You could (I suppose) get it to cache all DNS requests for something like
>> > 24 hours :) (Evil grin ;) and only re-lookup if you issue a reload command
.
>> >
>> > (Yes I know that there are all sorts of bad points about not following
>> > RFC's reguarding DNS lookups etc, but please don't flame me!)
>> >
>> > On the other hand, something like www.microsoft.com works on a much
>> > easier system to cache:
>> > When you ask for www.microsoft.com, it returns 16 different IP addresses..
.
>> >
>> > It seems that squid would store the files with an algorithm based on
>> > the IP address?
>>
>> [snip]
>>
>> --
>> Eric Wieling
>> Advanced Network Research
>> InterCommerce Corporation
>> Pager: 800-758-3680
>>
>> The world needs no help seeing a fool for what they are.
>>
>

Duane W.
Received on Wed Aug 21 1996 - 07:54:12 MDT