連載：ネットワーク・コマンドでトラブル解決（7）

DNSの設定は正しいか？
〜nslookup／ipconfig〜

加地眞也
2002/3/21

関連するコマンド nslookup ipconfig

■DNS設定と利用

　DNS（Domain Name Service）は、インターネットの根本ともいえる基本的なサービスだ。ホスト名とIPアドレス間の名前解決などは、インターネットの「ディレクトリ・サービス」の先駆けであり、これなくしてインターネットの運用はありえない。

　基本的な概念や製品個々での設定方法については、「連載：DNSの仕組みと運用」などの関連記事を参照いただくとして、ユーザーとして利用する場合の設定は簡単だ。

画面1　Windows 2000でのDNSサーバ設定例

●Linuxの/etc/resolv.confファイルの例

domain          example.com nameserver      127.0.0.1 nameserver      192.168.10.100

　Windowsでは「ネットワークとダイヤルアップ接続」のプロパティに、Linuxでは/etc/resolv.confファイルに、それぞれ使用するDNSサーバ（フルサービス・リゾルバ）名や所属するドメイン名を指定することで、そのホストのDNSクライアント機能を設定できる。通常、そのホストでリゾルバ（DNSクライアント）機能を使用する際に、すべてのアプリケーションに反映されるメインの設定となる。Windowsでは、ipconfigコマンドから使用されるDNSサーバを確認することもできる。

　または、DHCP機能でDNSサーバ名やドメイン名を自動設定することも可能だ。

図1　DNSの動作概要。図の青い矢印が、DNSプロトコルのやりとりされている部分（図版をクリックすると拡大表示します）

　リゾルバ機能をエミュレートするnslookupコマンドは、この仕組みの中でほかのアプリケーションが実行する名前解決を、まったく同じように実行するためのコマンドだ。通常のアプリケーションでは、プロパティやresolv.confファイルの設定に沿った解決を行うだけだが、nslookupコマンドではDNSサーバの切り替えなど、細かな設定が独自に行える。

　また、Windows 2000のipconfigコマンドではローカルのDNSキャッシュの表示を行える。このキャッシュは、DNS Clientサービスが管理する、これまでに名前解決した結果の履歴だ。複数のアプリケーションで効率よく共有することで、パフォーマンス向上が実現できる。DNS Clientサービスは、一種のDNSサーバ（キャッシュ・サーバ）である。DNS Clientサービスを動かしていない場合には無効となり、単純なスタブ・リゾルバ機能のみを提供する。

■DNSの処理フロー

　DNSの基本仕様はRFC1034／RFC1035で定義されている。問い合わせと回答を表す一連のDNSメッセージを、DNSサーバとDNSクライアントが交換し合って、名前解決を行う。

図2　DNSメッセージのフォーマット。セクションの部分は、「問い合わせ」か「回答」などによって、含まれる種類と数は任意となる。問い合わせでは、通常Questionセクションのみが含まれている。また、1つのセクションには、複数のレコード情報が格納される可能性がある。例えば、回答として複数のAレコードやNSレコードを含む場合などだ（図版をクリックすると拡大表示します）

　クライアント→サーバへの問い合わせと、サーバ→クライアントへの回答のためのDNSメッセージ構造は、同じフォーマットが定義されている。もちろん、問い合わせか回答かによって、含まれるデータ・セクションは異なる。

　まずヘッダでは、このデータが問い合わせなのか回答なのかなどを表す。特にフラグでは、順に含まれる以下のようなフラグやパラメータを用いて、クライアント／サーバ双方に必要な問い合わせ／回答種類やステータスを通知し合う。

●QR：1ビット
　問い合わせ時には0を、回答時には1をセットする

●オペレーション・コード^＊1（OPCODE）：4ビット
　この要求の具体的内容を示す

0：標準問い合わせ
1：逆順問い合わせ（レコードの左辺から右辺ではなく、逆に右辺から左辺の検索。例えば、AレコードのIPアドレスからホスト名を検索するなど、いわゆる逆引きとも異なることに注意）
2：サーバ・ステータス問い合わせ
3：拡張用の予約
4：DNS Notify（RFC1996）
5：DNS Update（ダイナミックDNS）（RFC2136）
6〜15：拡張用の予約

●Authoritative Answer（AA）：1ビット
　回答にオーソリティがある場合1をセットする

●Trancation（TC）：1ビット
　回答データが不完全であることを示す。一般的には、UDPではサイズが足りないため、改めてTCPで問い合わせることが求められる

●再帰検索要求（RD）：1ビット
　クライアントからの再帰検索に対する要求

0：インタラクティブ問い合わせ
1：再帰問い合わせ（リカーシブ）

●再帰検索可能（RA）：1ビット
　サーバからの再帰検索に関する提示。フルサービス・リゾルバとして動作可能かどうかを示す

0: 再帰検索不可
1: 再帰検索可能

●予約：1ビット
　将来のための予約

●Authentic Data（RFC2535）
●Checking Disabled（RFC2535）

