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