Let’s make sure our servers are directing web traffic properly with some basic IIS Bindings rules and practices.
While IIS is a powerful tool for hosting sites on Microsoft Servers, we will only be going over the “easy” stuff in this article. However, it’s safe to say that before you perform an operation that requires you to edit the web.config file for a site, you may want to check IIS first since it will typically provide a GUI to do the same thing. Without further ado, let’s dive right in.
IIS or ‘Internet Information Services’ is a set of services for servers using Microsoft’s operating system.
Many versions of IIS exist, but if you are working on a server today, you’ll typically be using 6.0, 7.0, 7.5, 8.0, or 8.5. You can run more than one version on a server at a time as well, (such as both 6.0 and 7.0). The differences between 6.0 and the other versions are quite vast, (how they handle code and features), while 7.0, 7.5, 8.0, and 8.5 are similar, (although the later versions offer a few more features). The main purpose for this service is to house, administrate, configure and operate on your sites.
What is an IIS Binding?
A IIS binding is simply a mechanism that “binds” to your site and tells the server how this site can be reached. An IIS Binding is simply a binding that lives in IIS. When we talk about IIS Bindings, we are talking about this part of IIS:
As you can see, it’s aptly named.
Why are IIS Bindings Important?
Because we need them to direct the traffic sent to the server to the appropriate site. In other words, DNS will direct traffic to your server, and then bindings take over to get that traffic to the appropriate site by using the sites’ binding.
The primary rule for bindings is that when you have multiple bindings, each must differ in some way. We have three binding options in which to do this with. They are Port, IP Address, and Host Header. When working with multiple sites, no site can have the same Port, IP Address, and Host Header as another; they must differ on at least one of these criteria.
How do IIS Bindings Work?
So when a request hits the server, the first thing it looks for is Port. The two most common Ports are port 80 (HTTP) and 443 (HTTPS). That being said, it’s not uncommon to have multiple sites using either Port.
The next item that a request considers is IP Address. This can really go either way. If you have plenty of static IP Addresses to use, then it’s best practice to have a unique IP Address for each site. However, you can use the same IP Address for multiple sites if you are paying per IP.
So, what happens when you share the same Port and IP Address? You must differentiate by Host Header, (aka Host name). This name must match the request exactly. So, if you are trying to reach a site by www.test.com, then you must have www.test.com as the Host Header. Want to access by Test.com? Then you must have Test.com in the Host Header. Sites may have multiple Host Headers to compensate for CNAMES/Alias’ or sites that are accessed by different names.
*On a side note, when you’re ordering an SSL be careful of the name you choose. It must be accessed by exactly that name (unless it’s a wildcard certificate). You can use IIS Redirects to “force” requests into appropriate bindings, but I will cover that in detail in another post.
Proper Planning Makes IIS Bindings Successful
This is the “very” basic essence of bindings. While seemingly simple, this can become a major pain point when dealing with many sites if proper planning and/or documentation is not utilized. If you cannot get a site to start without it automatically stopping another, then you have a binding conflict that you must address. Proper planning will avoid this issue altogether, so keep these rules in mind when planning your environment.