On 17 Sep 2003 09:34:39 -0700, in <alt.privacy.spyware>, yosponge@yahoo.com
(sponge) wrote:
>
> On Wed, 17 Sep 2003 15:19:13 GMT, "YoKenny" <YKnot@home.invalid>
> wrote:
>
> >sponge wrote:
>
> >> HOSTS will likely slow you down. The files out there today are
> about
> >> 450k in size, so if you visit a webpage with a dozen off-site
> images
> >> and scripts, you'll be going through 5.4 megabytes worth of DNS
> >> lookups. That'll slow things down.
> >
> >How do you come up with that figure? DNS lookup are very small
> packets
> >and if the site is in the HOSTS file then nothing leaves the PC.
>
> It's not the packet size that's the problem. It's the lookups
> themselves.
>
[snip]

But that's just it... If a given machine has an entry in in the local HOSTS
file, then there is *no* DNS lookup for that hostname, ever.

> Take a look at Yahoo's homepage, for example. It will load images, ads
> and scripts from a number of different sites. Let's say,
> ad.doubleclick.net, us.i1.yimg.com, rd.yahoo.com,
> adfarm.mediaplex.com, images.x10.com, and a few others.
>
> If none of these in your HOSTS list, then that means your browser's
> DNS resolver has to search through the entire list for each domain
> name before allowing it to pass.
[snip]

True, but that's much MUCH faster than doing a DNS lookup, at least
presuming a semi-modern and properly configured system.

> Of
> course, some of these actually are on the HOSTS file blocklist, so the
> time will be shorter depending on the location of the entries withing
> HOSTS.
[snip]

It will be shorter, period -- you *do* have your system's disk caching set
up halfway sanely, don't you? (For that matter, at least some versions of
Windows might explicitly hold the HOSTS data in memory anyway... not sure of
this one, but it stands to reason.)

> Even then, though, that's usually still quite substantial since
> most entries won't be near the top of the list.
>
[snip]

Actually, for an even number of entries in the HOSTS file (and ignoring
comment lines), exactly 50% will be nearer to the top of the list than to
the bottom. And vice versa. ;-) (For an odd number of entries, one will
be exactly in the middle.)

> If the looked-up names are cached afterwards, then the lookup time
> will shorten in subsequent uses, but that will only happen on the
> names being sought and caches do expire. The whole HOSTS file isn't
> cached: you'd overflow your cache a couple times over if it tried.
>
[snip]

You are correct that the browser only "remembers" the addresses of those
hostnames it actually looks for; but this has nothing to do with
"overflow[ing] your cache". Most browsers will use a dedicated buffer for
this data, not the "cache". OTOH, if "Browser X" does store this data in
the main cache, you then need only adjust the cache settings within your
browser, if they are inadequate; you said earlier that most of the commonly
distributed HOSTS files are ~450K -- that is *nothing* compared to what any
semi-modern browser is capable of caching.

Having said all this, I would be remiss if I failed to note that the HOSTS
file is really the wrong place to do wholesale blocking (and a perversion of
its intended purpose, for that matter), for several reasons. First, it is
_at_best_ inherently only "half the answer", since the HOSTS file can *only*
influence where your system goes to *ask* for data from certain named
machines; it *cannot* do anthing about data transfers initiated from outside
the local machine. Secondly, and even ignoring the foregoing, the HOSTS
file is a horridly inefficient and labor-intensive way to block entire
networks, subnets and domains, simply because it cannot support entries like
<*.doubleclick.net> -- you need a separate entry for each and every host in
that domain, which means you first must *know* each and every host in that
domain. Got any idea how many entries that would be, *just* to cover
DoubleClick? Phooey! It's FAR easier to just plug:

63.160.54.0./24
63.166.98.0./24
63.168.198.0/25
65.167.64.0./22
128.11.60.64/26
128.11.92.0./24
146.82.220.0./23
198.31.62.0./23
204.178.112.160/27
204.253.104.0./23
206.65.181.96/28
206.65.183.0./24
208.10.202.0./24
208.32.211.0./24
216.73.80.0/20

into your external router/firewall's DENY table, and be done with it.

--

Jay T. Blocksom
--------------------------------
Appropriate Technology, Inc.
usenet01[at]appropriate-tech.net


"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: E-Mail address in "From:" line is INVALID! Remove +SPAMBLOCK to mail.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Unsolicited advertising sent to this E-Mail address is expressly prohibited
under USC Title 47, Section 227. Violators are subject to charge of up to
$1,500 per incident or treble actual costs, whichever is greater.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -