Home/ Questions/Q 113589
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T02:43:34+00:00

Most solutions I’ve read here for supporting subdomain-per-user at the DNS level are to

  • 0

Most solutions I’ve read here for supporting subdomain-per-user at the DNS level are to point everything to one IP using *.domain.com.

It is an easy and simple solution, but what if I want to point first 1000 registered users to serverA, and next 1000 registered users to serverB? This is the preferred solution for us to keep our cost down in software and hardware for clustering.

alt text http://learn.iis.net/file.axd?i=1101 (diagram quoted from MS IIS site)

The most logical solution seems to have 1 x A-record per subdomain in Zone Datafiles. BIND doesn’t seem to have any size limit on the Zone Datafiles, only restricted to memory available.

However, my team is worried about the latency of getting the new subdoamin up and ready, since creating a new subdomain consist of inserting a new A-record & restarting DNS server.

Is performance of restarting DNS server something we should worry about?

Thank you in advance.

UPDATE:

Seems like most of you suggest me to use a reverse proxy setup instead:

alt text http://learn.iis.net/file.axd?i=1102

(ARR is IIS7’s reverse proxy solution)

However, here are the CONS I can see:

  1. single point of failure
  2. cannot strategically setup servers in different locations based on IP geolocation.
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. The front-end proxy with a wild-card DNS entry really is the way to go with this. It’s how big sites like LiveJournal work.

    Note that this is not just a TCP layer load-balancer – there are plenty of solutions that’ll examine the host part of the URL to figure out which back-end server to forward the query too. You can easily do it with Apache running on a low-spec server with suitable configuration.

    The proxy ensures that each user’s session always goes to the right back-end server and most any session handling methods will just keep on working.

    Also the proxy needn’t be a single point of failure. It’s perfectly possible and pretty easy to run two or more front-end proxies in a redundant configuration (to avoid failure) or even to have them share the load (to avoid stress).

    I’d also second John Sheehan’s suggestion that the application just look at the left-hand part of the URL to determine which user’s content to display.

    If using Apache for the back-end, see this post too for info about how to configure it.

    • 0