Re: DNS lookup failures

From: Chris Fedde <cfedde@dont-contact.us>
Date: Sat, 10 Aug 1996 12:10:19 -0600

In message <199608100902.KAA17547@bourbon.pl.vtcom.fr>you write:
>> Subject: DNS lookup failures
>> From: Chris Fedde <cfedde@keota.uswmedia.com>
>
>
>> I'm thinking about ripping out the whole ipcache system and replacing
>> it with a simple call to gethostbyname.
>
>That would simply blow up the Squid proxy ! The ipcache system implements
>a _non-blocking_ name<->ip resolution mechanism, but gethostbyname is a
>blocking call ! Remember that Squid is a single-process program ... ;-)
>

Um. I guess that I was a bit violent in my statement about "ripping
out" the ipcache system. I was a bit frustrated with what I perceive
as unnecessary complexity in the address resolution mechanism. I
can see some advantage to the method by which squid manages resolver
queries through the external servers. The first resolver query
may indeed take several seconds to respond. So perhaps some startup
performance is gained through this mechanism. I do not see any
advantage to the current implementation of the ipcache.

My primary argument is with the internal data-structure maintained
by routines in ipcache.c. Based only on behavioral testing, including
packet traces I assert that squid only makes use of the first ip
address returned from dnsserver. Further, squid refreshes the
cache infrequently. If squid stays up for a long period of time
the ipcache becomes stale.

I suggest that a better approach would be to make use of the
dnsservers for every name query. Thus taking advantage of the
cache maintained by named. I believe that it would be impossible
for squid to do a better job of caching IP addresses than BIND
already does.

It is unfortunate that the standard resolver api does not support
an asynchronous interface. So a pair of routines that interface
with the dnsservers and the select loop might be the best approach.

chris
Received on Sat Aug 10 1996 - 11:12:24 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:46 MST