http://to./が開けるしくみ

不思議なURLの名前解決について、今回はsyonbori_techさんのブログ『しょんぼり技術メモ』からご寄稿いただきました。

http://to./が開けるしくみ
『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コマンドは、「知りたい情報の種類(A)」、「対象のホスト名文字列(to.)」、「”@”＋問い合わせるDNSサーバ (@8.8.8.8)」という引数を取ります。

ホスト名文字列からIPアドレスを取得する場合は、「Aレコード」を問い合わせることになります。

その結果、「”to.a”に対応するIPアドレスは”216.74.32.107″ だ」という回答が返ってきました。これにより、ブラウザは216.74.32.107のポート80番に接続し、HTTP通信を行います。たったこれだけです。

補足：jpやcomの場合は？
.jpや.comなど、いわゆる普通のドメインの場合はどうかを見てみましょう。
——
　dig A jp. @8.8.8.8
——

“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.
——

“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
——

このようにして、OSから問い合わせを受けたDNSサーバーは、”to.”に対応するAレコードを取得することができた(ANSWER SECTION)。

(4) DNSサーバーは、OSに対して「”to.”に対応するIPアドレスは”216.74.32.107″ だ」と応答する。サーバーによっては、今後の問い合わせに対して高速に応答できるよう、この結果を覚えておく（DNSキャッシュ）

(5) OSはブラウザにこの応答を伝え、ブラウザはこのIPアドレスに対して接続を行う。

執筆： この記事はsyonbori_techさんのブログ『しょんぼり技術メモ』からご寄稿いただきました。

文責： ガジェット通信

******
ガジェット通信では、皆さんの原稿を募集しています。
https://getnews.jp/post
******

■最近の注目記事
拝啓：日本がデフレだデフレだと騒いでる方々へ
「この部屋にテレビはありません！」
野菜が「安全」だった時期というのは、いつですか？