●レスポンス・コード^＊1（RCODE）：4ビット

0：正常（NoError）
1：フォーマット・エラー（FormErr）
2：サーバ・エラー（ServFail）
3：問い合わせされた名前は見つからない（NXDomain）
4：その問い合わせは実装していない（NotImp）
5：何らかの理由による拒否（Refused）
など

＊1オペレーション・コード、レスポンス・コードなどの種類については、IANAのサイトに定義されている

　一方、セクションは、実際にDNSを検索するキー・データや結果を格納するためのデータ・エリアだ。

●Questionセクション
　問い合わせ内容を格納する

●Answerセクション
　回答内容を格納する

●Authorityセクション
　この回答にオーソリティを持つDNSサーバ名（NSレコード）が格納される

●追加セクション
　追加情報。例えば回答されたMXレコード・ホストやNSレコード・ホストのIPアドレス（Aレコード）など

　問い合わせでは、Questionセクションに検索キーを格納してサーバへ渡される。サーバでは検索結果をAnswerセクションへ格納してクライアントへ回答する。Answerセクションや追加セクションなどに格納されるデータは、DNSサーバが管理するレコード・データ（Resource Records：RR）そのものである。また、セクションには複数のレコード・データが格納される場合もある。

　下記は、実際の名前解決（Aレコード検索）時の様子だ。

図3　名前解決時のフロー（図版をクリックすると拡大表示します）

　Answerセクションによって問い合わせられたwww.example.netのIPアドレスを回答するとともに、そのデータにオーソリティを持つ（ゾーン情報の元）NSサーバ名とIPアドレスを、Authorityセクションと追加セクションで通知している。また例では、再帰検索が指定されているので、DNSサーバはフルサービス・リゾルバとして動作して、ほかのDNSサーバー（ドメイン・ツリー）から再帰検索を行っている。DNSサーバが再帰検索を許可されておらず、自身が知らない情報を問い合わされた場合には、エラー（RCODE＝3）が返されることだろう。Questionセクションに示される検索キーのタイプがPTRレコードやSOAレコード、MXレコードなどに変更されることで、DNSサーバのさまざまなレコードの検索も可能になる。

　ここでは、DNSクライアント〜フルサービス・リゾルバ間での例だが、フルサービス・リゾルバからドメイン・ツリーの各DNSサーバへの検索では再帰検索ではなく、インタラクティブ検索（そのDNSサーバの管理するゾーン情報だけの検索）が指定されるだけで、ほとんど違いはない。

　DNSプロトコルは、通常のクライアントからの名前解決時のほか、プライマリDNSサーバからセカンダリDNSサーバへの「ゾーン転送」時にも同様に使用される。プロトコルの理屈はまったく同様だ。

図4　ゾーン転送時のフロー（図版をクリックすると拡大表示します）

　セカンダリDNSサーバがDNSクライアントとして動作して、プライマリDNSサーバが保持する該当ゾーンの全データを要求し、反映を行う。名前解決時との違いは、問い合わせ時のQuestionセクションでTypeとしてAXFR（完全転送）が指定されているだけだ。通常はデータ量が多いため、TCP接続を用いてAnswerセクションにゾーンのレコード情報をまとめて送信する（古い実装ではAnswerセクションではなく、複数のDNSデータに分割される場合もある）。

■DNS Uodate（ダイナミックDNS）

　DNS Update（RFC2136）は、「ダイナミックDNS」の名でよく知られている。これまでのDNSでは、ローカルのゾーン定義ファイルを読み込んでゾーン情報を変更する、つまり静的な更新しか行えなかったが、DNS Updateではクライアントなど外部からの要求に応じてゾーン情報（レコード）を追加／削除する仕組みが提供される。「動的DNS」などとも呼ばれる。

図5　DNS Updateメッセージのフォーマット（図版をクリックすると拡大表示します）

　DNS UpdateのためのDNSメッセージは、オリジナルのメッセージともフォーマットが多少異なる。これは、DNS Updateはクライアントからサーバへのデータ更新が可能かどうかの確認と変更要求という、これまでにはなかった機能が必要だからだ。ヘッダはオリジナルと同じだが、セクションは以下のデータから構成される。

●Zoneセクション
　更新対象とするゾーン名

●Prerequisiteセクション
　必要条件。ここに示した条件を満たすかどうかをサーバが判断し、更新するかどうかが決定される。またはZoneとPrerequisiteセクションのみを指定して、レコードの存在チェックなどにも使用される

●Updateセクション
　更新するレコード情報

●追加セクション
　追加で必要となる付帯情報

　DNS Updateのフローは大きく2段階に分けられる。

　クライアントは、まずDNS検索でUpdateしたいドメインのDNSサーバを調べたうえで、そのDNSサーバに対して必要条件（Prerequisite）を検索する。これは、登録したいホスト名やIPアドレスがすでに存在していないかどうかをチェックするフェイズだ。Prerequisiteセクションで必要条件を指定する。必要条件は通常のレコード情報と酷似しているが、レコード・タイプやクラスなどの指定の仕方によって、以下のような種類の指定ができる。

