sortlist Questions

Jonathan de Boyne Pollard J.deBoynePollard at Tesco.NET
Fri Dec 10 04:41:55 UTC 2004

M> a query might come from the wrong place, causing a client to get the
M> wrong site server first.



M> The web site in question has to be on a public network and should
M> determine whether a customer is calling in from one of our networks
M> in which case he gets a link to a local server, or he is calling in
M> from a network that isn't ours and he gets the main site server that
M> is best able to handle the load.

This can be tackled in one of two ways.  As you describe, it can be 
tackled with logic in the content HTTP server itself, deciding what to 
do (publish a redirection or publish the content) based upon the IP 
address of the HTTP client.  Another way is to use a mandatory proxy 
HTTP server within your organisation (a proxy HTTP server that everyone 
is instructed to use, *not* an interception proxy HTTP server, note), 
and have that proxy configured with overrides so that it fetches the 
relevant objects from different, internal, content HTTP servers rather 
than from the public ones.

M> I basically need arguments to share as to why DNS isn't built to make
M> this sort of address selection [...]

The simplest argument is that *this* *isn't* "address selection" *at* 
*all*.  It's selection of content HTTP servers.  It has nothing to do 
with picking IP addresses, and everything to do with having web browsers 
receive different content HTTP service according to where those web 
browsers happen to be located.  It's simple "split horizon" HTTP 
service, and it is done for HTTP in the same ways that "split horizon" 
DNS service is done for DNS: Either have overrides in the proxy server 
and two sets of content servers, or have a content server that serves 
different data according to its perception of the "location" of the client.


The analogy between HTTP and DNS works both ways.


Of course, this has nothing whatever to do with ISC's BIND.  It doesn't 
even involve mucking around with your DNS service at all.

More information about the bind-users mailing list