IIS 7.5 and DNS Configuration

You cannot use the DNS to point to a port (unless the client supports SRV records, most don't).

Websites and Protocols with Host Headers

You will have to put some front-end method in place to do this. Typically you would use a front end web server or a dedicated proxy software to forward the connection from port 80 to port !80 based on the name of the server being requested in the header. Some firewalls can also forward based on the host header too.

SRV Records

Some clients support lookups of SRV records which indicate hostname and port number of server for the specified service (ie the user specifies "example.com", the client looks up a SRV record and gets "server101.example.com" on port "255"; then connects to that). Some clients also implement this where it is not required (my last smartphone would lookup the SRV records when setting up a new e-mail account for example).

Unfortunately support for SRV records is highly uncommon. Only a few notable protocols mandate it's support (Jabber/XMPP, Kerberos, LDAP, SIP) and not every client supports it even when mandated.

I would uninstall and reinstall ASP.NET. I've had issues occur after installing the .NET Framework that I do this almost routinely now.

To uninstall:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ua

To reinstall:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i

If you need to run 32-bit applications, you would also need to run the aspnet_regiis in the C:\Windows\Microsoft.NET\Framework\v4.0.30319 folder. Note that performing the re-installation would affect other ASP.NET web applications if there are any running.

Because the issue occurs so early, it may be useful to enable the .NET Framework Fusion logging. This is designed to provide verbose information about what is occurring during the loading of assemblies.

If all the assemblies are loading ok, I would use Process Monitor to get a trace. That may point you in the right direction for what it was doing at the time of failure.

http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx

If it is an issue of a missing assembly, you can determine what assemblies your application needs by inspecting the manifest. This can be done with ildasm.exe (IL Disassembler) or ILSpy.

I've seen a lot of MVC apps crash at startup with a meaningless error message when introduced on a new server because an assembly (dll) existed in development or test, but not on the new server. If that is the case, it may be one of the following assemblies that need to be copied to the bin folder of the web site:

Microsoft.Web.Infrastructure.dll
System.Net.Http.dll
System.Net.Http.Formatting.dll
System.Net.Http.WebRequest.dll
System.Web.Extensions.dll
System.Web.Helpers.dll
System.Web.Http.dll
System.Web.Http.SelfHost.dll
System.Web.Http.WebHost.dll
System.Web.Mvc.dll
System.Web.Optimization.dll
System.Web.Providers.dll
System.Web.Razor.dll
System.Web.WebPages.Deployment.dll
System.Web.WebPages.dll
System.Web.WebPages.Razor.dll

When you install the ASP.NET MVC msi proper, it usually copies many of those files to a folder in C:\Program Files x86, or under C:\Windows\winsxs somewhere (global assembly cache).

Note that this issue may also occur if the vendor is signing their assemblies, but they are delay-signed. That would also be revealed in the Fusion log. A description of that symptom is here:

https://stackoverflow.com/questions/11030500/assembly-binding-error-bind-result-hr-0x80070002-the-system-cannot-find-the

Delay Signing an Assembly
http://msdn.microsoft.com/en-us/library/t07a3dye.aspx