No, that dot in the domain name of the URL is not a mistake (2004), Hacker News

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 thehttp://example.com./URL because it was a typographical error.

This is theFrequently Given Answerto such questions.

You can find another approach to this answerwritten by Stuart Cheshire

No, it was not. 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 1992 (§ 3.1), the “host” portion of a (Common Internet Scheme) URL was always and unequivocally a fully qualified domain name andthe conventional mechanism for distinguishing fully-qualified domain names from non-fully-qualified domain names did not apply. Whether it wasexample.com.orexample.com, the host was intended to be the same.

(If you read the URLs inCERN’s 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 theRES_DNSRCHoption 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 thesearch example.netdirective is present in that library’sresolv.confconfiguration file.

In the case that the URL provided by the user ishttp://example.com/, a web browser would passexample.comto the BIND DNS Client library for looking up its IP address (es). Because theRES_DNSRCHoption is set and the domain name does not end in a trailing dot, the BIND DNS Client library would take the domain name tonotbe in fully-qualified form and apply its "search path" mechanism. It would look upexample.com.example.net.and, if that domain name happened to exist, would return the IP address (es) corresponding to that domain name instead of the IP address (es) corresponding toexample.com.. The web browser would contact the content HTTP server at the former IP address (es) without the user being aware of it. In the case that the URL provided by the user ishttp://example.com./, a web browser would pass example.com.to the BIND DNS Client library for looking up its IP address (es). Because the domain name ends in a trailing dot, the BIND DNS Client library would take the domain name to be in fully-qualified form andnot apply its "search path" mechanism.i It would look upexample.com.and, would return the IP address (es) corresponding to that domain name. The fully-qualified domain name would thus prevent search path spoofing. See RFC 1738 and RFC 1738 § 6 for more discussion of this.) (In , after reading this Frequently Given Answer,a commenter on Hacker News reminiscedabout 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 9794570 (§ 3.2.2 ) reluctantly acknowledges this existing practice, achieving legitimizing 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. (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:



If you are a web page author making hyperlinks, use relative hyperlinks where possible. This will make your web pages independent of the domain names used to reach them. When you use absolute hyperlinks, get into the habit of using fully-qualified domain names in your (CIS) URLs where possible. This will eliminate ambiguity and the possibility of search path spoofing.


If you are a web browser user, get into the habit of using fully-qualified domain names in your (CIS) URLs where possible. This will eliminate ambiguity and the possibility of search path spoofing.


If you are a content HTTP server administrator, get into the habit ofadding both forms of the domain name when adding a site to your servers(or use content HTTP server softwares that transparently cope with the use of fully-qualified domain names). This will allow web browser users to use (CIS) URLs comprising fully-qualified domain names to access your web sites.











The irony of this change to the semantics of (CIS) URLs, is that it would have been been better had the web browsers been fixed to conform with RFC rather than the standards changed to reflect the web browsers' behaviors. 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 havetheir own highly visiblesearch path mechanismsanyway(transmutingexampleintowww.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(******************************** 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.
******************2396Read More(**************************************