知れば知るほどDNSは不思議の海へ 覗いてみればディープな世界DNS（2）：TCP/IPアレルギー撲滅ドリル（7）（3/3 ページ）
DNSの現場を見てみよう
DNSサーバにはどんな種類がありますか？
図3を見て気付いたことはないでしょうか？
プロバイダのネームサーバのように、得られた振り分け先情報をたどっていって、最終的な答えを求めるもの。問い合わせを受ける.jpなどのネームサーバのように、自分が知っている答えだけを答えるもの。同じネームサーバといいながら、ずいぶん機能が違っています。
実はネームサーバはその機能で3種類に分類されています。.jpのネームサーバなど問い合わせを受けるものを「コンテンツサーバ」。プロバイダのネームサーバのように振り分け先情報をたどっていくものを「フルサービスリゾルバ」。そして問い合わせ元のPCが持っているフルサービスリゾルバへの問い合わせを行うプログラムを「スタブリゾルバ」といいます。イカメしい名前はともかく、それぞれ機能が違うということは、図3の説明で分かっていただけましたよね。
なお実際のネームサーバの中には、コンテンツサーバとフルサービスリゾルバを兼ねたものも多くあります。
セカンダリサーバって何ですか？
先ほどルートサーバの話で、13台のサーバが危険と負荷を分散していると書きました。実はこれと同じようなことが、各段階のネームサーバでも行われているんです。例えば先の説明では、atmarkit.co.jpのネームサーバが1つだけのように書きましたが、実際には3台のネームサーバが用意されています。
このように、通常ネームサーバは2台以上用意して、停止の危険と負荷を分散することになっています。セカンダリサーバとは、このときに使う2台目以降のマシンを指していう言葉です。
なおセカンダリという言葉から、メインのネームサーバが壊れたときに働くように聞こえるかもしれませんが、そうではありません。atmarkitの例でいえば、外部からの問い合わせは、3台あるネームサーバに分散するようになっています。
これは、co.jpのネームサーバの回答に、atmarkitのネームサーバ3台分の情報が含まれていて、前図のプロバイダのネームサーバが、その中から適当なものを選択するような仕組みになっているからです。
ところでDNSのプロトコルってどうなっているんですか？
DNSのプロトコル自体は、どこを見てもあんまり話題には上らないようです。確かにDNSでは分散協調の仕組みが一番大切ですから、それは致し方ないのかもしれません。ただ、それではちょっと気持ち悪いので、ここではごく簡単にDNSのプロトコルも紹介しておきましょう。
DNSはポート53番を使います。この連載でここまで登場した各プロトコルは、通信途中で誤りや抜けが発生すると、それを訂正したり、送り直したりする機能を持った、TCPという手順でパケットをやりとりしていました。しかし、DNSはそういった仕組みが一切ないUDPという手順でパケットをやりとりします。
重要なDNSなのに、なぜ確実性の低いUDPを使うんでしょうか？ これはおそらく問い合わせを受けるサーバ側の負荷を考慮したものと考えられます。ルートサーバのように非常に負荷が高くなるサーバでは、誤りを訂正したり、抜けを再送する処理をすることがさらに負荷を高くして、新しい処理が一切進まない状況を生み出す可能性があります。"プロトコルを設計したときに、そういった状況を防ぐためのある種の割り切りがあった"そういうふうに考えられます。
DNSパケットは図4のような構造になっています。最初にヘッダがあり、その後に、問い合わせの内容、回答の内容、ネームサーバの情報、追加情報が続きます。ヘッダは必須で、そこに問い合わせに関するさまざまな制御情報が含まれます。ヘッダには、ヘッダ以外の部分に含まれる情報数が含まれていて、全体の長さは可変長です。
ID: 問合せを識別するための任意の値
QR: 問合せ=0、回答=1
Opcode: 問合せ種別（通常は0）
AA: オーソリティのある回答=1
TC: 制限長を超えたため切り捨てあり=1
RD: 再帰的解決要求=1
RA: 再帰的解決可能=1
RCODE: 結果コード（0=エラーなし、他=エラーコード）
ネームサーバへ問い合わせるときは、QRを0として、「問い合わせ」の部分に問い合わせ内容を含んだパケットを送ります。ネームサーバからの回答は、QRが1になり、「問い合わせ」のほかに「回答」を含んだパケットが送り返されてきます。
DNSもtelnetで接続テストができますか？
いいえ。DNSは残念ながらtelnetでの接続テストができません。telnetを使った接続テストは、TCPという通信手順を使っていて、コマンドが文字で構成されているプロトコルの場合に試してみることができます。しかしDNSは、UDPという通信手順を使っているうえに、文字だけのコマンドで動作をコントロールできるようにもなっていません。そのため、試すことができないのです。
DNSの動作を確認するには、普通、nslookupというツールを使います。Linuxなどでは、さらに新しいツールがあるようですが、UNIX系OSでも、Windows系OSでも現在共通して利用できるのはnslookupですので、最初にこれを試してみるのがいいでしょう。
なおnslookupの詳細については、ここでは説明を省略します。サーチエンジンで「nslookup 使い方」などのキーワードで検索すれば、平易な説明を簡単に見つけることができますので試してみてください。また当サイトの「nslookup ‐ DNSサーバに名前解決の問い合わせを行う」にも、非常に詳しい説明があるので、より深い興味のある方には参考になると思います。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。