No, that dot in the domain name of the URL is not a mistake.

You've come to this page because you've asked a question similar to the following:
I omitted the trailing dot in the domain name in the http://example.com./ URL because it was a typographical error.

This is the Frequently Given Answer to such questions.

You can find another approach to this answer written by Stuart Cheshire .

No, it wasn't. It was there for a reason. It made the domain name a fully qualified one, and thus unambiguous and not prone to search path spoofing.

Originally, as defined in RFC 1738 (§ 3.1), the "host" portion of a (Common Internet Scheme) URL was always and unequivocally a fully qualified domain name and the conventional mechanism for distinguishing fully-qualified domain names from non-fully-qualified domain names did not apply. Whether it was example.com. or example.com, the host was intended to be the same.

Unfortunately, in practice web browsers have always violated that specification and passed the "host" portion through the name qualification procedures of their DNS Client libraries when mapping the host name to a set of IP addresses. (For example, those that used the BIND DNS Client library would leave the RES_DNSRCH option set and would not append the final trailing dot if it was missing.)

For example: Posit that the web browser uses the BIND DNS Client library and the search example.net directive is present in that library's resolv.conf configuration file.

The fully-qualified domain name would thus prevent search path spoofing. (See RFC 1535 and RFC 1536 § 6 for more discussion of this.)

RFC 2396 (§ 3.2.2) reluctantly acknowledges this existing practice, thereby legitimising the (already existing) notion of (CIS) URLs that employ fully qualified domain names for their "host" portions (http://example.com./) and (CIS) URLs that do not (http://example.com/).

This notion hasn't yet percolated through to all content HTTP server administrators, and we find a few badly configured web sites which don't contain the correct content when accessed using URLs with fully qualified domain names. (Dan Bernstein's web site is one, for example.) However, this is simply an education problem. (Many web sites have no such problem, it should be noted.)

Best practice is thus the following:

The irony of this change to the semantics of (CIS) URLs, is that it would have been better had the web browsers been fixed to conform with RFC 1738 rather than the standards changed to reflect the web browsers' behaviours. This is not just because doing so has undermined the notion of universality and forced additional work on content HTTP server administrators if they want their web sites to be configured properly, but also because web browsers usually have their own highly visible search path mechanisms anyway (transmuting example into www.example.com, for instance) which they apply to "host" names themselves. So the DNS client libraries' name qualification procedures, operating behind the scenes invisibly to the user, are usually redundant in the first place.


© Copyright 2004–2004 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.