2026年6月10日

2026年6月10日

nslookup と kdig の違いと使い分け|Windows の手元確認から、サーバーでの詳しい調査へ切り替える目安

nslookup は Windows に標準で入っていて「その端末から名前が引けるか」をすぐに確かめるのに向き、kdig はフラグ・TTL・DNSSEC・暗号化DNSまで含めて「DNS の答えの中身」を詳しく調べるのに向きます。最初は nslookup で症状を確かめ、TTL や権威サーバーの値、署名の有無が論点になった時点で kdig に切り替える、という使い分けが現実的です。この記事では、2つのツールの違い、nslookup の結果を読み違えやすい点、同じ確認を kdig で行う書き方、切り替えの目安を説明します。

2つのツールの出自と入手方法

nslookup は古くからある問い合わせツールで、Windows には OS の一部として入っています。Linux や macOS の nslookup は BIND に付属するもので、Debian・Ubuntu では bind9-dnsutils、RHEL 系では bind-utils に含まれます。同じ名前でも Windows 版と BIND 版は別の実装で、表示やオプションの細部が異なります。

kdig は、チェコの CZ.NIC が開発する Knot DNS に付属する問い合わせツールです。書式は dig とほぼ同じで、TLS や HTTPS を使った暗号化DNSの問い合わせにも対応しています。パッケージ名は Debian・Ubuntu では knot-dnsutils、Fedora などでは knot-utils、macOS の Homebrew では knot が一般的です(2026年10月現在)。Windows 向けの公式な実行ファイルは用意されていないため、Windows で使う場合は WSL の Linux 環境に入れるのが手軽です。

何が違うのか

違いを一覧にすると次のとおりです。

観点 nslookup kdig
入手のしやすさ Windows に標準搭載 パッケージの追加が必要
TTL の表示 通常は表示されない(-debug で表示) 常に表示
応答のフラグ(aa・ad など) -debug で一部を表示 常に表示
DNSSEC のレコード 種別を指定すれば取得は可能 +dnssec で署名ごと取得、ad フラグも確認できる
暗号化DNS(DoT・DoH) 非対応 +tls、+https などで対応(版による)
スクリプトでの利用 出力が OS や版で揺れやすい +short などで出力を絞れる

どちらも DNSSEC の検証そのものは行いません。kdig で見える ad フラグは、問い合わせ先のキャッシュサーバーが検証に成功したという印です。手元で検証まで行いたいときは、BIND の delv など別のツールを使います。

nslookup の結果を読み違えやすい点

nslookup は手軽な反面、表示の意味を取り違えやすいツールです。特に Windows 版では次の点に注意します。

  • 冒頭の Server: と Address: は、問い合わせたキャッシュサーバーです。そのサーバーの逆引きができないと名前が UnKnown と表示され、タイムアウトの表示が出ることもありますが、目的の名前の解決とは別の話です。
  • 「権限のない回答」(英語版では Non-authoritative answer)は、キャッシュサーバーが答えたという意味で、エラーではありません。
  • 名前の末尾にピリオドを付けないと、端末に設定された DNS サフィックスを付けた名前を先に問い合わせることがあります。社内ネットワークで意図しない答えが返るときは example.com. のように末尾にピリオドを付けて比べます。
  • Windows の nslookup は自分で DNS サーバーに問い合わせるため、hosts ファイルや OS の DNS キャッシュを使いません。ブラウザで開くサイトと nslookup の答えが違う場合は、hosts ファイルや OS のキャッシュを確認します。OS と同じ経路で確かめたいときは、PowerShell の Resolve-DnsName も使えます。

TTL を見たいときは -debug を付けます。

# 問い合わせ先を指定して NS を引く
nslookup -type=NS example.com 8.8.8.8

# TTL やフラグを含む詳しい表示
nslookup -debug -type=A example.com 8.8.8.8

同じ確認を kdig で行う書き方

