We would like to offer a free trial to customers of our SaaS product. So, customers will put the desired sub-domain name while signing up and they will get a site like clientname.ourmainsite.com for free trial. We don’t want to manually setup a sub-domain for each customer. After research I came to know this can be achieved by setting up “wildcard” DNS record for ourmainsite.com, so we need to add a *. ourmainsite.com entry in DNS of ourmainsite.com pointing to our server.

But this seems to point all sub-domains to a single a site which is opposite to our current setup where each client domain has a separate website setup in IIS like client1.com, client2.com, etc. How this option of using single website for multiple domains sounds as compared to separate site for each domain? What are the pros/cons of this approach specially cons? Which option is more secured? Which option uses less resources like memory on server?

My main concern is in current setup we can have separate app pools for each site. But if we go with the approach of “wildcard” DNS record where all domains are pointed to a single site then what will happen if some site is attacked or having huge traffic slowing down other sites on server then how this can be controlled or monitored as we won’t be able to set separate app pool for each domain? Are there any alternatives to this? I have read that many SaaS companies follow the “wildcard” DNS approach. So how do they handle loading or attack on some specific site? Or do they use “wildcard” DNS approach only for trial sites to setup a virtual sub-domain like client1.ourmainsite.com and after trial create separate site in IIS for their domain like client1.com?

1 Answer
1

If you don't want to be setting up individual sites you can have *.mydomain.com go to a specific IP address of your IIS server and you would need a catchall binding on a single site on that server so it would know to listen for an unknown name. This sounds convenient but it's a terrible idea. Don't do it.

It sounds like you are going to need to create a site for each subdomain and put that client's specific subdomain in the binding, and create an application pool for each site to keep them separate.

If you're going to have a lot of these, I suggest putting PowerShell to use to help you automate the creation of sites, content directories and application pool settings as part of your onboarding workflow.

If you have concerns about one site getting hammered and taking all the other sites down with it, you could establish CPU throttling rules on the Advanced Settings of the application pool to prevent that. This is not possible if you have all the traffic going to a single site.

One alternative to this approach is to set up load balancing of some kind (I use AWS Application Load balancers) to direct incoming requests to a specific target group based on host or path. Then the target group has health checks in place to keep an eye of the status of the instances in the target group. Then cloudwatch events can see an unhealthy instance and fire off a lambda function which spins up another instance added to that target group. You can still use IIS under the hood as your web server but AWS offers additional ways to scale it out on demand. This is just the AWS example but I'm sure the same could be done with Azure or GCP.

Currently we cant implement AWS/Azure and we have limited options. It seems I have 2 options: single website for all domains using wildcard dns or separate site for each domain in IIS(current approach). Now, my main concern is which option is better. Does second option gives any benefits over the first or vice-versa. If separate site for each domain option is good then should we just use wildcard dns option to setup sub-domains for trial signups and use "separate site for each domain" option for client's main domains which are used after free trial?
– web developerOct 30 '18 at 19:18

I would use the wildcard DNS to direct *.yourdomain.com to the IP address of your IIS server. You will need to have at least one site on IIS that listens for * on that IP. Make that site show a blank page or whatever custom message you want people to see when they hit a non-existent site. Then set up individual sites for each of your tenants with each site having its own app pool. You may want to set up a default throttling policy at the server level that way you won't need to set it up for each individual site you create. From there, automate the site creation as much as possible.
– LifeSizeActionFigureOct 31 '18 at 0:32