I'm more of a stackoverflow.com guy, but am running into something interesting. I'm developing an application which is going to be managed once it is published (hoping sometime early next year)...
My goal was to have http://domain.com as the brochureware site, and have http://client.domain.com/ as the host that the client logs into. The hope being that 1 client to 1 database, instead of all clients into a single database. makes scaling lightyears easier.. need to scale more, throw a few more servers into the farm.
From my extensive research, the best methods to do this happen to be using some sort of nameserver to host the "hosts", and then setup an iis box that can read the headers and pass it to the app, which can control the database connections, etc.
I was wondering... I know i can use WMI to programmatically control nameservers if everything is windows based, but is this the best method? Am I going to run into a ton of headaches? can someone suggest a decent configuration that can be used to handle this better? I'm bootstrapping the software, so I've got limited resources to get it off of the ground.
Thx.
Why not use www.domain.com as the brochureware site and instead go with www.domain.com/client as the individual customer sites?
When you start using SSL this will avoid the cost of a wildcard certificate, etc and gets you out of the DNS business.
PowerDNS can use a database backend to store your zone information. In that case, all you'd need to do to add a subdomain is just insert a row into the database. It supports a myriad of database backends. Needless to say, a SQL insert is dead-simple to achieve programatically.
I'll caution you, though...hosting DNS isn't for the faint of heart. You'd do yourself well to do a lot of reading, research, and testing on your servers before putting them into production. As such, I'd highly recommend you consider using a third-party DNS service for this. There are many that have open APIs you can use to manage the DNS entries for your zone. DNSmadeeasy and Dyndns are two that come to mind that allow API access. These companies make their money hosting DNS. They know what they're doing, and they're relatively cheap. Why expose yourself to the risk and time loss of hosting DNS yourself when you have the option to outsource it?
Running a simple DNS setup is really not very difficult. I would, however, second ErikA's suggestion to do some serious research (DNS & Bind by O'Reilly is always a good start) before trying to run it yourself.
I would definitely say it's worth doing yourseif if you:
Personally, I've been running bind with multiple views for about 8 years and had very good success with it. Recently, I've started looking at PowerDNS with a mysql backend and poweradmin for management to try to reduce the learning curve of my backup person. It seems very snappy and straightforward once it's setup.
The process is called "transparent redirection" or Virtual Hosting. Which simply means you will be connected to a different website depending on which URL is being asked for in the HTTP header.
It's trivial in Apache. And possible in IIS see: http://www.simpledns.com/kb.aspx?kbid=1149
The client.domain.com and client2.domain.com require 2 DNS entries, so each URL will need a new entry. You'll have to manage those for each client.
Another way to do it is as a subfolder instead though rather than another virtual host. That would mean no extra DNS entries. A real advantage.
e.g. www.domain.com/client and www.domain.com/client2
You can point each subfolder at a different site for each client and therefore a different set of data. I'm not sure whether IIS will let you transparently proxy that to another server or not but you could put a load balancing server in front of your web server to farm the requests out to different servers. Either way, it's all very possible and not that difficult.
The simplest way to do this would simply be to use a Wildcard entry, and then have the web server sort out the requests?
Set up a DNS record for
*.example.com
, and then using IIS (I assume), bind your brochure site toexample.com
andwww.example.com
, and then map your applications one by one to the other sites (client1.example.com, client2.example.com) etc.This way you're only managing the IIS bindings, not the DNS as well, and because the wildcard is the lowest ranked match for a DNS entry, if you need to create an A or CName record for something else (say,
support.example.com
), the wildcard will rank lower than this record.