nslookupコマンドの使い方
windowsにはdigコマンドがついていないため、DNSに関する調査をしたい場合は、nslookupコマンドを使用する。
以下の記載内容は、Windows7Professional SP1付属のnslookupを使用している。
■ 長いので目次
1. 非対話型と対話型
2. nslookupの書式、オプション
3. 問い合わせレコード・ドメインの最後にはピリオドをつける
4. 問い合わせるレコードのタイプ(種類)を変える
5. DNSの問い合わせに対する詳細な情報を見る
6. 問い合わせ先のDNSサーバが、そのドメインのコンテンツサーバかを調べる
7. セカンダリDNSサーバが正常に動作しているかを確認する
8. TCP53番での問い合わせに応答するかを調べる
9. TCPフォールバックされているかを調べる
10. ゾーン転送ができるか確認する
11. nslookupでのエラー一覧
1. 非対話型と対話型
nslookupコマンドは、非対話型による方法と対話型による方法がある。
このサイトでは、主に対話型による方法で説明している。
2. nslookupの書式、オプション
オプションの詳細は、help や ? で検索するが良し。
3. 問い合わせレコード・ドメインの最後にはピリオドをつける
nslookupの場合、問い合わせレコードやドメインの最後に [.](ピリオド)がついていないものはFQDNと認識せず、勝手に今のドメイン名を補完する仕組みになっている。
nslookupで詳細情報を見たい場合やWireSharkなどでパケットキャプチャをする場合、不要な情報が含まれることになり、また、ドメインを補完したことによって
問い合わせ結果が誤っていたりすることもある。
よって、ピリオドは付けるようにしたほうが絶対に良い。
ただし、ゾーン転送の確認においては、ピリオドがないほうが（個人的に）うれしい出力結果になることもある。
なお、[nosearch]と[nodefname]オプションをつけてドメイン補完をさせないこともできるが、正確な結果が出力されいないこともある。
以下、①～④でその例を示す。
① debugやd2で詳細情報を見たとき、不要な問い合わせをしている
(ピリオドの有無に関わらず、最初に行っている問い合わせ先DNSの逆引きは、通常の動作）
② メイン補完がない状態での問い合わせをしないことがある
以下の例では、ピリオドがない場合、ドメイン補完をしない問い合わせをしていないため、Answerが返ってこない。
（全てではなく、どうやらTLDの問い合わせのみっぽい）
しかも、結果に記載されている問い合わせ内容（「 jp を見つけられません」）と実際の問い合わせ内容(「jp.example.com」）が異なるので、
余計にわけわかめになる。
また、ドメイン補完を無効にした場合も同様に回答なしとなった。（そもそもDNSサーバに問い合わせていない）
③ コンテンツDNSサーバに問い合わせたときに、エラーになる
ドメイン補完されるため、コンテンツDNSサーバの管理外のドメインになり、当然のことながら拒否される。
こちらも②と同様に、結果に記載されている問い合わせ内容（「 jp を見つけられません」）と実際の問い合わせ内容(「jp.example.com」）が異なるので、
コンテンツDNSサーバが自身が管理している情報を拒否していると誤認してしまう。
また、ドメイン補完を無効にした場合も同様に回答なしとなった。（そもそもDNSサーバに問い合わせていない）
④ ゾーン転送確認のときは、ピリオド無しのほうがよさげ
ピリオドがない場合、左辺側はFQDN表記では無いので（たぶん多くの人が）うれしい。
4. 問い合わせるレコードのタイプ(種類)を変える
デフォルトの問い合わせレコードは、AとAAAAとなっているので、SOAやNS、MX、TXT、PTRの問い合わせがしたい場合は、set typeで変更する必要がある。
5. DNSの問い合わせに対する詳細な情報を見る
set debugもしくはset d2オプションを指定することで、digコマンドのような詳細情報を表示させることができる。
6. 問い合わせ先のDNSサーバが、そのドメインのコンテンツサーバかを調べる
回答結果に、[権限のない回答]と表示される場合は、問い合わせ先DNSサーバはそのドメインのコンテンツDNSサーバではなく、キャッシュを返しているだけである。
よって、回答結果に[権限のない回答]が表示されていなければ、問い合わせたドメインのコンテンツDNSサーバからの回答であるといえるが、確実なのは、[set debug]
もしくは[set d2]オプションをつけて、ヘッダーフラグに[auth]があることを確認することである。
7. セカンダリDNSサーバが正常に動作しているかを確認する
セカンダリDNSが適切に動作しているかの条件として、
① セカンダリDNSサーバが、そのドメインの上位のDNSサーバでも委譲先DNSサーバ名として登録されていること。
② セカンダリDNSサーバが、そのドメインの問い合わせに応答していること。
③ セカンダリDNSサーバが持つそのドメインのシリアル番号が、プライマリDNSサーバと一致していること。
④ NSレコードにセカンダリDNSサーバが登録されていること。
あたりを確認する。
なお、[適切に動作している]
≒
[ゾーン転送が正常にできている]な点に注意する。
（ゾーン転送ができていなくても、セカンダリDNSサーバはそのゾーンの期限が切れるまでは回答を返すため）
ゾーン転送もできていることを確認したい場合は、10.を参照すること。
8. TCP53番での問い合わせに応答するかを調べる
DNSサーバへの問い合わせは、通常、UDP/53番ポートに対して行われている。
しかし、DNSサーバではパケットサイズが大きくUDPで返すことができない場合、TCP53番に切り替えて応答を返す仕組みがある。
また、TCP53番は、プライマリDNSサーバとセカンダリDNSサーバとの間のゾーン転送でも使用するようになっている。
TCP53番が許可されているかどうかについては、nslookupコマンドを使って調査することができる。
少なくとも、セカンダリDNSサーバからプライマリDNSサーバに対してTCP53番での問い合わせができなければ、ゾーン転送は失敗している。
9. TCPフォールバックされているかを調べる
DNSでは、回答のパケットサイズが大きすぎてUDPでは返せない場合、DNSサーバ側はTCPで問い合わせをし直すように回答を返し、クライアント側はTCPで問い合わせし直す仕組みになっている。
これをTCPフォールバックというが、この機能の仕組みをnslookupコマンドで見ることができる。
10. ゾーン転送ができるか確認する
lsオプションを使うことで、指定のDNSサーバに対してゾーン転送ができているかどうか確認できる。
実際の現場では、セカンダリDNSサーバ(windows)からプライマリDNSサーバに対しての確認に使用される。
もし、セカンダリDNSサーバ以外からゾーン転送ができるようであれば、プライマリDNSサーバの管理者へ"サーバの運用ができていない"とはっきり言ってあげると良い。
11. nslookupでのエラー一覧
とりあえずnslookupでよく見かけるエラーを再現してまとめてみました。
既定のサーバ Unknown , DNS request timed out , Non-existent domain , Query refused , Unspecified error , Server failed
