kcd at daimlerchrysler.com
Tue Nov 30 00:05:37 UTC 2004
Martin McCormick wrote:
> We want clients on our remote campuses to be able to locally
>download software which we have purchased. Last year, I asked about
>using sortlist so that a person querying from Campus A would get a
>server's address on Network A, first. I was told by someone on this
>list that that is not a good strategy because a query might come from
>the wrong place, causing a client to get the wrong site server first.
>I appear to have lost the actual message explaining why this is a bad
>idea, but I understand why it is.
Well, I frankly don't understand the skepticism, from how you have
described the problem set so far. In what way is the query going to come
from the wrong place? Sortlists are a bit of a pain to manage -- since
you need to maintain the same sorting definitions on all of your
nameservers -- but when properly managed, perform as advertised. We're
using sortlists here so that the same name can be used for a resource
that exists in more than a dozen different locations, with clients at
each location connecting to their local instance of that resource. Other
than the aforementioned sorting-definition maintenance problems, it
Also, even if there was some sort of problem with the sortlisting, would
it be a disaster if the occasional client pulled from the "wrong"
server? This is a showstopper for some apps, but merely
bandwidth-unfriendly for others.
> Could name-based hosting be used by web servers to determine
>where a customer is so that he or she will get a link that resolves to
>a server which is on their local network?
I don't see how name-based hosting can help here. I'd be more likely to
say that a smart app(let) on the web server, which looks at the source
IP of the connecting client and customizes links accordingly, might be
one viable alternative to sortlists. This assumes, of course, that your
clients are connecting directly to the web server, or if you use HTTP
proxies, the proxies are local enough to the clients that the app(let)
can make a good decision about how to point them to their "closest"
> As I understand it, bind is not a good place to try to
>determine which IP address a customer needs based upon the query
>address. The web site in question has to be on a public network and
>should determine whether a customer is calling in from one of our
>networks in which case he gets a link to a local server, or he is
>calling in from a network that isn't ours and he gets the main site
>server that is best able to handle the load.
Hmm... That adds another wrinkle to the problem. The web server is on a
public network, but are all of the clients configured to use your
nameservers for resolution? If not, then forget about using sortlists
exclusively, since if the clients are using nameservers not under your
control, you can't completely determine the order in which the address
list is handed out to them. In this case, you could use "view"s instead,
or some combination of "view"s and sortlists (e.g. a classic "internal"
versus "external" view, with a sortlist in the internal view) but that
means having to maintain some of the same data in parallel, which can be
More information about the bind-users