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 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 or, the host was intended to be the same.

(If you read the URLs in CERN's 1992 list of WWW servers you will see host portions both with and without dots.)

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 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.)

(In 2015, after reading this Frequently Given Answer, a commenter on Hacker News reminisced about using this very search path spoofing mechanism to make corporate intranet WWW sites appear, to naïve users who did not understand what the lack of a dot meant, to be under top-level domain names.)

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

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. (Daniel J. 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, 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 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.