nslookupコマンドの使い方

windowsにはdigコマンドがついていないため、DNSに関する調査をしたい場合は、nslookupコマンドを使用する。以下の記載内容は、Windows7Professional SP1付属の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でよく見かけるエラーを再現してまとめてみました。