If there exists a dot after ".com", is it a valid URL?

Question

I came across a few URLs which also render with or without a dot/period after .com, while some do not.

For example:

www.example.com.

Should the URL render normally if a dot/period is added after .com or should it go to a 404 page?

Answer 1

See: http://www.dns-sd.org/trailingdotsindomainnames.html

And the old RFC it links to: http://www.ietf.org/rfc/rfc1034.txt

Truly fully qualified domain names have a period after the TLD, but unless you're managing a DNS server you almost never come across them. It is however something you might want to consider if you were for instance writing an HTTP server varying on hostname.

Answer 2

As said in comment this great resource, solves many of your queries, including a portion below specific to your query:

Fully-Qualified Domain Names

When I double-click a Bonjour (DNS-SD) Name in a web browser like Safari, the resulting URL has a hostname with a dot at the end. Is this a bug?

No, the dot at the end is correct.

You can try it here. Try adding a dot at the end of www.dns-sd.org, as shown in the subtitle at the top of this page, and you should still get the same page.

It's a little-known fact, but fully-qualified (unambiguous) DNS domain names have a dot at the end. People running DNS servers usually know this (if you miss the trailing dots out, your DNS configuration is unlikely to work) but the general public usually doesn't. A domain name that doesn't have a dot at the end is not fully-qualified and is potentially ambiguous. This was documented in the DNS specification, RFC 1034, way back in 1987:

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.ISI.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 ISI.EDU domain.

How this affects web browsing

The people defining the HTTP protocol understood this issue, and RFC 1738 specifies clearly that the part of a URL is supposed to contain a fully qualified domain name:

3.1. Common Internet Scheme Syntax

  //<user>:<password>@<host>:<port>/<url-path>

host
  The fully qualified domain name of a network host

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 searchlist to constuct 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."

• www.example.com. — Absolute domain name
• www.example.com — Relative domain name, which, after applying the "." that's always implicitly in everyone's DNS searchlist, becomes www.example.com.
• www with "example.com" in DNS searchlist — user types "www" and gets
  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). Unfortunately the Apache web server (at least in some versions) doesn't recognise that all those three names are just three different ways of referring to the same host.

If you're a web site administrator setting up a web site using Apache "VirtualHost" directives or similar, you need to have a ServerAlias line listing all the things the user might type to get to that web site (typically the first label, the whole name without a trailing dot, and the whole name with a trailing dot, as shown in the example above).