Within an IIS worker process, separate sites (i.e. domains) run in their own app domain.

I have a site example.com which has a wildcard DNS record (i.e. *.example.com pointed to an IP.) Will processing for a subdomain resource z.example.com be isolated into a separate appdomain from handling of requests for www.abc.com? I think the answer must be yes, but can't find anything definitive

1 Answer 1


No. I run several sites like this. The binding determines which app takes the requests, and each app can only have one app pool. An app pool can use multiple processes (a web garden) but that is completely unrelated to wildcard domain names (even a single domain gets split across multiple processes in this scenario).

An app domain (a security construct within .Net) isolates applications from each other. Each application only gets one app domain per process, regardless of how many domains bind to it. Even without wildcard DNS, if two completely separate domains are bound to the same application, such as www.abc.com and foo.xyz.net, they are both handled by the same app domain in the same app in the same process(es) in the same app pool.

Here's an overview of how an incoming request is handled by IIS (ignoring ISAPI filters, URL rewriting, etc.), gleaned from 15 years of research and experience dealing with two large multi-domain applications on IIS 5-8.5:

  1. The IP address and port number of the incoming request (comes from the network interface) check to see if there is an SSL(TLS) certificate bound to the port. If so, SSL(TLS) negotiation begins. This happens before IIS ever sees the request, as this part is handled by the operating system itself. Newer versions of TLS may allow the hostname (which is sent in the headers of an HTTP or HTTPS request) to be sniffed so that different certificates can be used for the encryption, even on the same IP address and port. The IIS management interface makes the configuration of certificates appear as if they are part of IIS, but it's not.

  2. Next, IIS receives the HTTP or HTTPS request from the operating system. IIS looks at the bindings for every site (sometimes also referred to as Website by IIS tools) and finds all the ones whose IP address and port match. If there is more than one, chooses the one with a matching hostname (using the Host header in the request, which the browser populates with the hostname from the URL). The hostname cannot contain wildcards, the IIS management interface will not allow them (even though you can set them using command-line tools, they probably don't work they way you think they do anyway, so it's best to avoid them for now). The IIS management interface will not let you create more than one binding with the same information (though the command-line tools sometimes let stuff like this slip by, and the results are undefined). A site is really just an organizational construct in IIS. Like a binding, it has configuration information, but there is no code directly associated with a site--the path specified in the site configuration is really the path for the default application within the site.

  3. Now that the site has been determined, IIS must decide which application to send the request to. When a site is created, a default application is also created for the site. IIS first checks for any non-default applications in the site. Each of those applications will be uniquely identified by a path (the default application has no path, or has the "root" path). If the path matches what's at the beginning of the incoming URL, that application is selected, and the most specific (deepest) matching site is selected. If no non-default application matches, the default application is selected.

  4. Now that the application has been determined, IIS must handle the request directly or somehow route the request to the application. If the request is for a static file and you don't have system.webServer/modules/@runAllManagedModulesForAllRequests="true" set in the web.config for the application, IIS (or perhaps ASP.NET within IIS) just returns the file contents with the appropriate content type. If the request is not for a static file (or you've set the web.config to route all requests through your code), IIS looks to see which Application Pool (or AppPool as the command-line tools refer to it) the site is configured to use. It then forwards the request to your application code in a randomly (or perhaps round-robin) selected process from the "web garden" for that Application Pool. The default web garden only has one process. (IIS itself doesn't ever use the term "web garden", but it is used in blog posts by IIS team members--See the "Maximum Worker Processes" setting in Application Pool settings--this is what controls how many processes are in the garden).

  5. Within the process in the web garden, each site lives in its own AppDomain (this is a .NET term referring to a sandbox within a .NET process, although it is often misused to mean an IIS 'Site', and the term 'application domain' is also sometimes used for this, though I've never seen this term used in the IIS management interface or in the command-line tools). Because of how AppDomains work, each instance of the site (each in a different process in the web garden) gets its own static variables. Your site code is free to create more AppDomains as needed, but that's up to you. IIS only creates one in each web garden (Application Pool) process. Technically, the 'World Wide Web' service probably hands the request to the Application Pool process (w3wp.exe) and that process determines the site and AppDomain to pass the request to, but that's an implementation detail that is hidden by IIS, as both the 'World Wide Web' service and the w3wp.exe process are part of IIS. W3wp could examine the headers at this point to see which hostname was specified and call a different AppDomain for each unique hostname at that point, but it doesn't--that would just slow things down. The request may not even have a hostname, as it could have come in with just an IP address.

  6. Once we get to this point, the ASP.NET application life cycle takes over, but that's irrelevant to your question.

Notice that as your request goes through this process, different hostnames may cause them to go to separate AppDomains in separate applications, but they won't go to separate AppDomains in the same application, unless you specifically write code yourself to create those AppDomains and route the requests there.

  • Thanks James, but in this case all subdomains are bound to and handled by the same site and app pool.
    – Matt Evans
    Dec 3, 2014 at 9:23
  • Yes, I understood that, so the answer to your question is no. All your requests will be handled by the same app pool.
    – James
    Dec 3, 2014 at 13:17
  • And within the app pool, will there be an appdomain for each sub domain?
    – Matt Evans
    Dec 3, 2014 at 14:09
  • 1
    No. There is an app domain for each application handled by a process, but in this situation, you only have one application, so there is only one app domain. This is generally what is wanted because it means that static variables and caching are shared across sub domains.
    – James
    Dec 3, 2014 at 14:52
  • Well that's funny that you mention statics and caching, because when I consolidated all subdomain traffic to www using an url rewrite rule, we saw our server side performance improve dramatically, and our main search procedure RPM fall a lot. The only explanation i could come up with was separate app domains (and caches) being created, per sub domain. Can you point me to any documentation on this? Would really like to understand this behaviour better
    – Matt Evans
    Dec 4, 2014 at 6:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.