http://www.dns-sd.org./TrailingDotsInDomainNames.html
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.
Unix users are familiar with the concept of relative and absolute file names. File names starting with a leading slash are absolute and unambiguous. File names without a leading slash are relative to your current working directory or some other assumed context. For example, if you type a command like "emacs", then Unix will consult your $PATH to locate the executable file to run; if you type a command like "/usr/bin/emacs", then Unix will not search using your $PATH variable — it will directly run the file you named. When you type "emacs" you're not necessarily sure what exact program you're running; when you type "/usr/bin/emacs" that ambiguity is removed.
In DNS, your search domains play a similar role. If you have "apple.com", "microsoft.com", "linux.com", and "malicioushackers.net" in your DNS searchlist, then when you type a hostname like "www", you'll actually get one of "www.apple.com", "www.microsoft.com", "www.linux.com" or "www.malicioushackers.net". It may not always be clear to you which one you're going to get, especially if DHCP options are inserting extra entries into your DNS searchlist, like "myisp.com", as they usually do.
Most people have an intuitive understanding of this when they type a single-label name with no dots, because they don't expect a single-label name to resolve as-is. What surprises most people is that if you type a multi-label name containing dots, then it's still relative to your DNS searchlist unless you remember the trailing dot on the end to make it fully-qualified. So, if you type "www.someco.com" and you have "comcast.net" in your DNS searchlist then you could end up actually getting "www.someco.com.comcast.net." That web page probably doesn't exist, but it could. At the very least, all these extra DNS lookups are inefficient and a waste of time. At worst, you could end up accessing a malicious web site set up to deceive you.
To avoid the inefficiency of these extra lookups, and, perhaps more importantly, to avoid the pointless ambiguity and potential unreliability that results, most Bonjour (DNS-SD) software uses fully-qualified DNS domain names with dot at the end. When you resolve a service to its hostname using DNS-SD, you know that hostname is complete; it's not a partial name relative to whatever happens to be in the user's DNS searchlist at that moment.
(This advice holds any time you're using a hostname that's generated programatically, as opposed to input entered by the user. For example if you write software that has a DNS name of one of your severs embedded in it for some reason (e.g. for update checking), then that name should have a dot at the end. If it doesn't have a dot at the end you risk it being looked up relative to the user's current DNS searchlist. Since you probably don't know or care what's going to be in your user's DNS searchlist, that's almost never what you actually want. Normally it will find the right host, but in the event of DNS failures it will then go off down the user's searchlist looking for other matches, which results in time delay doing pointless lookups, and at worst could even result in it connecting to the wrong host.)
The people defining the HTTP protocol understood this issue, and RFC 1738 specifies clearly that the <host> 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."
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).
See also: No, that dot in the domain name of the URL is not a mistake.