dig は、DNSサーバーが返した応答をほぼそのまま表示してくれる調査用のコマンドです。応答コード・フラグ・TTL・どのサーバーが答えたかまで一度に見えるため、「レコードが正しく設定されているか」「どこで食い違っているか」を根拠をもって調べられます。この記事では、出力の読み方を押さえたうえで、WordPressサイトの運用でよく使う調査パターンを紹介します。
dig を使えるようにする
macOS には標準で入っています。Linux ではディストリビューションによってパッケージ名が異なります。
# Debian / Ubuntu
sudo apt install dnsutils
# RHEL / AlmaLinux / Rocky Linux など
sudo dnf install bind-utilsWindows には標準では入っていません。WSL（Windows Subsystem for Linux）上の Linux に上記のパッケージを入れる方法が手軽です。WSL を使わない場合は、PowerShell の Resolve-DnsName や nslookup で代用できます。
出力の読み方
まずはオプションなしで実行してみます。
dig example.com A出力はいくつかの区画に分かれています（値は説明用の例です）。
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41352
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 3600 IN A 203.0.113.10
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)調査で特に見るのは次の部分です。
- status：応答コード。
NOERRORは正常、NXDOMAINはその名前が存在しない、SERVFAILはサーバーが答えを作れなかった、REFUSEDは問い合わせを拒否された、という意味です。名前は存在するのに ANSWER が0件なら、その種類のレコードが無い状態です - flags：
aaがあれば権威DNSサーバーからの答え、raがあれば再帰問い合わせに対応したキャッシュDNSが答えたことを表します - ANSWER SECTION：左から名前・TTL（秒）・クラス・レコード種別・値。キャッシュDNSに聞いた場合のTTLは残り時間です
- SERVER：実際に答えたDNSサーバー。思っていたサーバーに聞けているかをここで確認します
表示の細部は dig のバージョンによって多少異なります（2026年10月現在）。
出力を絞るオプション
慣れてくると、必要な部分だけを表示したほうが比較しやすくなります。
# 値だけを表示
dig +short example.com A
# 回答部分だけを、TTL付きで表示
dig example.com A +noall +answer+short はスクリプトや素早い確認に向いていますが、TTLや応答コードが見えません。「値が出ない」ときは +short を外し、status を確認してから原因を考えます。
問い合わせ先を指定する（@サーバー）
@ に続けてDNSサーバーを指定すると、そのサーバーに直接問い合わせます。比較の基本は「キャッシュDNS」と「権威DNS」です。
# 公開DNSに聞く
dig @8.8.8.8 example.com A +noall +answer
# 権威DNSを調べて、直接聞く（ns1.example.net は例）
dig +short example.com NS
dig @ns1.example.net example.com A +norecurse権威DNSへの問い合わせに +norecurse を付けるのは、再帰問い合わせを求めずに、そのサーバー自身が持っている答えだけを確認するためです。応答に aa フラグがあれば、そのゾーンを担当しているサーバーの答えと判断できます。
WordPress運用でよく使う調査パターン
サーバー移転後のIPアドレスを確認する
dig +short example.com A
dig +short example.com AAAA
dig +short www.example.comAとAAAAの両方を確認するのがポイントです。IPv6のAAAAレコードが旧サーバーのまま残っていると、IPv6で接続する環境だけ旧サイトが表示されます。www付きは CNAME になっていることが多く、+short では別名の行と最終的なIPアドレスが続けて表示されます。
メールが届かないときにMX・SPF・DMARCを見る
dig +short example.com MX
dig +short example.com TXT
dig +short _dmarc.example.com TXTMXは優先度と受信サーバー名の組で表示されます。TXTでは v=spf1 で始まる行がSPFです。SPFの行が複数あると正しく評価されないため、1つにまとまっているかも確認します。WordPress から送るメールが迷惑メール扱いになる場合も、まずこの3つを見ると原因の当たりが付きます。
複数の権威DNSで内容がそろっているか調べる
ネームサーバーが複数ある場合、それぞれが同じ内容を返しているかを SOA のシリアル番号で比べます。
for ns in $(dig +short example.com NS); do
echo "$ns: $(dig +short @"$ns" example.com SOA)"
doneSOAの3番目の値がシリアル番号です。サーバーごとに番号が違えば、ゾーン転送や同期が遅れていて、問い合わせ先によって違う答えが返る状態です。
ルートから順にたどる（+trace）
dig +trace example.com A+trace は、ルートサーバー → TLD（.com など）のサーバー → 権威DNS の順に問い合わせ、途中の応答をすべて表示します。キャッシュの影響を受けずに、上位に登録されているネームサーバーと実際の答えを確認できるため、ネームサーバー変更後に「上位の登録が切り替わったか」を調べるときに役立ちます。
逆引きを確認する
dig -x 203.0.113.10 +shortIPアドレスからホスト名を調べます。メールサーバーの送信元IPの逆引き（PTRレコード）を確認するときに使います。逆引きの設定はドメインのDNSではなく、IPアドレスを管理するサーバー会社側で行うのが一般的です。
SERVFAIL の原因が DNSSEC かを確かめる
dig example.com A +dnssec
dig example.com A +cd通常の問い合わせで SERVFAIL になり、+cd（署名の検証を行わないよう求めるフラグ）を付けると答えが返る場合、DNSSECの署名や上位に登録したDSレコードに問題がある可能性が高いと考えられます。
調査でつまずきやすい点
- ANY は当てにしない：
dig example.com ANYで全レコードを取ろうとしても、現在は多くのDNSサーバーが最小限の応答しか返しません（RFC 8482）。レコード種別ごとに問い合わせてください - 手元の結果はブラウザと一致しないことがある：dig は hosts ファイルを参照しません。ブラウザとの違いを調べる場合は、OSのキャッシュや hosts ファイルも確認します
- CDN経由のサイト：Cloudflare のプロキシを有効にしている場合、Aレコードには Cloudflare のIPアドレスが返るのが正常です
まとめ
- dig は応答コード・フラグ・TTL・応答したサーバーまで表示できる調査向けのコマンド
- まず status と flags を見て、正常か、権威DNSの答えかを判断する
@サーバーでキャッシュDNSと権威DNSを聞き比べ、+norecurseや+traceで上位からの登録状況を確かめる- 移転ではAとAAAA、メールではMX・SPF・DMARC、整合性はSOAのシリアル番号を確認する
- SERVFAIL は
+cdとの比較で DNSSEC が原因かどうかの見当を付けられる