IIS 7 and Above
“wildcard” DNS vs Separate Websites
Last post Jul 09, 2019 06:31 PM by Chris Becke
Oct 30, 2018 02:34 PM|garybenson|LINK
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?
Oct 30, 2018 04:02 PM|lextm|LINK
Wildcard DNS means that traffic for all subdomains goes to a single IP address. However, that does not mean you ought to handle the incoming requests using "a single site". I believe most SaaS providers are smart enough to associate that IP address with
a reverse proxy, which in turn forwards requests based on their Host headers to different back end infrastructure (servers/sites), so as to distribute the load in a healthy way.
Your questions above like "pros/cons" are only viable if we completely rip reverse proxying out of the image, which is not practically at all.
Oct 30, 2018 06:52 PM|garybenson|LINK
Thanks for the info.
However, that does not mean you ought to handle the incoming requests using "a single site".
I don't want to manually setup a sub-domain for each trial signup. Then, how can I handle sub-domains of trial signups?
Also, We are using a Windows dedicated server and would like to keep all sites on a single server until client sites grow as we are offering our software for a very little monthly price. What are the best options for this scenario? It seems I have 2 options:
single website for all domains using wildcard dns or separate site for each domain in IIS. Now, my main concern is which option is better. Does second option gives any benefits over the first or vice-versa.
Oct 31, 2018 01:35 AM|lextm|LINK
I wrote an article for another purpose, https://blog.lextudio.com/wildcard-host-name-support-in-old-iis-releases-8e4448040b5a
but it does reveal a typical reverse proxy usage. Hope it gives you some hints on what is reverse proxy and how rules can be used to distribute loads based on their host headers.
Jul 09, 2019 06:31 PM|Chris Becke|LINK
This is an old question but there are some issues worth addressing:
The wildcard DNS entry is going to map *.example.com to an IP address, not a site which will allow traffic to reach your IIS server.
On that server you can create many sites: one for each customer, each with its own binding. E.g. Site1 with binding http://site1.example.com:80 which will then handle that traffic.
Or you could install and use Application Request Routing to rewrite hostnames to direct traffic to other servers if you need to start partitioning customer traffic.
Also note that in IIS7 and up a site can have multiple applications and each application can have its own application pool.
So you can still use application pools to control resources to individual applications. You can even use sites as as a high level security assignment by assigning a single site to a customer, rather than creating multiple sites if they wanted multiple sub
domains they simply deploy to sub applications within their site (each with its won app pool) and you use ARR to rewrite external links of the form http://app.example-site.com to the needed form on the server: http://example-site.com/app