I read this question How can URLs have a dot . at the end, e.g. www.bla.de.? and realise that FQDN should contain a trailing . for the root label of the DNS tree:

example.com. instead of example.com

However, there are issues as pointed out in this blog article:

If you do not consider the fact that the user can accidentally enter the domain name with a dot at the end, or follow a link received from some "well-wisher" and get on your domain name with the dot at the end, as the result it may lead to unexpected consequences:

1) If the website uses HTTPS, when navigating to the domain name with the dot at the end, the browser will display the warning on untrusted connection.

2) Authentication may be broken, as cookies are usually set for the domain name without a dot at the end. User in this case will be quite surprised why he can’t log in. It is noteworthy, that if you set a cookie for a domain name with a dot at the end, this cookie will not be passed to the domain name without the dot at the end and vice versa.

3) JavaScript on the page may be broken.

4) There may be problems with the caching of website pages (for example, https://www.cloudflare.com/ does not clear the pages cache if domain name has a dot at the end considering it an invalid domain name).

5) If in conditions in the web server configuration you rely on the particular domain name ($http_host in Nginx, %{HTTP_HOST} in Apache) without the dot at the end, you may face a variety of unexpected situations: unexpected redirects, basic-authorization problems, etc.

6) If the web server is not configured to accept requests on the domain name with the trailing dot, any user who accidentally typed a domain name with the trailing dot will see something like Bad Request - Invalid Hostname.

7) It is possible that search engines may find that your resource has a duplicate content, if someone accidentally or intentionally post links to your web pages with a dot at the end of the domain name.

I also realise that http://webmasters.stackexchange.com./ does a 400 Bad Request. But since the domain name proper should contain a . at the end, shouldn't we be issuing 400 error or 301 redirect for hostnames without a trailing dot? What is the proper way to deal with this issue in a coherent and consistent manner?

  • There's a serious misunderstanding of this, the dot, but it's been too long for me to write an answer and I'll probably say something wrong. Suffice to say that the dot stands for the root, or parent, of the domain name. The root here would be "webmasters" and the root of that would be "dot" so "dot" would not be at the end of the URI and I don't think it belongs in the URI at all, in this case. As I said, I've forgotten too much of the exact operation and I'll leave that to someone else.
    – Rob
    Commented Dec 14, 2014 at 15:18
  • I'd just like to leave a note; make your domain name compatible with a . - personally I always put a dot at the end, I don't know why, and I notice a lot (lot) of websites aren't compatible with this.
    – William
    Commented Dec 14, 2014 at 15:28
  • The . [dot] at the end of a domain name was always meant to be transparent and not intended to be ever used by a user. It is the root of the TLD (TLDs are domains) .com. I personally would not worry about the odd wing-nut that puts a dot at the end of a URL with respect to my Friend William who is indeed impressive. ;-)
    – closetnoc
    Commented Dec 14, 2014 at 16:12
  • @closetnoc Well, I should admit that ;) It's just a weird habit. You shouldn't optimize your website to be compatible with it because of user behaviour, but because of the technical side of things.
    – William
    Commented Dec 15, 2014 at 19:23
  • @WilliamD.Edwards At least it is not as strange as picking your teeth with your toes... not that I do that... anymore.
    – closetnoc
    Commented Dec 15, 2014 at 19:39

3 Answers 3


To partially answer your question, you can add it to .htaccess canonical forwarder rules. In a basic HTTP sense it looks for a period before the URI and works it into whatever anti-duplicate forwarding mechanism you use. Here is an example including a common "addon domain" sub util route:

