電子メールの秘密 第2回

メールの宛先となるサーバの見つけ方

メールを支えるドメイン名とDNSの仕組み

DNSの階層構造

　DNSの階層構造は、上から順番に、

• ルートドメイン（.）
• トップレベルドメイン（Top Level Domain）
• セカンドレベルドメイン（Second Level Domain）
• サードレベルドメイン（Third Level Domain）

といった具合になっている（図1）。そして、これらをルートから順番に並べたものが、ドメイン名となる。たとえばwww.ascii.co.jpというホスト名を例にすれば、.jpがトップレベルドメイン、.coがセカンドレベルドメイン、.asciiがサードレベルドメイン、そしてwwwがホスト名だ（ルートは省略する場合が多い）。

図1　ドメインの階層構造

　トップレベルドメインには、.jpや.nz（ニュージーランド）などのような国名を表わす「ccTLD（country code TLD）」のほか、.comや.orgなどの「gTLD（generic TLD）」がある。2007年に始まった.asiaもgTLDだ（表1）。

表1　代表的なトップレベルドメイン

　セカンドレベルドメインには、企業用の.coやネットワークサービス提供者用の.ne、政府機関用の.goなどがある。こちらも代表例を表2に挙げた。

表2　代表的なセカンドレベルドメイン（.jp）

リゾルバによる名前解決の手順

　ではリゾルバは、この階層構造を使って、どのように宛先メールサーバのIPアドレスを得るのだろうか。ここでは[e-mail]宛のメールを送信するケースを例に、リゾルバの動作を見ていこう。

　まず、送信メールサーバ（MTA）からascii.co.jpの名前解決を依頼されたリゾルバ（これをスタブリゾルバという）は、このドメイン名を「ローカルDNSサーバ」に転送する。ローカルDNSサーバ（図2）は、企業ネットワークであれば社内で、個人であればISPが管理している場合が多い。このローカルDNSサーバのリゾルバは、最終的なIPアドレスを得るまで問い合わせを続けるリゾルバであり、これを「フルサービスリゾルバ」と呼ぶ。

図2　ローカルDNSサーバの動作

　ローカルDNSサーバのリゾルバ（フルサービスリゾルバ）は、ルートネームサーバに「ascii.co.jpのIPアドレスを教えてください」と問い合わせる。ルートネームサーバは、世界中で13サイトが運用されており、各サイトにはA.ROOT-SERVERS.NETからM-ROOT-SERVERS.NETまで名前が付けられている。これらのIPアドレスは、「ルートヒントファイル」として配布されており、DNSサーバに登録するようになっている。ちなみに日本国内にあるのはM.ROOT-SERVERS.NETとなる。なお、毎回ルートネームサーバに尋ねると負荷が高くなるので、通常は得た結果をキャッシュして次回の問い合わせに備えるようになっている。

　ローカルDNSサーバのリゾルバの問い合わせに対して、ルートネームサーバが直接IPアドレスを教えてくれるわけではない。通常、ルートネームサーバからは「私は直接知らないので、こちらに聞いてください」と、別のDNSサーバを紹介してくる。次に、ルートから紹介されたサーバに「ascii.co.jpのIPアドレスを教えてください」と尋ねると、再び別のDNSサーバを紹介される。この問い合わせを何度か繰り返すことで、宛先メールサーバが所属するドメインを管理するDNSサーバにたどり着く。

　するとローカルDNSサーバは、今度は「メールサーバのホスト名を教えてください」と問い合わせる。DNSサーバには、ホスト名とIPアドレスの対応表（これをリソースレコードという。おもなリソースレコードは表3）のほかにも、メールサーバのホスト名や優先順位などが登録されている。これらの情報を受け取ったローカルDNSサーバは、優先順位の高いメールサーバのIPアドレスを尋ね、DNSサーバからの応答を得る。このIPアドレスをスタブリゾルバに返せば、送信元メールサーバから宛先メールサーバに対してメールが送れるというわけだ。

表3　DNSサーバに登録されているおもな情報