An IIS binding uses the following shorthand notation.

<protocol> <IP address>:<port>:<host name>

For example, the site binding for http://www.web.com could look like this.

http 66.129.79.227:80:www.web.com


In order for IIS to transfer a page request to a site all conditions in one of the site binding(s) must be met.  If no binding is found you get the dreaded 404 error.

Binding shorthand translates directly to how the IIS Manager handles bindings.   Add Site Binding window for the IIS7 IIS Manager.  You will notice there is a Type (protocol), IP address, Port and Host name slot that can be used to create a binding.  While binding shorthand is used for examples in this article they can easily be translated to the Add Site Binding format with a little practice.




Binding rules

The binding rules can be summarized like this:

1. Find all bindings with a matching protocol.

2. Filter by port.

3. Try to match the requested domain name to a host name.

4. Match by IP address.

The rules on how each element in the bindings is configured and matched requires a more detailed discussion.

The protocol, or binding type, and port are always required in a binding and have a rigid set of rules, but the other fields offer some flexibility.  The protocol must always be an IIS recognized protocol type, such as http, https, ftp, etc. and the port must always be an integer (whole number) from 0 to 65535.  Be careful of the port you use as the ORCS Web perimeter firewall will block all incoming non-standard ports unless a custom firewall rule is applied.  The IP address has a little more flexibility in the form of a wildcard, which, for IIS, is an asterisk (*).

When an asterisk is used instead of an IP address the binding will apply to the site if the other three binding conditions are met.  In the IIS binding drop-down the wildcard option is called “All Unassigned” .  Be careful when using an IP address wildcard as a similar binding with an actual IP address will take precedence over the wildcard.  The host name, or domain name, field is the only part of the binding that is optional in the UI and provides the greatest flexibility.

Host names, or host headers as they were called in IIS6, allow you to serve many sites from a single IP address.  It is common to see a dedicated server with a single IP address host a dozen individual sites through the use of host names.  When a host name is used, however, IIS will only pass the request if the exact domain name entered matches the host name exactly – where the domain name is the part between “://” and the first “/”, i.e. in http://www.web.com/blog the domain name is www.web.com.  This domain name to host name matching is not case-sensitive, only character sensitive.

When using host names it is important that you to analyze how clients may type in your domain name and create a host header binding for each scenario you wish to support.  For example, if you have a domain, web.com, that shares an IP address with other sites on a server you will want to create two bindings; one binding for web.com and a second binding for www.web.com.  The binding shorthand for the above example would look like this.

http *:80:web.com

http *:80:www.web.com

Value of the Domain name is sent in 'Host' Header.

When only a single site uses an IP address it is not necessary to use host names at all.  If there is no host name IIS will disregards the domain name all together and assigns the request based on protocol, IP and port; however, if a different site has a matching host name the request will go there instead.  A matching host name, even with a wildcard IP, will take priority over an IP address with no host name binding.

http 66.129.79.227:80:

http *:80:www.web.com [this binding will have priority over the above binding if the requested domain name is www.web.com]

The shortest possible binding is reserved for servers with a single IP and site, or if you wish to have a “catch-all” site when no other binding fits.  This binding, which uses the IP wildcard and no host header, would be applied absolutely last when no other binding match could be found.  In this case the binding will simply be:

http *:80:

One final rule for bindings, you should not use the same binding twice on a server.  Each binding on a server must be unique or IIS will be unable to determine where to send the request. If you do manage to add duplicate bindings, and there are a couple of ways to do it, one of the sites will be stopped by IIS. You will be unable to start both sites until the binding conflict is removed. The IIS Manager will give you a warning if you try to enter a duplicate binding so there is little to worry about, but it is something you should be aware of, especially when working with secure sites.

If you use IIS6, or do not have access to IIS Manager for an IIS7 site, you are welcome to send the ORCS Web support team any binding setup requests you may need.  While you do not have to put the request into binding shorthand, this article should provide you with the knowledge needed to decide what sort of bindings your site(s) may need.

Secure site bindings


When setting up a secure site, one that uses an SSL certificate to encrypt the data stream, all of the binding rules from above are still valid but there are special circumstances that must be taken into account.  The primary factor behind this stems from rule number one of secure site bindings: no IP address sharing is allowed unless you have a wildcard certificate or use a non-standard port.  A traditional secure site binding will look something like this:

https 66.129.79.227:443:

While some sites and blogs show workarounds that allow multiple secure sites per IP we highly discourage this unsupported behavior.  Modifying the configuration files to break rule #1 will cause all modern web browsers to throw certificate errors when entering your secure site, and that is not only a bad practice but could discourage customers from using your site.

Secure sites are bound to port 443 by default.  It is only on very rare occasion that this port number should be changed.  Corporations with perimeter firewalls almost always keep port 443 open for secure browsing and then block all non-standard ports.  While changing the https port from 443 will allow you to host multiple secure sites on a single IP address you first, add difficulty for the customer who needs to remember adding a port to your domain name (i.e. www.web.com:4443) and second, you run the risk of being blocked by corporate firewalls.

This port paradox is the primary reason why you generally need one IP per secure site per server since the bindings on a server must be unique and without host headers there is only one possible binding combination on the standard port. Unless you are designing a secure site for a very specific set of users you should not us a non-standard secure port.

A quick word of caution about wildcard certificates and https bindings: if the certificate Name does not include "*." before the domain name IIS7 will not allow you to use https host names through the UI. Even if the certificate "issued to" contains *.domainname.com it will not work.  There are ways to get it working through the command line or by directly modifying the binding in applicationHost.config so there is no concern for alarm if the wildcard certificate name does not contain "*.".



When requesting, or setting up, a secure site binding the only information needed is the site, the IP address and which certificate to use.  If you have a wildcard certificate, i.e. *.web.com, then a host header value can be assigned as well.  For information on how to obtain an SSL certificate please refer to this KB article.

Link: https://support.cartika.com/portal/en/kb/articles/intro-to-iis-binding