RewriteCond %{HTTP_HOST} ^domain\.hostdomain\.example(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.hostdomain\.example(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^domain\.example(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain\.example\.$
RewriteRule ^(.*)$ "http\:\/\/www\.domain\.example\/$1" [R=301,L]

What this would do is forward all of the following to a canonical HTTP www domain:

  • domain.hostdomain.example
  • domain.hostdomain.example.
  • www.domain.hostdomain.example
  • www.domain.hostdomain.example.
  • domain.example
  • domain.example.
  • www.domain.example.

All forward to:

  • http://www.domain.example

There is a caveat to this though - as stated in the original blog quote, SSL will not forward correctly and will fly a browser warning or 400 bad request error in most server instances (esp with HSTS). This is because it sees the "host" SSL in a post-TLD-period use case. I am not sure of a workaround to deal with the host SSL warning since it comes before .htaccess and things.

  • Aside: Rather than redirecting from every possible domain to the canonical example.com. It might be easier to just to say: If not example.com then redirect to example.com. (?)
    – MrWhite
    Commented Dec 27, 2016 at 2:38

my comment my reply to the text by the first link:

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.

I think he is not right, I think example.com was not allowed at all in URLs according to RFC 1738, it is cited in the second text, and I cite it:

3.1. Common Internet Scheme Syntax
        The fully qualified domain name of a network host

and example.com could not be used in HTTP headers at that time, because RFC 1738 is of 1994 and host field appeared only with HTTP 1.1 in 1997 (you can check in Wikipedia).

So, indeed, only fully qualified domain name (FQDN) was left allowed in URLs. I think, this was a error in RFC 1738, because in such way it made (tried to make) the "relative domains" feature useless. if it did not disallow it, they theoretically could be used in a tag hrefs in local scripted sites or static HTML documentation inside big companies that used relative domains, if browsers and servers supported it. but even if RFC 1738 disallowed them, people did not obey it: they continued to use top level domains in relative form ie without trailing dot, so this disallowing by RFC 1738 was not a big practical problem anyway, and people had and used an alternative to relative domains: they just made local top-level domains like localhost (and used and use them also without trailing dot).

then he says:

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

I think he meant that hosts without trailing dot should be just thrown off as error, and only absolute domains (FQDN) should be passed to DNS. I think probably browsers did pass all domains to DNS because people used their custom local top level domains like localhost. and anyway, later in RFC 2396 published in 1998, the usage of top level domains in URLs without trailing dots was allowed.

Then the author (Jonathan de Boyne Pollard) cites RFC 2396 and expresses regrets that it changed according to the established human behaviour, ie de facto standards, says that better would be if browsers obeyed RFC 1738, and recommends to all people to use only FQDN, in all places, as it was commanded by RFC 1738.

But what would happen if people obeyed RFC 1738? URLs like http://example.com/test.html and http://localhost/test.html all had to be rewritten as http://example.com./test.html and http://localhost./test.html. Browsers would have to either mark hosts without dots as error, or redirect on clicking them to full/absolute form of them. All people who configured local top-level domains like localhost would have to configure their servers to accept only requests for domains like localhost., or accept and redirect [all URLs inside] localhost to [corresponding URLs in] localhost.. Text like localhost would stay useful only when typing it in browser address bar, but that would be only very useless usage, and the relative domain feature is not needed for that, because browsers search for domains on typing. usage of them in HTML source would become useless because it would lead to that such links would not work, or clicking all links with localhost would move user to localhost. and it would be just extra redirect on every click (on such links). so, RFC 1738 would make the planned "relative domain" feature entirely useless. if some company used that feature, and used their relative domains in their local sites, and their URLs with relative domains were not redirected to absolute form by browsers, so their sites worked normally, if they also obeyed RFC 1736, they would configure their servers to accept only FQDN, and they would have to either rewrite all their such URLs with FQDN, or work with extra redirect on every click on such URLs. if that companies liked having short domain like "team101" instead of "team101.microsoft.com." in their address bars and HTML sources, they would have to start to use their custom internal top-level domains like "team101." ie like localhost. instead of subdomains like "team101.microsoft.com." (which could be used as just "team101" before they decided to obey RFC 1738).

I have found out that the trailing dot, which was so strongly supported by RFC 1738, really appeared only after the standard without trailing dots! it appeared with RFC 1034 in 1987, it is cited in the second link, and I cite it:

Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot. We use this property to distinguish between:

  • a character string which represents a complete domain name (often called "absolute"). For example, poneria.example.EDU.
  • a character string that represents the starting labels of a domain name which is incomplete, and should be completed by local software using knowledge of the local domain (often called "relative"). For example, poneria used in the example.EDU domain.

RFC 1034 (of 1987) just declared all domains which were used, seems they all were without trailing dots, declared them all as becoming relative domains! but they still worked as before, so probably few people knew out about that, and continued to think that they are unambiguously requesting a unique real example.com site when they use example.com without trailing dot. so that has become an additional security breach in some cases: famous real example.com could be spoofed by a subdomain administrator even if he was not given rights to make any local domain like localhost.. so, RFC 1034 also was not designed very well: seems its authors did not expect that maybe it will be {not widely known, so creating security breach}!

probably RFC 1738 (1994) tried finally to bring the idea of distinction between absolute and relative domains to wide audience and also fix that security breach after 6 years, {but by fixing the security breach by disallowing relative domains in URLs it made relative domains useless, {but I think they probably were not used widely, probably only in some big companies}}. so, what would be [left] in result of RFC 1737, if it would be obeyed?

  1. relative domains declared in 1987 would become finally useless, so, trailing dot, designed to show absolute domain, also would become finally useless and redundant "legally" ie as defined by the RFCs! (but maybe they planned later re-allow relative domains in URLs after many years, when wide audience (general public) start to know about the possibility of relative domains).
  2. and RFC 1737, if it was obeyed, would also fix the security breach. - but even RFC 1034 would not create the security breach if it reached masses and it was widely understood that using relative domain is not safe! - so, main recipe to fix it was reaching the wide audience, and publishing one more RFC was just one of many ways to do it.

I think now that probably the relative domain feature has not become widely known after RFC 1034 (of 1987) because it was of too limited use: only in some big companies or providers' local networks, and it was a feature with no practical value, because local networks could already make any local domain, so that feature was just for itself, it was in fact just a useless text in RFC that anybody should know and use without having any additional benefit! but people created the little security breach by widely ignoring the RFC, while browsers started to obey it.

I checked the relative domains feature yesterday, it works. (it is OK, because RFC 2396 (of 1998) re-allowed it after RFC 1034 (of 1987) denied, and later RFC 3986 (of 2005) still allows them). I added DNS suffix in Windows 10 - control panel - ... - network device properties - IPv4 properties - additional - DNS tab. when I added google.com then opened http://mail/ in Firefox, it opened Google's server, but it was not configured to work with just "mail" in the HTTP "host" header, so I got something like "404" page.


my reply to the text by the second link:

he also cites the rule in RFC 1738 and says:

Unfortunately, the people implementing web browser clients appeared not to understand what this meant. When you access a web site, the value most web browsers put in the "Host:" field is what the user typed, not what the computer actually ended up using, after applying the DNS user's search list to construct a fully-qualified name from the partial name. For example, here are three different ways the user may refer to the host "www.example.com. ... When sending the Host: parameter to the web server, the web browser client puts in what the user typed (www.example.com., www.example.com, or www) instead of what the client ended up actually looking up in DNS (www.example.com. in all three cases). ...

This is not very true (correct), because RFC 1738 was very strict in this regard, and it disallowed relative domains in all URLs, even if it is in browser's address bar, and URL itself is the [recommended] way of making any references to sites, even if people write it on paper, so it was not allowed to users to refer to that site in that 3 ways, by RFC 1738, if that users were going to think by it that they used URL!

and seems the author of this text (Stuart Cheshire) did not know about RFC 2396, so this text is outdated.

and what is the situation nowadays? RFC 3986 allows referring to absolute domain without trailing dot: it says " The rightmost domain label of a fully qualified domain name in DNS may be followed by a single ." and that it should be used if it is "necessary to distinguish between the complete domain name and some local domain". I think that due to de facto standards it is almost never necessary, so WordPress can accept the de facto standard and redirect from address with trailing dot to the address without it.


I like to think of the trailing dot as the "real" root of the Internet, and that it lives in Virginia, USA. If you leave out the dot, then some root is always implied. For normal users, it's the same root, and that's the situation I will discuss today.

In my perverse way, I actually find the trailing dot quite handy. If I'm checking out someone else's website and I want to start fresh, with no caching, no cookies etc, and I'm too lazy to flush those out, I'll either use a different browser or I will add the dot. If the site doesn't redirect me, I've got all-fresh uncached URLs for all the site's pages and other resources.

As a webmaster, I want all people and robots viewing a page to be viewing it with the same URL, and therefore with the same hostname. If the hostname isn't the one I want them to use, I'll do an immediate 301 redirect so they will see the correct URL in their browser. For my PHP-based sites, I handle the problem in PHP and not in the .htaccess or web.config file, as it is more portable and is easier to test on development and staging servers. I handle my database connections at the same time, as they also also vary among development/staging/production servers.

Here is a simplified version of my typical code. Note the canonical redirects towards the end.

    $Host = $_SERVER['HTTP_HOST'];
    switch ( $Host ) {
        case 'exampleweb.local':                    // my local dev machine
                $MysqliParams = array(
                        'host'      =>  'localhost',
                        'username'  =>  'root',
                        'passwd'    =>  'snoopy',
                        'dbname'    =>  'exampledb');
        case 'www.example.com':                 // the "live" site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_db');
                $GoogleAccount = 'UA-13243546-01;   // only enable for live site
        case 'exampleweb.mystagingsite.example':        // the client preview site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_staging');
        case 'example.com':                     // canonical redirects 
        case 'example.com.':
        case 'www.example.com.':
                header('HTTP/1.1 301 Moved Permanently');
                header("Location: http://www.example.com");
                die("invalid hostname $Host");
  • I have typically done my host canonicalization through Apache virtual hosts rather than handling it in code. It appears that Apache matches a HTTP host name with or without the trailing dot to a virtual host, but you can see if there is trailing dot in the code. Commented Dec 19, 2014 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.