どのように一体http://to./は有効なドメイン名ですか？
どうやらそれはURLの短縮版です。 ChromeおよびFirefoxでは問題なく解決されます。これはどのようにして有効なトップレベルドメインですか？
更新：それがブラウザの悪ふざけだと言っている人々のために、なぜそれはそれです：http://com./は私を次の場所に連れて行きません：http://www.com/？
また、ブラウザがアドレスバーに実際に表示されている場所以外の場所から応答を送信することはありますか？フレームセットなどの問題は別として、ブラウザはフィッシングから身を守るために、アドレスバーのサイトからのみコンテンツを送信しようと真剣に取り組んだと思いました。
基本的に、誰かがccTLDの所有者を「に」説得することに成功しました。 （トンガ？）自分のIPアドレスにAレコードを割り当てます。 URL短縮機能の奇妙な古い世界ではかなりのクーデターです。
通常、これらのトップレベルには標準のAレコードを介してIPアドレスが割り当てられませんが、.uk、.com、.euなどに対して同じことができなかったと言っても過言ではありません。
厳密に言えば、「。」を使用する理由はありません。指定しますが、ブラウザが「to.yourdomain.com」などの他の組み合わせを最初に試行するのを防ぎ、アドレスの解決を高速化する必要があります。ドットがないため、ブラウザーを混乱させる可能性もありますが、少なくともSafariは問題なく動作するようです。
"to"（国TLDのTLD）は、サイトのドメイン全体です。ブラウザの手口はありません。
$ telnet to 80
Trying 216.74.32.103...
Connected to to.
Escape character is '^]'.
GET / HTTP/1.1
Host: to
HTTP/1.1 200 OK
Date: Thu, 03 Dec 2009 18:34:04 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_Perl/1.26
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
2d7
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>TO. -- Get Shorty URL</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<form method="post" action="/" enctype="multipart/form-data">
<table><tr><td>Enter a long URL:</td> <td><input type="text" name="url" size="50" /></td></tr><tr><td>Enter an optional name:</td> <td><input type="text" name="name" size="20" /></td></tr><tr><td> </td> <td><input type="submit" name="'Witz that URL!" value="'Witz that URL!" /></td></tr></table></form>
</body>
</html>
0
Connection closed by foreign Host.
" http://to./ "を使用することをお勧めする理由は、一部のブラウザーは "to"を " http://www.to。 com "はアドレスバーにあります。
どのDNSゾーンにも、そのゾーン自体のDNSレコードを含めることができます（バインド構成ファイルでは、このレコードには@のラベルが付いています）。実際-これについてお聞かせください-ルートゾーンにそれ自体を表す@を付けることはできますか？ IE @に住所レコードを含めることができますか？できなかった理由がわかりません。それは、持っているクールなアドレス " http：//./ "
「ルート」ゾーンは単に「。」という名前のゾーンです。現在、そのゾーンには多数のネームサーバーがあります。これらのネームサーバーのアドレスは テキストファイル として配布されます。このテキストファイルまたは類似のものは、多くの典型的な再帰ネームサーバーに手動で入力されます。
「。」を配置する名前の最後にあるローカルリゾルバは、入力した名前が " 完全修飾 "ドメイン名であることを示します。つまり、検索したい名前だけを正確に指定します。多くの場合、「www」などの修飾されていない名前またはあいまいな名前を使用して、ローカルのDNSリゾルバーが「dn。ドメイン」または「検索ドメイン」。
これらのルートレベルのドメインサーバーには、 " トップレベル "大まかにマッピングされるドメインのリストがあります 古い抽象化 80年代の研究者がインターネットがどのように使用されると考えたかのリスト 国 、および「 インフラストラクチャ 」のトップレベルドメイン。これらのトップレベルドメインのそれぞれには、そのドメイン内の実際のゾーンのリストを含む多数のネームサーバーがあるため、maps.google.comへのリクエストは最初にルートレベルサーバーに送信され、ルートレベルサーバーがを知っているネームサーバーのリストを渡します。 com、そして尋ねられたとき、それらの1つはgoogle.comのレコードを持っているネームサーバーを知っており、それらの1つはwww.google.comの特定のレコードを知っています。
したがって、国または組織のTLDを実行している人にgoogle.zoneだけでなく.zoneの住所レコードを入力するように説得するだけで、あなたは金色です。
現在、次のトップレベルドメインにはアドレスレコードがあります（ただし、すべてが実行されているWebサーバーではありません）。
ac has address 193.223.78.210
ai has address 209.59.119.34
bi has address 196.2.8.205
cm has address 195.24.205.60
dk has address 193.163.102.23
gg has address 87.117.196.80
hk has address 203.119.2.28
io has address 193.223.78.212
je has address 87.117.196.80
ph has address 203.119.4.7
pn has address 80.68.93.100
pw has address 203.199.114.33
sh has address 64.251.31.234
tk has address 217.119.57.22
tm has address 193.223.78.213
to has address 216.74.32.103
uz has address 91.212.89.8
ws has address 63.101.245.10
そして以下はmxレコードを持っています（したがってuser @ TLD。は潜在的に配信可能なアドレスです）
ai mail is handled by 10 mail.offshore.ai.
as mail is handled by 10 dca.relay.gdns.net.
cf mail is handled by 10 mail.intnet.cf.
dj mail is handled by 5 smtp.intnet.dj.
dj mail is handled by 5 relais2.intnet.dj.
dm mail is handled by 10 mail.nic.dm.
gp mail is handled by 20 manta.outremer.com.
gp mail is handled by 5 ns1.nic.gp.
gp mail is handled by 10 ns34259.ovh.net.
gt mail is handled by 10 mail.gt.
hr mail is handled by 10 alpha.carnet.hr.
io mail is handled by 10 mailer2.io.
kh mail is handled by 10 ns1.dns.net.kh.
km mail is handled by 110 bow.snpt.km.
km mail is handled by 100 mail1.comorestelecom.km.
mh mail is handled by 10 imap.pwke.twtelecom.net.
mh mail is handled by 20 mx1.mail.twtelecom.net.
mh mail is handled by 30 mx2.mail.twtelecom.net.
mq mail is handled by 10 mx1-mq.mediaserv.net.
ne mail is handled by 20 bow.rain.fr.
ne mail is handled by 10 bow.intnet.ne.
pa mail is handled by 5 ns.pa.
td mail is handled by 0 mail.intnet.td.
tt mail is handled by 0 66-27-54-138.san.rr.com.
tt mail is handled by 10 66-27-54-142.san.rr.com.
ua mail is handled by 10 mr.kolo.net.
va mail is handled by 20 paul.vatican.va.
va mail is handled by 50 proxy2.urbe.it.
va mail is handled by 90 john.vatican.va.
va mail is handled by 10 lists.vatican.va.
ws mail is handled by 10 mail.worldsite.ws.
（ここで "tt"がどうなっているのか本当に気になります...）
したがって、理論的には、pope @ vaにメールを送信できます。そしてそれは適切に配信されます...
別のルートサーバーを使用する場合、インターネット上に存在するものの別のビューが表示されます。私が行ったすべてのローカル解決は、ルートサーバーに直接移動する " dnscache "を使用しているローカルシステムに対するものでした。他の多くの解決DNSサーバーは、ルートサーバーに問い合わせるのではなく、別のローカルDNSサーバーに問い合わせます。
それはどうですか？ドメインが持つ必要のある最小の「セクション」に制限はありません。それはus、eu、uk、me、...のような トンガ のccTLDです。次のドットは、ルートドメインのサブドメイン。実際、xyz.comは実際にはxyz.com.です。
基本的に、彼らが行ったことは、単にWebサーバーを指すAレコードを追加することです。彼らは、to.とそのすべてのサブドメインのクエリに応答する責任を負うネームサーバーを所有しているため、それを簡単に行うことができます。
事実の証明：
MehrdadAir:~ Mehrdad$ ping to.
PING to (216.74.32.103): 56 data bytes
Request timeout for icmp_seq 0
^C
--- to ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
MehrdadAir:~ Mehrdad$ telnet 216.74.32.103 80
Trying 216.74.32.103...
Connected to 216.74.32.103.static.sfo.hosting.com.
Escape character is '^]'.
GET / HTTP/1.0
Host: to.
User-Agent: Mozilla
HTTP/1.1 200 OK
Date: Thu, 03 Dec 2009 18:41:05 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_Perl/1.26
Connection: close
Content-Type: text/html; charset=ISO-8859-1
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>TO. -- Get Shorty URL</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<form method="post" action="/" enctype="multipart/form-data">
<table><tr><td>Enter a long URL:</td> <td><input type="text" name="url" size="50" /></td></tr><tr><td>Enter an optional name:</td> <td><input type="text" name="name" size="20" /></td></tr><tr><td> </td> <td><input type="submit" name="'Witz that URL!" value="'Witz that URL!" /></td></tr></table></form>
</body>
</html>
Connection closed by foreign Host.
PS：このスレッドの内容に基づいて、一部のインターネット事業者（ISPなど）が使用しているソフトウェアはに従っていないと確信しています。 ）仕様が正しく、たまたま慣例に従っている。これがおそらく、多くの人にとってドメインが壊れている理由です。
トップレベルのドメインにAレコードがあることはまれですが、完全に正当です。 「www.foo.com」と「foo.com」が異なるレコードを持つことができる方法を考えて、それをTongan ccTLD、.toまで適用します。
うん...
「telnet www.to 80」...「GET /」と入力すると機能します
「telnet www.to. 80」...「GET /」と入力すると機能します
「Telnet to 80」...接続を開くことができませんでした
"telnet to。80" ...接続を開けませんでした
そうそう、私はブラウザが助けてくれると思います。 m。
TLDであるため、example.comがAレコードを持つことができるのと同じように、IPアドレスを指すAレコードを持つこともできます。
編集：nslookupを使用したいくつかのテストによると、「to」のAレコードは「www.to」のAレコードとは異なるようですが、これが問題かどうかは完全にはわかりません。
誰かが.to全体を購入したようです。 TLD http://en.wikipedia.org/wiki/.to Mehrdadが言ったように、Aレコードを追加できます。私は彼らが追加しているだけだと思います。 www.toの終わりまで。これまでに何がTLDのルートでアドレス検索を行っているかを確認します。 。とにかく、すべてのドメインの最後に暗示する必要があります。serverfault.comを使用しない理由は、私が取得できないことです。 400 Bad Requestを返しますか？
私が試した2つのDNSサーバーの50％でしか機能しないため、TLDがAレコードを持つようにすべてのキャッシュDNSエンティティが準備されているわけではないようです。
それらのフレンドリーなブラウザは、その場合ドメインをwww.toに「修正」し、混乱を解消する助けにはなりません。
これはブラウザとは何の関係もありません。 「to」には、次のように単純なDNSリソースレコードがあります。
$Origin to.
@ SOA to. admin.to. ( ... )
@ A 123.4.5.6
ヘルプブラウザーは必要ありません。
$ curl -i "http://to./check"
HTTP/1.1 302 Found
Date: Thu, 03 Dec 2009 18:27:20 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_Perl/1.26
Location: http://madmw.tumblr.com/tagged/check <<<=== Actual URL
Transfer-Encoding: chunked
Content-Type: text/plain
TLD全体がIPアドレス（対DNS階層）にマップされているようです。試してください：
$Dig to.
...
to. 85265 IN A 216.74.32.103
...
ただし、他のTLDを確認してください。
$Dig as.
as. 600 IN SOA dca.tld.gdns.net. hostmaster.gdns.net.as. 56480 10800 1800 604800 21600
これがICANNのルールに従っているかどうかはわかりませんが、国全体のTLDのDNSにDNSを構成するだけの問題です。
簡単な答えは、Webサーバーの所有者が
to.
そのWebサイトの（追加）httpホストヘッダーとして。
ここでの問題は、一部のDNSサーバーが「to」と「to」を解決できることです。 （Google DNSは216.74.32.103と言っています）いくつかは単純にできません。
これは本当に新しいことではありません。 dot tkはこれを長い間提供してきました。 Tweak.tkを見てから、技術タブを見てください。彼らはそれを涼しくします http://tk./abcde もabcde.tkで、これはさらに短くなっています！
DNS仕様では、末尾のピリオドを使用してルートを示すこともできます（例：「a.b.c」および「a.b.c」）。同等ですが、後者はより明示的であり、アプリケーションによって受け入れられる必要があります。この規則は、TLD名が直接参照される場合に特に重要です。たとえば、「。COM」は、そのトップレベルドメイン「COM」を指すための一般的な用語になっています。 「COM」がトップレベルのドメイン名であることを示しているので、DNSについて話す場合、厳密かつ技術的に正しいでしょう。
だから問題はなぜそれがうまくいかないのかということです。答えは、Verisignがワイルドカードを.comに導入することを決定した後です。数年前のゾーンでは、bindの開発者は「委任専用」ゾーンの概念を導入しました。委任のみのゾーンでは、NSレコードの接着剤に劣らないAレコードはリゾルバーに受け入れられず、クライアントはNXDOMAINを返します。
したがって、厳密なプロトコルの観点からは、「to」で問題ありません。 Aレコードを持つDNS名。実際には、一部のISPの顧客には機能しません。
あなたは置くかもしれません：
zone "com." { type delegation-only; };
named.confで、.comに対してのみこれをオンにします。ドメイン、またはすべてのTLDで有効にするが、オプションに追加してそれらの一部を除外する場合{}ブロックは次のようになります。
root-delegation-only exclude { "de"; "to"; };
ここには、「to」など、一般的に許可されている「承認済み」ドメインの長いリストがありますが、BOFHishの具合によっては、これをさらに制限する場合があります。
リンクを最初にメモしてから、また最初にこの返信を書いてからリンクは移動しましたが、これは私が指摘したものだと思います： http://www.isc.org/software/bind/delegation-のみ
たぶん、OpenDNSと関係があるかもしれません。 OpenDNSを使用している自宅のコンピューターで、nslookupがIPアドレスを返します。私の職場では、VPN経由のコンピューターは解決せず、 http://to./ は何もしません。
OpenDNSのバグである可能性があります...これは、ショートカットとして 'mail'のように入力し、 ' http://webmail.mydomain.com 'Webサイトとして、定義したネットワークから' mail 'と入力すると、' http://webmail.mydomain.com 'に移動します。おそらく誰かが自分のネットワークを0.0.0.0として定義し、「to」をショートカットとして作成しましたか？それが事実なら、それはOpenDNSユーザーを利用する大きな機会です！
示されているように。 "に。"完全修飾ホスト名を指定する有効な方法です。 「通常の」DNS名の他の部分は必要ありません。
「Dig to。」のこのスクリーンキャプチャを見ると、「to」が表示されます。 216.74.32.103のAレコードがあります。
トンガが何かと引き換えにこれを許可することを決めたと思います（コールド、ハードキャッシュ？）
おそらくさらに不可解な質問は、なぜ地球上で彼らがへのリンクを短くしないのかです
http://go.to/S50kahUN
のではなく
http://www.to/S50kahUN
警告：私はDNSについて知っているだけで危険です。しかし、これが私が知っていることです：
.はルートドメインです。 toはその1つ下です
これはもっと理にかなっています（そしてうまくいきます！）：
それで、基本的に、wwwの部分を省略していて、ブラウザーがそれを推測していますか？
基本的なDNSの概要：
http://developer.yahoo.net/blog/archives/2009/11/an_engineers_gu.html
http://to./ が http://www.to./ とは異なるサイトを生成することを示すために、一部の画面キャプチャー†：
http://to./とhttp://www.to./（クリックして拡大）
IPアドレスも異なります。現在は216.74.32.103と74.54.218.210です。
つまり、2つのURLが同じである場合、ブラウザは実際に混乱しており、おそらく両方でwww.toを表示しています。
†http://www.to./は、ブラウザに特別なことを試みないように指示するために末尾のドットを必要としない可能性が高いため、 http://www.to と同じです。ここで、wwwはおそらく セカンドレベルドメイン として、無関係な他の会社によって登録されています。
TOでwhoisを実行します。ドメイン名は、IANAが所有していることを示します。
Domain Name: TO
Registrar: INTERNET ASSIGNED NUMBERS AUTHORITY (2)
Whois Server: whois.iana.org
Referral URL: http://www.iana.org
Name Server: AUTH02.NS.UU.NET
Name Server: COLO.TO
Name Server: NS-TO.RIPE.NET
Name Server: NS1.IAFRICA.COM
Name Server: TONIC.TO
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Status: serverDeleteProhibited
Status: serverTransferProhibited
Status: serverUpdateProhibited
Updated Date: 23-oct-2008
Creation Date: 18-dec-1995
Expiration Date: 31-dec-2099