dig は、DNSサーバーに直接問い合わせて「どのサーバーが、どんな答えを、どの状態で返したか」を確認するコマンドです。この記事では、インストールから基本の問い合わせ、出力の読み方、問い合わせ先の切り替え、+trace による経路の追跡までを順に説明します。読み終えるころには、サーバー移転やメール設定の前後に、DNSが意図どおりになっているかを自分で確かめられるようになります。
dig を使う前に知っておきたいこと
ブラウザで表示を確かめるだけでは、どのDNSサーバーの答えを見ているのか分かりません。PCやルーター、プロバイダのキャッシュが古い値を返していることも多く、「設定したのに変わらない」の原因の大半はここにあります。dig は問い合わせ先を明示できるため、権威DNSサーバー（ドメインの正しい答えを持つサーバー）と、キャッシュを持つリゾルバ（8.8.8.8 などの公開DNS）を分けて調べられます。この区別が、dig を使う一番の理由です。
インストール
macOS には標準で入っています。Linux ではパッケージ名がディストリビューションごとに異なります。
# Debian / Ubuntu（新しい版では bind9-dnsutils が実体で、dnsutils はその移行用パッケージ）
sudo apt install dnsutils
# RHEL / AlmaLinux / Rocky Linux
sudo dnf install bind-utils
# 確認
dig -vWindows 向けの公式バイナリは配布が終了しているため（2026年10月現在）、WSL 上の Linux で使うのが手軽です。Windows 標準の nslookup でも簡単な確認はできますが、出力の情報量は dig のほうが多くなります。
手順1：まず基本の問い合わせをする
最初は、ドメイン名とレコードタイプだけを指定します。タイプを省略すると A レコードを問い合わせます。
dig example.com A出力は長く見えますが、見る場所は決まっています。
->>HEADER<<-の行のstatus:…NOERRORなら応答は正常です。NXDOMAINはその名前が存在しない、SERVFAILは問い合わせ先のサーバーが答えを出せなかった（DNSSECの検証失敗や権威サーバーの不調が多い）、REFUSEDは問い合わせ自体を断られたことを示します。flags:…qr（応答である）、rd（再帰を要求した）、ra（再帰に対応している）、aa（権威サーバー自身の答え）、ad（DNSSECで検証済み）などが並びます。aaがあれば、キャッシュではなく権威サーバーの答えです。ANSWER SECTION… 実際の答えです。左から名前、TTL（残りのキャッシュ秒数）、クラス、タイプ、値の順に並びます。AUTHORITY SECTION… 答えがない場合などに、どのネームサーバーが担当かが出ます。- 末尾の
SERVER:… 実際に問い合わせたサーバーです。意図した相手に聞けているかをここで確かめます。
status: NOERROR なのに ANSWER SECTION が空、という結果もあります。これは「名前は存在するが、そのタイプのレコードがない」状態です。たとえば www に CNAME しかない場合に MX を聞くと、こうなります。
手順2：必要な部分だけを表示する
日常の確認では、出力を絞ったほうが見間違いが減ります。
# 値だけ
dig +short example.com A
# 答えのセクションだけ（TTLも見たいとき）
dig +noall +answer example.com A
# よく使うタイプ
dig +short example.com MX
dig +short example.com TXT
dig +short example.com NS
dig +short www.example.com CNAME
dig +short example.com CAA+short は手軽ですが、TTLや status が見えません。「何も出ない」ときに、NXDOMAIN なのか、レコードがないだけなのかを区別できないので、迷ったら +noall +answer か通常の出力に戻ります。
WordPress の運用では、TXT（SPF・DKIM・DMARC、各種サービスの所有権確認）と CAA（証明書を発行できる認証局の指定）の確認が特に役立ちます。お問い合わせフォームのメールが届かない、Let's Encrypt の発行が失敗する、といった場面で、まず実際に公開されている値を確かめます。
手順3：問い合わせ先を切り替えて比べる
@ に続けてサーバーを指定すると、そのサーバーに直接問い合わせます。ここが dig の中心的な使い方です。
# 担当のネームサーバーを調べる
dig +short example.com NS
# 権威サーバーに直接聞く（キャッシュの影響を受けない）
dig @ns1.example-dns.com example.com A +norecurse
# 公開リゾルバに聞く（利用者側から見える値に近い）
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A権威サーバーが新しい値を返しているのに、公開リゾルバが古い値を返している場合は、設定は正しく、キャッシュが切れるのを待っている段階です。リゾルバ側の ANSWER SECTION に出る TTL は、残りのキャッシュ時間なので、おおよその待ち時間の目安になります。
反対に、権威サーバーが古い値を返しているなら、DNS管理画面の変更が保存されていないか、別のDNSサービスを編集している可能性があります。レジストラでネームサーバーを切り替えたのに、旧DNSサービス側のレコードを編集していた、というのはよくある取り違えです。
手順4：+trace でルートから順にたどる
+trace を付けると、dig がルートサーバーから TLD（.com や .jp）のサーバー、権威サーバーへと順に問い合わせ、委任の流れを表示します。
dig +trace example.com Aネームサーバーを変更した直後に確認すると、TLD のサーバーがどのネームサーバーに委任しているか（レジストラでの設定が登録済みか）が分かります。途中で止まる、想定外のネームサーバーが出る、といった場合は、レジストラ側のネームサーバー設定を見直します。なお、ネットワークによっては外向きのDNS通信が制限されていて、+trace が途中で失敗することがあります。その場合は別の回線やサーバー上で試すと切り分けられます。
手順5：逆引きやその他の確認
# IPアドレスからホスト名を逆引き（PTR）
dig -x 203.0.113.10 +short
# DNSSEC の署名も表示
dig example.com A +dnssec
# TCP で問い合わせる（大きな応答やUDPの遮断を疑うとき）
dig example.com TXT +tcp
# IPv4 / IPv6 の経路を固定する
dig -4 example.com AAAA逆引きは、メールサーバーの信頼性確認でよく使われます。PTR はドメインのDNSではなく、IPアドレスを管理する側（VPS事業者など）で設定するのが一般的です。
つまずきやすい点
- ローカルのキャッシュと混同する：
@を付けない dig は、OSに設定されたリゾルバ（/etc/resolv.conf など）に聞きます。社内DNSやルーターが古い値を返している場合があるので、比較には@を明示します。 - 末尾のドットや CNAME の連鎖：CNAME の先がさらに CNAME になっていると、ANSWER SECTION に複数行出ます。最後の行が最終的なアドレスです。
- ワイルドカード：
*.example.comが設定されていると、存在しないサブドメインでも答えが返ります。NXDOMAIN にならないのは不具合ではありません。 - ブラウザでの確認は最後に：ブラウザやOSにもキャッシュがあります。dig で正しい値を確認してから、必要に応じてOSのDNSキャッシュを消去します。
まとめ
- dig は問い合わせ先を指定できるため、権威サーバーの正しい値とリゾルバのキャッシュを分けて調べられます。
- 出力ではまず status、flags の aa、ANSWER SECTION、SERVER の4か所を見ます。
- 日常の確認は
+shortや+noall +answerで、迷ったら通常の出力に戻ります。 - 権威サーバーとリゾルバの値を比べ、違いがTTLによる待ちなのか設定ミスなのかを判断します。
- 委任の問題は
+trace、メールや証明書の問題は TXT・CAA・PTR の確認が手がかりになります。