Re: Summary - Will browsers support multiple proxy servers

Bernhard.Schneck@physik.tu-muenchen.de wrote:
# 
#  > [... about what to do when the primary proxy server fails ...]
#  
# What's wrong with putting two A records in the DNS?

If you think about this, it will not do what you really want it to.

# 
# I didn't check the source of any WWW browser, but I hope they'd cope
# with multi-homed servers.  If a request to one address times out, they
# should automagically switch to the secondary address ...
 
It's not the WWW browser that's doing the name resolution.  This is
strictly a DNS issue.

# 
# 	% setenv http_proxy http://http-proxy/
# 	% www
# 
# DNS zone file:
# 
# 	server1		IN A 1.2.3.4
# 	server2		IN A 1.2.3.5
# 
# 	http-proxy	IN A 1.2.3.4
# 			IN A 1.2.3.5
# 
# This should also distribute the load between the two servers, as newer
# nameserver implementations (at least BIND) shuffle the addresses.  Of
# course, both servers will have different caches, which is suboptimal,
# but I don't think this will hurt too much.
 
The problem with this is that if the name server returns the first
A record, and that is the server that's down, it will NOT automagically
'switch' to the other server until the cache times out.  Also, even
after the cache times out, you are not guaranteed that you will resolve
the server that is up.  

The key here is that each server needs to be it's own primary server.
Therefore, if the server is down, no DNS info can be given out, thus
queries will be sent to the server that is up.  Also, since it needs to
be its own primary server, the hostname (usually www) is actually a
sub-domain.  Therefore, if you have two servers at www.foobar.com, you
must setup www as a subdomain of foobar so that it can become a primary
server to achieve the effect stated above.  To see what I have done, see
the DNS records for www.wdc.com. 

This has been up for a couple months, and it works great.  Of course
this can be done not just for WWW, but ftp and other resources that you
wish to load-balance or mirror. 

Also, if anyone sees any faults as to what I have implemented or commented 
on above, please let me know.

# 
# \Bernhard.
# 
# 

Regards.
-- 
Andy Kumeda -- Consultant              Voice:  714.449.8327
InteleNet Communications, Inc.         E-mail: andy@intelenet.net
30 Executive Park, Suite 265           P-mail: andy.pager@intelenet.net
Irvine, CA  92714-6741                 URL:    http://www.intelenet.net

Received on Friday, 30 June 1995 11:53:23 UTC