kdig と dig は、どちらも DNS サーバーに問い合わせて応答をそのまま見るためのコマンドです。普段のレコード確認は使い慣れた dig で十分ですが、DNS over TLS（DoT）や DNS over HTTPS（DoH）、DNS over QUIC（DoQ）の動作確認や、JSON での出力が欲しい場面では kdig のほうが扱いやすいことがあります。この記事では、両者の出自と出力の違いを押さえたうえで、どの場面でどちらを使うかを判断できるようにします。
kdig と dig はどこから来たツールか
dig は ISC（Internet Systems Consortium）が開発する DNS サーバーソフト BIND 9 に付属するコマンドです。歴史が長く、解説記事やサポート窓口の手順書もほとんどが dig を前提に書かれています。
kdig は、チェコのドメイン登録管理団体 CZ.NIC が開発する権威 DNS サーバー Knot DNS に付属するコマンドです。dig と似た書式で使えるように作られていますが、中身は別の実装です。そのため「dig の上位互換」ではなく、「似た操作感の別ツール」と考えるのが正確です。
同じ問い合わせを両方で投げても、受け取る DNS の応答そのものは同じです。違うのは、どの通信方式で問い合わせられるか、結果をどう表示するか、どのオプションがあるか、という点です。
導入方法の違い
どちらも多くの Linux ディストリビューションでパッケージとして入れられます。パッケージ名はディストリビューションや版で変わることがあるので、見つからない場合はパッケージ検索で確認してください。
# Debian / Ubuntu
sudo apt install bind9-dnsutils # dig（古い版では dnsutils）
sudo apt install knot-dnsutils # kdig
# RHEL / AlmaLinux / Rocky Linux / Fedora
sudo dnf install bind-utils # dig
sudo dnf install knot-utils # kdig（EPEL が必要な場合あり）
# macOS（Homebrew）
brew install bind # dig（macOS には標準で dig が入っています）
brew install knot # kdigWindows では、BIND の公式 Windows 版の提供が終了しているため、どちらも WSL（Windows Subsystem for Linux）上の Linux に入れて使うのが現実的です。レンタルサーバーの SSH 環境には dig だけが入っていて kdig は無い、ということもよくあります。共有サーバーでは自分でパッケージを追加できないことが多いので、手元の PC や WSL に入れておくと困りません。
基本の書式はほぼ同じ
よく使う書式は共通です。dig の手順書を見ながら、コマンド名だけ kdig に置き換えても多くの場合そのまま動きます。
dig example.com A
kdig example.com A
# 問い合わせ先のサーバーを指定
dig @1.1.1.1 example.com MX
kdig @1.1.1.1 example.com MX
# 回答だけを短く表示
dig +short example.com A
kdig +short example.com A
# 逆引き
dig -x 192.0.2.10
kdig -x 192.0.2.10+short、+tcp、+dnssec、+norecurse、+multiline、+nsid といった主要なオプションは両方にあります。ただし細部の挙動や、指定できるオプションの全体は一致しません。手順書を移植するときは、man kdig で対象のオプションがあるかを確かめてください。
違い1：暗号化DNSへの対応
使い分けの一番の判断材料はここです。
kdig は早い時期から DoT（+tls）に対応しており、その後 DoH（+https）、比較的新しい版で DoQ（+quic）にも対応しました。証明書の検証方法を細かく指定するオプション（+tls-ca、+tls-hostname など）もそろっています。
# DoT（853番ポート）で問い合わせ、システムのCAで証明書を検証
kdig @1.1.1.1 +tls-ca +tls-hostname=cloudflare-dns.com example.com A
# DoH で問い合わせ
kdig @1.1.1.1 +https example.com A
# DoQ で問い合わせ（対応している版のみ）
kdig @dns.example.net +quic example.com Adig も BIND 9.18 以降で +tls と +https に対応しています。一方で、DoQ は筆者の把握している範囲では dig では扱えません。また、+tls を付けただけでは証明書を厳密に検証しない動作になる場合があります。検証まで確認したいときは、使っている版のマニュアルで +tls-ca などの対応状況を確かめてください。対応オプションは版によって異なります（2026年10月現在）。
自社で DoT や DoH のリゾルバーを立てた、ルーターやファイアウォールで暗号化 DNS を許可したかどうか確かめたい、といった場面では kdig を選ぶと手間が少なく済みます。
違い2：出力形式
既定の出力は似ていますが、細部が違います。dig は末尾に Query time、SERVER、WHEN、MSG SIZE rcvd を表示します。kdig は Received ... B と、どのサーバーにどのプロトコル（UDP / TCP / TLS など）で問い合わせたかを From の行にまとめて表示します。暗号化 DNS の確認では、この行で「本当に TLS で通信したか」を目で確認できるのが便利です。
機械処理向けの出力も異なります。dig は +yaml で YAML 形式を出せます。kdig は新しめの版で +json による JSON 出力に対応しています。監視スクリプトで応答を解析したい場合、jq で扱える JSON のほうが楽なことが多いでしょう。
dig +yaml example.com A
kdig +json example.com A | jq .ただし、どちらの形式もフィールド名や構造が版によって変わる可能性があります。スクリプトに組み込むなら、サーバー側のツールの版を固定するか、+short の素朴な出力を使うほうが壊れにくいです。
違い3：dig にあって kdig に無いもの
dig の +trace は、ルートサーバーから順に委任をたどって、どの段階で応答がおかしくなるかを見せてくれる機能です。ネームサーバーの変更が反映されない、委任が切れている、といった調査でよく使います。kdig には同等の機能が用意されていないため、委任をたどる調査は dig で行うのが一般的です。
また、dig はホームディレクトリの ~/.digrc に既定のオプションを書いておけますが、kdig はこのファイルを読みません。普段 ~/.digrc に +noall +answer などを入れている人は、kdig では毎回オプションを付ける必要があります。
どちらを使うかの目安
判断を短くまとめると次のとおりです。
- 普段のレコード確認、サーバー移転時の IP 確認、メール関連の TXT や MX の確認：dig で十分です。手順書やサポートとのやり取りも dig が前提のことが多いです。
- 委任のたどり直し（
+trace）：dig を使います。 - DoT / DoH / DoQ のリゾルバーが応答するか、証明書が正しいかの確認：kdig が向いています。
- 監視スクリプトで JSON として扱いたい：kdig の
+jsonが扱いやすい選択肢です。 - 両方の結果が食い違う：ツールではなく、問い合わせ先や通信経路の違いを疑います。
最後の点は意外とつまずきやすいところです。kdig と dig で結果が違うときは、問い合わせ先サーバー（@ の指定や /etc/resolv.conf の内容）が同じか、片方だけ TCP や TLS で通信していないか、キャッシュの残り時間（TTL）が違うだけではないか、を順に確認してください。ツール自体が間違った答えを出すことはまずありません。
WordPress 運用で使う場面
WordPress サイトの運用では、ほとんどの作業は dig で足ります。サーバー移転のときに新旧どちらの IP が返っているか、独自ドメインのメール設定で SPF や DMARC の TXT が正しく公開されているか、といった確認です。
kdig が役立つのは、社内ネットワークや自前の VPS で暗号化 DNS を使う構成を組んだときです。たとえば、VPS 上に DoT 対応のキャッシュサーバーを立てた場合、kdig で +tls を付けて問い合わせれば、853 番ポートが開いているか、証明書のホスト名が合っているかを一度に確かめられます。ファイアウォールの設定を変える前後で同じコマンドを実行し、結果を比べると切り分けが速くなります。
なお、どちらのツールも読み取り専用の問い合わせを行うだけなので、実行してもサーバーの設定は変わりません。ただし、他者が管理する DNS サーバーに大量の問い合わせを短時間で繰り返すのは避けてください。
まとめ
- dig は BIND 付属、kdig は Knot DNS 付属の別実装で、基本の書式はほぼ共通です。
- 暗号化 DNS（DoT / DoH / DoQ）の確認や証明書検証の指定は kdig が扱いやすく、DoQ は kdig の対応している版で確認します。
+traceによる委任の追跡や~/.digrcは dig 側の機能です。- 機械処理には dig の
+yaml、kdig の+jsonが使えますが、版による違いに注意します。 - 結果が食い違うときは、ツールではなく問い合わせ先・通信方式・TTL の違いを確認します。