http://to./が開けるしくみ
※2010/04/14 11:55追記
ブコメでのご指摘の通り、「なぜ開けるか」に対する答えは、「"to"のトップレベルドメイン(TLD)にAレコードが設定されているから」というシンプルなものです。
"to"はトンガのTLDで、古くからTLDを売って外貨を稼いでいます。恐らく、今回の"to."URL短縮サービスもその一環ではないかと考えられています。（beroさん コメントでの情報提供ありがとうございました)
※さらに補足：もう少し正しい説明 を追加しました。
Twitterでちょっと話題に上っていたので。
http://to./というURL短縮サービスがあります。一見開けなさそうなこの不思議なURL、実は正しく開けます。
その仕組みについて簡単に説明したいと思います。
ブラウザで"http://to./"にアクセスすると、ブラウザはOSに"to."のIPアドレスを尋ねます。
そのリクエストを受けたOSは、その"to."という文字列から、IPアドレスへ変換しようとします。今回は、Linuxでの動作で説明しますが、Windowsでもおよそ同じ処理が行われます。
まず、OSは"to."に対応するIPアドレスを、OSに設定されているDNSサーバに対して問い合わせます。同じ処理を、コマンドラインから次のようにして実行することができます。今回は、DNSサーバとしてgoogle DNS(8.8.8.8)を使用してみましょう。
$ dig A to. @8.8.8.8 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> A to. @8.8.8.8 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23942 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;to. IN A ;; ANSWER SECTION: to. 63755 IN A 216.74.32.107 ;; Query time: 43 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Apr 13 16:41:37 2010 ;; MSG SIZE rcvd: 36
digコマンドは、「知りたい情報の種類(A)」、「対象のホスト名文字列(to.)」、「"@"＋問い合わせるDNSサーバ(@8.8.8.8)」という引数を取ります。
ホスト名文字列からIPアドレスを取得する場合は、「Aレコード」を問い合わせることになります。その回答が、
;; ANSWER SECTION: to. 63755 IN A 216.74.32.107
これです。「"to.a"に対応するIPアドレスは"216.74.32.107"だ」という回答が返ってきました。
これにより、ブラウザは216.74.32.107のポート80番に接続し、HTTP通信を行います。たったこれだけです。
補足：jpやcomの場合は？
.jpや.comなど、いわゆる普通のドメインの場合はどうかを見てみましょう。
$ dig A jp. @8.8.8.8 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> A jp. @8.8.8.8 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17303 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;jp. IN A ;; AUTHORITY SECTION: jp. 66 IN SOA z.dns.jp. root.dns.jp. 1271142901 3600 900 604800 900 ;; Query time: 44 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Apr 13 16:45:10 2010 ;; MSG SIZE rcvd: 67
このような回答となります。"A"に対する回答が含まれていないため、"jp."に対応するIPアドレスはありません。返ってきた情報は、"ナントカ.jp"の情報はこのサーバに聞いてね(SOA)という情報だけです。com.としても同様です。
"to"というトップレベルドメインの場合に関してのみ、Aレコードを持っているため、正しくIPアドレスを取得できるのです。
補足：なぜ「http://to./」なの？「http://to/」じゃないの？
環境によります。簡潔に言うならば、「to.」はFQDN(Fully Qualified Domain Name: 完全修飾ドメイン名)で「to」はFQDNではない、という違いです。
最後にドットが付いている場合、その表記は絶対的な表記として扱われます。しかし、そうでない場合には、環境によっては相対的な表記として扱われることがあります。
例として、foo.bar.baz.example.com というドメインを考えてみます。example社のbaz部のbar課のfooというPCだとしましょう。このPCを指すとき、foo.bar.baz.example.comと毎回入力するのは面倒なので、bar課では「foo」と入力するだけで「foo.bar.baz.example.com」を意味するようになっていると便利です。そのための機能が、ドメインサフィックスと呼ばれる機能です。
Linuxでは、/etc/resolv.confのsearchオプションで指定できます。
search bar.baz.example.com
と書いてある場合、"foo"と指定した場合、自動的に"foo.bar.baz.example.com"を意味することになります。これを回避したい場合、"foo."とします。後者はFQDNですので、このような自動的な補完は行われません。
このような事情から、ドメインサフィックスが設定されている環境では、http://to/は開かないかもしれませんが、http://to./なら開けるのです。
さらに補足：もう少し正しい説明
to.からIPアドレスが正しく引ける理由について、もう少し正しく詳しく説明してみます。間違っていたらご指摘いただければ幸いです。
※OSが最初に問い合わせるDNSサーバは"to."について何も知らないという前提
(1) OSがDNSサーバに問い合わせる。("to."に対応するAレコードを要求)
(2) DNSサーバは、自分は"to."について何も知らないため、"to."についての情報を上位のサーバに問い合わせることにする。今回の場合、"."、つまりDNSルートサーバに問い合わせを行う。なお、DNSサーバはルートサーバのIPアドレスを事前に知っていることになっている。
$ dig SOA to. @a.root-servers.net. ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> SOA to. @a.root-servers.net. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43993 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;to. IN SOA ;; AUTHORITY SECTION: to. 172800 IN NS tonic.to. to. 172800 IN NS auth02.ns.uu.net. to. 172800 IN NS colo.to. to. 172800 IN NS ns-to.ripe.net. to. 172800 IN NS ns1.iafrica.com. ;; ADDITIONAL SECTION: ns1.iafrica.com. 172800 IN A 196.7.0.139 colo.to. 172800 IN A 216.74.32.104 ns-to.ripe.net. 172800 IN A 193.0.12.224 tonic.to. 172800 IN A 216.74.32.100 auth02.ns.uu.net. 172800 IN A 198.6.1.82 ;; Query time: 104 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Tue Apr 13 17:35:49 2010 ;; MSG SIZE rcvd: 223
"to."について知っているのは、tonic.to.をはじめとする5台のDNSサーバであることがわかる("… IN NS …" 応答)。ついでに、その各DNSサーバのIPアドレスも付加情報（グルーレコード、ADDITIONAL SECTION）として一緒に返ってきている。
(3) DNSサーバは、"to."のAレコードを"tonic.to."に問い合わせる。グルーレコードから、"tonic.to."は"216.74.32.100"であることがわかっているので、このIPアドレスのサーバに問い合わせる。
$ dig A to. @216.74.32.100 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> A to. @216.74.32.100 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46073 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 3 ;; QUESTION SECTION: ;to. IN A ;; ANSWER SECTION: to. 86400 IN A 216.74.32.107 ;; AUTHORITY SECTION: to. 86400 IN NS ns1.iafrica.com. to. 86400 IN NS colo.to. to. 86400 IN NS ns-to.ripe.net. to. 86400 IN NS tonic.to. to. 86400 IN NS auth02.ns.uu.net. ;; ADDITIONAL SECTION: colo.to. 86400 IN A 216.74.32.104 ns-to.ripe.net. 9641 IN A 193.0.12.224 tonic.to. 7200 IN A 216.74.32.100 ;; Query time: 125 msec ;; SERVER: 216.74.32.100#53(216.74.32.100) ;; WHEN: Tue Apr 13 17:39:50 2010 ;; MSG SIZE rcvd: 207
このようにして、OSから問い合わせを受けたDNSサーバは、"to."に対応するAレコードを取得することができた(ANSWER SECTION)。
(4) DNSサーバは、OSに対して「"to."に対応するIPアドレスは"216.74.32.107"だ」と応答する。サーバによっては、今後の問い合わせに対して高速に応答できるよう、この結果を覚えておく（DNSキャッシュ）
(5) OSはブラウザにこの応答を伝え、ブラウザはこのIPアドレスに対して接続を行う。
