Configuring DNS records
Starting with DNS, the simplest DNS configuration is as follows:
| Type | Name | Content |
|---|---|---|
| A | domain.com | 1.2.3.4 |
| A | * | 1.2.3.4 |
This sets the IP address for domain.com and adds a wild card entry pointing to the same IP address. The wildcard covers any subdomain including e.g. www, mail, test, beta etc. The only time you would add separate subdomain entries is if you wanted them to point to another IP address.
Website Bindings
The above configuration will send all requests for a domain, and its subdomains to the configured IP address. IIS configuration determines how HTTP requests are handled. First you need a site, and then you need to configure HTTP bindings. When creating a site, you typically need to give it a name, specify where on disk the site files are located and then add a default binding, which consists of the (sub)domain that the site listens for. Usually, you will add two bindings: one for the domain, and one for the www subdomain. Both of these will use the http protocol (the Type). By default, these will be configured to listen for requests on port 80.
Leave the IP address as All Unassigned, You would only select an IP address if the server has multiple IP addresses and you want to ensure the site is bound to one in particular (e.g. in a shared hosting environment).
Certificate Management
Once you have configured the DNS record and the initial bindings, you can use WinAcme to generate TLS certificates for each binding. This process will result in additional https binding being added to the website for each domain that you add a certificate for.
Multiple Sites, Single Codebase
When you have a single codebase serving multiple sites, you can either create a separate website for each site, or you can create one website and add multiple HTTP bindings to it.
When you create a new website in IIS, it gets its own application pool. This is a dedicated process for the website application. You cannot create multiple application pools for one website, so if you configure one site with multiple bindings, all those bindings will affect each other. They will share app pool resources such as memory and they will share problems such as app pool recycles or crashes. Generally, the multi-site model is best served by creating separate websites for each domain and pointing to the same code base.