sortlist Questions

[Kevin Darcy]

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 
works fine.

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" 
download site.

>	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 
a pain.


                                                                         
                                    - Kevin