●RRset Exists（Value Independent）
　RR名とタイプが一致するレコードがZoneセクションで示したゾーンに存在していること。またTTLとデータ・サイズを0、データはなし、として指定する

●RRset Exists（Value Dependent）
　この指定したレコードが存在していなければならない（つまりこのレコード自体が存在を確認したいレコードそのもの）

●RRset Does Not Exist
　RR名とタイプが一致するレコードが、Zoneセクションで示したゾーンに存在していないこと。またTTLとデータサイズを0、データはなし、クラスは'none'として指定する

●Name Is In Use
　RR名が一致するレコードが存在していること。タイプは問わない。TTLとデータサイズを0、データはなし、タイプは'ANY'として指定する

●Name Is Not In Use
　タイプを問わず、RR名が一致するレコードが存在していないこと。TTLとデータサイズを0、データはなし、タイプは'ANY'、クラスは'none'として指定する

　これらの結果は、通常のDNSの回答メッセージとして示される。すべての条件を満たした場合のみ、RCODE＝0（正常）が返答される。そのほかのエラーのために、RCODEとして以下のコード番号が追加されている。

6：登録要求されたのと同じ名前のレコードが既に存在している（YXDOMAIN）
7：同じレコードがすでに存在している（YXRRSET）
8：同じレコードは存在していない（NXRRSET）
9：DNSサーバーがZoneセクションで示されたゾーンにオーソリティを持っていない（NOTAUTH）
10：指定された名前とZoneセクションで示されたゾーンのドメイン名が一致していない（NOTZONE）

　次に実際のレコード登録が行われる。Updateセクションに登録したいレコードを格納するとともに、やはり重複登録などを避けるために必要条件もPrerequisiteセクションで指定する。正常に登録されれば、RCODEが0として返答されるはずだ。AレコードとPTRレコードをそれぞれ登録したい場合には、Prerequisite+Update要求も2回実行されることになる。またここでは新規登録時の例を示したが、単に定期的にクライアントが自身の情報を更新したいだけの場合には、Prerequisite+Update要求のみ行われることになるだろう。

　なお、DNS Updateには更新要求自体は定義されていない。レコードを削除したうえで新規登録を要求することになる。レコード削除のためには、レコードのほかの部分を一致させたうえで、クラスが'ANY'でTTLとデータサイズ（LENGTH）が'0'、リソース・データがなし、となるレコードをUpdateセクションに指定すればよい。またさらに、タイプを'ANY'とすることで、同じRR名を持つレコードをすべて削除できる。同じRR名とタイプを持つ複数のレコードが存在している場合には、クラスを'none'としてそのリソース・データとデータ￥サイズを指定すれば、特定のレコードのみを削除可能だ。

■DNS Notifyと差分転送

　DNS Updateの適用は、これまでのDNSにおける基本的な考え方にも大きく影響を及ぼす。典型的な例がプライマリ〜セカンダリDNSサーバ間のゾーン転送時の問題だ。

　従来のゾーン転送では、プライマリが指定したゾーン情報の更新間隔に従って、セカンダリがプライマリから定期的に、すべてのゾーン情報の転送を行う。これは、ゾーン情報はあまり変更されることが多くない「静的」データであるという前提があったからだ。しかしDNS Updateでは、より頻繁にゾーンが更新されるかもしれない。より短い更新間隔でなければ、セカンダリは最新状態を保てなくなるだろう。また、DNS Updateで更新されるのはレコードの単位だ。すべてのレコードが変更されていないのに、すべてのゾーン情報を転送するのは効率的ではない。

　その1つ目の解決策がDNS Notify（RFC1996）だ。DNS Notifyは従来のゾーン転送とは逆に、プライマリからセカンダリに対するゾーン転送開始を指示するための通知だ。これにより、DNS Updateによってゾーン情報が更新されたプライマリから遅滞なく、セカンダリの情報更新も保証できる。

　差分転送（IXFR：RFC1995）は常にゾーン情報全体を更新するのではなく、DNS Updateなどで更新されたレコードのみを転送する仕組みだ。これにより転送時間が短縮されるとともに、多数のセカンダリが存在するによるネットワーク帯域への負荷などの問題も低減できる。ただし、DNSサーバ側では、更新されたレコードを更新タイミングのシリアル番号とともに関連付けて把握されていなければならない。

関連ネットワーク・コマンド／ツール
	ipconfig 〜Windowsのネットワーク設定を確認する
	nslookup 〜DNSサーバに名前解決の問い合わせを行う

---

ネットワークトラブル解決法 - 通信の疎通を確認 - TCP／UDPの状態 - 設定は正しいか？ - DHCPの設定 - ルーティングの設定 - DNSの設定 - イーサネット通信確認

ネットワークコマンド使い方 - ping - route - traceroute - arp - ipconfig - netstat - ifconfig - nslookup

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）