Take the 2-minute tour ×

I just read through this question, and when browsing through the answers, I randomly tried out something and noticed that http://admin.to and http://admin.to. lead to different locations. Both return a 403 error, but the .to. domain redirects to a completely different server.

How is this possible? I though that both should be technically identical, so what happens here?

share|improve this question

4 Answers 4

up vote 6 down vote accepted

Actually, the DNS entry is the same (, as expected. It seems what's different is the vhost. Very likely, the server has one vhost for each server name, specifying the final dot for one of them and not for the other. It's more of an Apache question than a DNS question I think.

Now as others have said, the difference between admin.to and admin.to. is that the second one is a fully qualified name, so your resolver won't try to resolve it by appending your DNS search parameters to it, whereas the first one will be tried with the search parameters.

As an example, I put raphink.info in my search path in /etc/resolv.conf:

$ grep '^search' /etc/resolv.conf
  search raphink.info

$ getent hosts www   raphink.info www.raphink.info

$ getent hosts www.

The first request is www without a trailing dot, so the resolver tries to solve it with the search path. The second request is a fully qualified name since it has a trailing dot, so the search path is not tried, and the resolution yields no results.

Now as I said, your question in this case seems more like an HTTP server thing than a DNS one, since I get the same result on my own machine:

$ getent hosts admin.to   admin.to

$ getent hosts admin.to.   admin.to
share|improve this answer

This smells of a host headers issue:

As far as DNS is concerned you are correct: With or without the trailing . the domain resolves to, but the server that lives there (which reverses to the serverdomain.org name) doesn't understand that when it parses the host headers.

share|improve this answer

A trailing dot means that it's a fully qualified name, which will be handled differently by DNS resolvers.

share|improve this answer
It should not be handled any different. The trailing dot is implied in all DNS requests that don't include it specifically. –  Scott Lundberg Feb 2 '10 at 20:09
A not fully qualified name is handled differently on two levels: the client will try to append the search path to it, and the DNS server will append the zone to it if it's found in a zone file. –  ℝaphink Feb 3 '10 at 8:34

The way I understand it, the . at the end indicates that it is a Fully Qualified Domain Name. It means that this is the exact hostname that will be looked up.

If you leave off the . at the end, it will first search your domain. So for example if you go to admin.to, and you happen to be part of a domain somedomain.com, then it will first look for admin.to.somedomain.com. If that resolves, then it would go to that location rather than your intended domain of admin.to.

share|improve this answer
When you type http://google.com without a trailing dot, do you expect to get to http://google.com.mydomain.net if it exists? –  ℝaphink Feb 2 '10 at 18:34
@ Raphink - Practically, no. Technically, yes. Just because software treats the "normal" TLDs specially doesn't mean that's what the standard says to do. No trailing dot should be looking through the domain search path first... –  voretaq7 Feb 2 '10 at 19:03
The distinction is that the DNS servers themselves don't search the current domain, the application does. In other words, it's client specific. The DNS servers are not going to do that search for you... –  Scott Lundberg Feb 2 '10 at 20:13
Dave, as Scott Lundberg said in another comment, the trailing dot is implied. What application searches the "current domain" without using DNS? –  John Gardeniers Feb 2 '10 at 21:24
Right voretaq7, there's still a chance that poke actually has a server at admin.to.mydomain.net with mydomain.net in his DNS search parameter, although it's not likely at all, seing how he gets a 403 in both cases. I lean more towards the vhost explanation :-) –  ℝaphink Feb 3 '10 at 8:19

Your Answer


