How do I allow trailing dot in host headers in IIS

I am running an IIS 7.5 site that serves up content for http://www.foo.com/

I've been asked to properly route http://www.foo.com./ (note the trailing dot). If you hit that page now, you'll get an IIS error:

Bad Request - Invalid Hostname

HTTP Error 400. The request hostname is invalid.

This happens even for http://www.microsoft.com. I have seen some sites route trailing periods successfully (like http://www.amazon.com./), but it looks like most of those were using Apache, not IIS.

I added a host header in IIS for www.foo.com. which is allowed. However, it won't let you start the site. It won't start and pops up a message box saying:

Value does not fall within the ex开发者_如何学Cpected range.

Does anyone know how to serve up domains with trailing dots in IIS?

The trailing dot is an absolutely legal part of the hostname - it's just that it's normally invisible because it's implicit in DNS. If the trailing dot is present it's called a "Fully Qualified" Domain Name (FQDN).

Note that on the wire DNS always deals in FQDNs.

§3.2.2 of RFC 3976 (the definition for URI syntax) says this (my emphasis):

A host identified by a registered name is a sequence of characters usually intended for lookup within a locally defined host or service name registry, though the URI's scheme-specific semantics may require that a specific registry (or fixed name table) be used instead. The most common name registry mechanism is the Domain Name System (DNS). A registered name intended for lookup in the DNS uses the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. Such a name consists of a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters. The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain.

File a bug report with MS.

This is effectively a bug in IIS7+, apparently with no workarounds. It is affecting me as well. Please go vote up the request for MS to fix this:

https://connect.microsoft.com/WindowsServerFeedback/feedback/details/648242/trailing-dot-in-fqdn-causing-bad-request-invalid-hostname

This issue is discussed on Microsoft forums here and is seen as a change in behaviour between IIS 6 and 7.

This site here provides a work-around to re-write the url on the IIS side.

The config change required for various web-servers is reproduced below in case the site above ever goes away.

Apache (.htaccess)
RewriteCond %{HTTP_HOST} !^domain\.zone$
RewriteRule ^(.*)$ http://domain.zone/$1 [L,R=301]

Nginx (nginx.conf)
if ($http_host != 'domain.zone') {
    return 301 http://domain.zone$request_uri;
}

IIS (web.config)
<httpRuntime relaxedUrlToFileSystemMapping="true"/>
<rule name="point" stopProcessing="true"> <match url="^(.*)\.$" />
    <action type="Redirect" url="{R:1}" redirectType="Temporary" /> 
</rule>

I am sure that there is a bug somewhere but the question is what the bug is.

I think that the bug is that IIS allows you to set a host header with a trailing ".". The host header is not the same thing as a FQDN. The host header is meant to match the Host directive in the HTTP request:

GET / HTTP/1.0
HOST: www.doilooklikeicare.com

It is certainly valid in the URL typed in to the browser eg: http://www.doilooklikeicare.com./default.aspx as this is resolved to find out WHERE to send the request.

Try removing the trailing dot in the host header and it should work OK. You will still be able to use it in the URL.

Hope this helps

Jonathan

The browser is at fault. It should not accept a trailing dot in the hostip (hostname) portion of the URL.

Specifically, for FF and other mozilla-based browsers:

Bug 124565 - DNS: URL: FQDN usage in "hostip"

From a design perspective, the networking library (necko) should be rejecting this, but the docshell (the user-friendly part) should probably trap aa user-inputed string, and do fix-up (remove the ".", and clean up the Host: header).

Incidentally, necko also has a problem where it is fqdn-lazy, it doesn't stick the "." on the end of the fqdn when it sends the request to the resolver, which makes every fqdn treated by the local-resolver's pqdn logic.