nslookup でよく行う確認は、kdig では次のように書けます。問い合わせ先は @ で指定し、種別は名前の後ろに書きます。

# nslookup -type=NS example.com 8.8.8.8 に相当
kdig @8.8.8.8 example.com NS

# 値だけを表示する
kdig @8.8.8.8 example.com A +short

# 権威サーバーに直接、再帰要求なしで問い合わせる(設定上の TTL を見る)
kdig @ns1.example.net example.com A +norec

# DNSSEC の署名も取得し、ad フラグを確認する
kdig @1.1.1.1 example.com A +dnssec

# DNS over TLS で問い合わせる(証明書の名前も確認する)
kdig @1.1.1.1 +tls-ca +tls-hostname=cloudflare-dns.com example.com A

kdig の出力では、ヘッダーの flags 行に qr rd ra のようなフラグが並び、aa があれば権威サーバーの答え、ad があればキャッシュサーバーで DNSSEC の検証に成功した答えです。各レコードの2列目が TTL で、キャッシュサーバーの答えでは残り時間、権威サーバーの答えでは設定値です。出力の最後には、問い合わせ先と使った通信方式(UDP・TCP・TLS など)、応答時間が表示されるため、暗号化DNSで問い合わせられたかもここで確かめられます。

+tls だけを指定すると、証明書の検証をしないまま暗号化して問い合わせる動きになります。通信経路の確認では +tls-ca(OS の証明書ストアで検証)と +tls-hostname を組み合わせると、接続先が本物かどうかまで確かめられます。DoH の +https や DoQ の +quic は比較的新しい版で加わった指定なので、手元の kdig で使えるかは kdig -h やマニュアルで確かめてください。

切り替えの目安

次のような場面では nslookup で足ります。

  • 社員の PC やサーバーから、ある名前が引けるかどうかをすぐに確かめたい。
  • 端末に設定された DNS サーバーが応答しているかを見たい。
  • 社内向けの名前と外向けの名前で答えが違うかを、端末の設定のまま確かめたい。

一方、次のような論点が出てきたら kdig に切り替えます。

  • ネームサーバーの変更やレコードの修正後、どのくらい待てば反映されるかを TTL から見積もりたい。
  • 権威サーバー同士で答えが食い違っていないかを、+norec で1台ずつ確かめたい。
  • 一部の環境でだけ SERVFAIL になり、DNSSEC の署名が関わっていそうだ。
  • DoT や DoH の問い合わせ先が正しく動いているかを確かめたい。
  • 定期的な確認をスクリプトにしたい。出力を +short などで絞れるため、結果の比較や記録がしやすくなります。

Windows が中心の環境では、最初の切り分けを nslookup と Resolve-DnsName で行い、詳しい調査は Linux サーバーや WSL 上の kdig で行う、と役割を分けておくと、手元の環境の都合に振り回されずに済みます。

使うときの注意

  • どちらのツールも、問い合わせ先を指定しなければ端末やサーバーに設定された DNS サーバーを使います。結果を人に共有するときは、どのサーバーに問い合わせたかを添えると誤解を防げます。
  • 公開されている暗号化DNSのサービスは、提供条件や対応方式が変わることがあります。問い合わせ先の名前や方式は、各サービスの公式の案内で確かめてから使います。
  • 社内のネットワークでは、外部の DNS サーバーへの問い合わせや 853 番ポートの通信が止められていることがあります。結果が返らないときは、ツールの問題か通信の制限かを切り分けます。

まとめ

  • nslookup は Windows に標準で入っており、その端末から名前が引けるかを確かめるのに向いています。
  • kdig は TTL・フラグ・DNSSEC・暗号化DNSまで含めて、答えの中身を詳しく調べるのに向いています。
  • nslookup の「権限のない回答」はエラーではなく、hosts ファイルや OS のキャッシュは使われない点に注意します。
  • TTL の見積もり、権威サーバーの比較、署名や暗号化DNSが論点になったら kdig に切り替えます。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