[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: caching dns lookups
On Thu, Aug 30, 2001, Tzafrir Cohen wrote about "Re: caching dns lookups":
> On Thu, 30 Aug 2001, Nadav Har'El wrote:
> > You seem to be only measuring resolve times in your browser. But if you're
> > using a (non-transparent) HTTP proxy, your browser actually has no business
> > resolving the domain name! It passes the unresolved domain name to the proxy,
> > and it is up to the proxy to resolve these domain names! So if thisis the
> > case (e.g., if you're connected to the technion you *must* be using a proxy),
> > your name server cannot have anything to do with the speed of domain name
> > resolution on a web browser, and installing a local named won't make one
> > iota of difference- only fixing the name server on the proxy can make a
> > difference.
>
> Yes, it does.
>
> wget http://www.technion.ac.il/proxy.pac and see exactly what netscape
> checks before even contacting the proxy.
Generally, without a fancy proxy.pac ("pac"=proxy auto configuration) file
my original statement was true. Netscape, and any other browser that I know of,
pass the given URL directly to the configured proxy (again, I'm not talking
about a transparent proxy which doesn't need to be configured). No attempts
to resolve the domain name are done first.
There is a simple way to verify this, and that what I originally said
was correct when you don't use a fancy proxy.pac:
Put an alias "hello" to 64.58.76.224 (an IP address for yahoo.com) in
your /etc/hosts. People who are forced to use proxies should use something
inside their area, e.g., you can use 132.68.7.11 which is www.technion).
Now, without a proxy, surf to http://hello/. This works, of course.
Now set up a proxy, and try to surf to http://hello/. It won't work.
Why? because the proxy gets the verbatim "http://hello/", and doesn't
know how to resolve this "hello". The way your own computer can
resolve "hello" means diddly-squat to the proxy - hence there is no
reason for your browser to do such a resolution, which only slows
everything down.
But now, returning to your comment about the specifics of the Technion's
automatic proxy configuration (I don't know if Dan is using it), you
have a good point! I don't know if Dan is using it, but if he is this
might explain some (but not all) of the slowness he's seeing.
First, I'd like to point the interested readers to the authoritative reference
on Netscape's proxy autoconfiguration, which you can find in
http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
Here's an interesting excerpt from that page:
"* Use of isInNet(), isResolvable() and dnsResolve() functions should
be carefully considered, as they require DNS server to be consulted
(whereas all other autoconfig related functions are mere string
matching functions). If a proxy is used, the proxy will perform its
own DNS lookup which would double the impact on the DNS server. Most
of the time these functions are not necessary to achieve the desired
result."
So, reading http://www.technion.ac.il/proxy.pac I see that indeed it calls
isInNet. This unfortunately really adds another DNS query penalty to your
browser, and in my opinion it is a mistake to leave it this way. But it
shouldn't be that bad if you have a close and quick nameserver... Just in
case, Dan, if you're using proxy.pac, could you please configure Netscape to
use a fixed proxy, and see if there is any difference in performance?
--
Nadav Har'El | Friday, Aug 31 2001, 12 Elul 5761
nyh@math.technion.ac.il |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Lumber Cartel member #2224.
http://nadav.harel.org.il |http://come.to/the.lumber.cartel
=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il