DNSのdigコマンドについて

dig（ディグ）は、DNS情報を調べるためのコマンドです。

正式には Domain Information Groper の略で、ドメイン名に紐づくIPアドレスやDNSレコード、ネームサーバー、メールサーバー、DNSの応答状況などを確認できます。

Webサイト運営、サーバー移転、ドメイン設定、メール認証、SEO、DNSトラブル調査などでよく使われるコマンドです。

たとえば、以下のように実行します。

dig example.com

このコマンドを実行すると、example.com に設定されているDNS情報を確認できます。

dig は、以下のような場面で役立ちます。

• ドメインがどのIPアドレスを向いているか確認したいとき
• AレコードやCNAMEレコードを確認したいとき
• MXレコードを確認してメールサーバー設定を調べたいとき
• SPF、DKIM、DMARCなどのメール認証設定を確認したいとき
• ネームサーバーの設定を確認したいとき
• DNS変更後の反映状況を確認したいとき
• DNSトラブルの原因を切り分けたいとき

特に、サーバー移転やメール配信設定を行う場面では、dig を使えると原因調査がかなりスムーズになります。

digコマンドの基本構文

dig の基本構文は以下です。

dig [ドメイン名] [レコードタイプ] [オプション]

たとえば、以下のコマンドでは example.com のAレコードを確認します。

dig example.com A

Aレコードは、ドメイン名をIPv4アドレスに変換するためのDNSレコードです。

また、レコードタイプを省略して以下のように実行することもできます。

dig example.com

この場合、多くの環境ではAレコードの問い合わせとして実行されます。

ただし、実務では確認したいレコードタイプを明示するほうが安全です。

dig example.com A
dig example.com MX
dig example.com TXT

digコマンドの基本的な使い方

Aレコードを確認する

Aレコードは、ドメイン名に対応するIPv4アドレスを示すレコードです。

dig example.com A

出力例は以下のようになります。

example.com.  3600  IN  A  93.184.216.34

それぞれの意味は以下です。

項目	意味
example.com.	対象のドメイン名
3600	TTL
IN	インターネットクラス
A	レコードタイプ
93.184.216.34	IPv4アドレス

Aレコードを確認することで、そのドメインがどのサーバーを向いているかを調べられます。

Webサイトが表示されない場合や、サーバー移転後に正しいIPへ向いているか確認したい場合によく使います。

AAAAレコードを確認する

AAAAレコードは、ドメイン名に対応するIPv6アドレスを示すレコードです。

dig example.com AAAA

出力例は以下です。

example.com.  3600  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

IPv6対応しているWebサイトでは、AAAAレコードが設定されている場合があります。

AレコードがIPv4用であるのに対し、AAAAレコードはIPv6用です。

CNAMEレコードを確認する

CNAMEレコードは、あるホスト名を別のホスト名の別名として設定するためのレコードです。

dig www.example.com CNAME

出力例は以下です。

www.example.com.  3600  IN  CNAME  example.com.

この場合、www.example.com は example.com の別名として設定されています。

CNAMEは、CDNや外部サービスを利用する場面でもよく使われます。

たとえば、WebサイトをCloudFront、Cloudflare、Shopify、HubSpot、フォーム作成ツール、MAツールなどに向ける場合に、CNAMEを設定することがあります。

ただし、CNAMEを設定した同じ名前には、原則として他の通常レコードを併存させません。

たとえば、以下のような設定は避けるべきです。

www.example.com.  IN  CNAME  example.com.
www.example.com.  IN  A      192.0.2.10

CNAMEを確認するときは、単に別名が設定されているかだけでなく、その別名の先が最終的にどこへ解決されるかも確認するとよいです。

dig www.example.com CNAME +noall +answer
dig www.example.com A +noall +answer

MXレコードを確認する

MXレコードは、対象ドメインのメールサーバーを指定するレコードです。

dig example.com MX

出力例は以下です。

example.com.  3600  IN  MX  10 mail.example.com.

10 は優先度を表します。

MXレコードでは、数字が小さいほど優先順位が高くなります。

たとえば、以下のような設定があるとします。

example.com.  3600  IN  MX  10 mx1.example.com.
example.com.  3600  IN  MX  20 mx2.example.com.

この場合、通常は mx1.example.com が優先されます。

mx1.example.com が利用できない場合などに、mx2.example.com が使われます。

Google WorkspaceやMicrosoft 365などを利用する場合、MXレコードの設定確認は非常に重要です。

TXTレコードを確認する

TXTレコードは、任意のテキスト情報をDNS上に公開するためのレコードです。

dig example.com TXT

TXTレコードは、以下のような用途でよく使われます。

• SPF設定
• DKIM設定
• DMARC設定
• Google Search Consoleの所有権確認
• Microsoft 365のドメイン認証
• 各種SaaSのドメイン認証

SPFの例は以下です。

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

TXTレコードは1つのドメインに複数設定されている場合があります。

そのため、SPFを確認したい場合は、TXTレコードの中から v=spf1 で始まるものを探します。

簡潔に確認したい場合は、以下のようにします。

dig example.com TXT +short

NSレコードを確認する

NSレコードは、そのドメインのDNS情報を管理しているネームサーバーを示すレコードです。

dig example.com NS

出力例は以下です。

example.com.  86400  IN  NS  ns1.example-dns.com.
example.com.  86400  IN  NS  ns2.example-dns.com.

NSレコードを見ることで、そのドメインがどのDNSサーバーで管理されているかを確認できます。

サーバー移転やDNS管理サービスの変更時には、NSレコードの確認が重要です。

簡潔に確認する場合は、以下のように実行します。

dig example.com NS +short

SOAレコードを確認する

SOAレコードは、DNSゾーンの基本情報を示すレコードです。

dig example.com SOA

出力例は以下です。

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. 2026051501 3600 900 1209600 300

SOAレコードには、主に以下のような情報が含まれます。

項目	意味
プライマリNS	代表となるネームサーバー
管理者メール	ゾーン管理者のメールアドレス
Serial	ゾーンのシリアル番号
Refresh	セカンダリDNSの更新確認間隔
Retry	更新失敗時の再試行間隔
Expire	ゾーン情報の有効期限
Minimum	主にネガティブキャッシュTTLに関係する値

SOAレコードは、普段のWebサイト確認ではあまり頻繁には使いません。

しかし、DNSゾーンの状態や権威DNSの設定を調べるときに役立ちます。

特に Serial は、ゾーン情報が更新されているかを確認する際に使われることがあります。

PTRレコードを確認する

PTRレコードは、IPアドレスからホスト名を調べるためのレコードです。

いわゆる逆引きDNSで使われます。

dig では、-x オプションを使って逆引きを確認できます。

dig -x 8.8.8.8

出力例は以下です。

8.8.8.8.in-addr.arpa.  86400  IN  PTR  dns.google.

簡潔に表示する場合は以下です。

dig -x 8.8.8.8 +short

逆引きDNSは、メールサーバーの信頼性確認やログ解析などで使われることがあります。

digコマンドの出力結果の読み方

dig example.com を実行すると、以下のような形式で結果が表示されます。

; <<>> DiG 9.18.1 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; 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  93.184.216.34

;; Query time: 30 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri May 15 12:00:00 JST 2026
;; MSG SIZE  rcvd: 56

最初は難しく見えるかもしれませんが、よく見るべき場所は限られています。

HEADER部分

HEADER部分には、DNS問い合わせの結果ステータスやフラグが表示されます。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345

特に重要なのは status です。

代表的なステータスは以下です。

status	意味
NOERROR	問い合わせ自体は正常に処理された
NXDOMAIN	問い合わせた名前がDNS上に存在しない
SERVFAIL	DNSサーバー側で処理に失敗した
REFUSED	DNSサーバーが問い合わせを拒否した

注意したいのは、NOERROR だからといって必ず回答があるとは限らない点です。

たとえば、ドメイン名自体は存在するものの、問い合わせたレコードタイプが存在しない場合、以下のように表示されることがあります。

status: NOERROR
ANSWER: 0

この状態は、実務上「回答なし」や「NODATA」と呼ばれることがあります。

NOANSWER と表現されることもありますが、dig の正式な status として NOANSWER が表示されるわけではありません。

QUESTION SECTION

QUESTION SECTIONには、問い合わせた内容が表示されます。

;; QUESTION SECTION:
;example.com.          IN  A

この例では、example.com のAレコードを問い合わせています。

つまり、DNSサーバーに対して、

example.com の IPv4 アドレスを教えてください

と聞いている状態です。

ANSWER SECTION

ANSWER SECTIONには、DNSサーバーから返ってきた回答が表示されます。

;; ANSWER SECTION:
example.com.     3600  IN  A  93.184.216.34

最もよく確認するのはこの部分です。

この例では、example.com のAレコードとして 93.184.216.34 が返っています。

DNS設定確認では、ANSWER SECTIONに期待した値が返っているかを確認します。

SERVER行

SERVER行には、問い合わせ先のDNSサーバーが表示されます。

;; SERVER: 192.168.1.1#53(192.168.1.1)

この例では、192.168.1.1 のDNSサーバーに問い合わせています。

これは、自分のPCやネットワークで設定されているDNSサーバーです。

多くの場合、自宅や社内のルーター、ISPのDNS、またはパブリックDNSが表示されます。

問い合わせ先を明示したい場合は、以下のように @ を使います。

dig @8.8.8.8 example.com A

この場合、Google Public DNSに問い合わせます。

Query time

Query timeは、DNS問い合わせにかかった時間です。

;; Query time: 30 msec

DNSの応答が遅い場合、名前解決に時間がかかり、Webサイトの表示にも影響することがあります。

ただし、1回の dig のQuery timeだけでDNS全体の品質を判断するのは早計です。

ネットワーク状況やキャッシュ状態によっても変わります。

TTLとは

TTLは Time To Live の略です。

DNSレコードをキャッシュしてよい時間を秒単位で示します。

たとえば、以下のように表示されていたとします。

example.com.  3600  IN  A  93.184.216.34

この 3600 がTTLです。

3600 秒なので、1時間を意味します。

TTLが長い場合、DNS変更後に古い情報がキャッシュDNSに残りやすくなります。

TTLが短い場合、変更が比較的早く反映されやすくなりますが、その分DNS問い合わせ回数は増えやすくなります。

キャッシュDNSではTTLが残り時間として表示される

TTLを見るときに注意したいのが、問い合わせ先によって表示される値が変わる場合があることです。

権威DNSサーバーに問い合わせた場合は、設定されているTTLがそのまま見えることが多いです。

一方、キャッシュDNSサーバーに問い合わせた場合は、キャッシュ上の残り時間として表示されることがあります。

たとえば、元のTTLが3600秒でも、キャッシュDNSに問い合わせると以下のように表示される場合があります。

example.com.  217  IN  A  93.184.216.34

これは、そのキャッシュDNS上で残り217秒キャッシュされる、という意味です。

DNS変更後の反映確認では、このTTLの残り時間も重要な手がかりになります。

よく使うdigコマンドのオプション

+short

+short は、結果だけを簡潔に表示するオプションです。

dig example.com A +short

出力例は以下です。

93.184.216.34

IPアドレスだけを確認したい場合に便利です。

ただし、+short は簡潔すぎるため、TTLやレコードタイプを確認したい場合には向いていません。

+noall +answer

+noall +answer は、ANSWER SECTIONだけを表示するための組み合わせです。

dig example.com A +noall +answer

出力例は以下です。

example.com.  3600  IN  A  93.184.216.34

+short よりも情報量があり、TTLやレコードタイプも確認できます。

実務では非常によく使う形式です。

@DNSサーバー指定

@ を使うと、問い合わせ先のDNSサーバーを指定できます。

dig @8.8.8.8 example.com A

これは、Google Public DNSに問い合わせる例です。

Cloudflare DNSに問い合わせる場合は以下です。

dig @1.1.1.1 example.com A

Quad9 DNSに問い合わせる場合は以下です。

dig @9.9.9.9 example.com A

DNS変更後は、問い合わせ先のDNSサーバーによって返ってくる結果が異なることがあります。

そのため、複数のDNSサーバーに問い合わせて比較すると、キャッシュ状況を確認しやすくなります。

+trace

+trace は、ルートDNSから順番に委任をたどって名前解決の経路を確認するオプションです。

dig example.com +trace

通常のDNS問い合わせでは、PCに設定されたキャッシュDNSサーバーに問い合わせます。

一方、+trace を使うと、以下のような流れでDNSの委任経路をたどります。

ルートDNS
  ↓
TLD DNS
  ↓
権威DNSサーバー
  ↓
最終的なレコード

DNSの委任設定やネームサーバー設定に問題がある場合、+trace を使うことでどこで止まっているかを確認しやすくなります。

ただし、+trace はキャッシュDNSの通常の動作をそのまま再現するものではありません。

ユーザーが実際に利用しているDNSサーバーでどのような結果になるかを確認したい場合は、@8.8.8.8 や @1.1.1.1 などで直接問い合わせる必要があります。

+dnssec

+dnssec は、DNSSEC関連のデータを要求するオプションです。

dig example.com A +dnssec

DNSSECが設定されているドメインでは、RRSIG などのDNSSEC関連レコードが返る場合があります。

ただし、+dnssec を付けたからといって、DNSSECの検証が成功していると判断できるわけではありません。

DNSSECの検証状態を確認する場合は、DNSSEC検証に対応したリゾルバへ問い合わせたうえで、ad フラグなども確認する必要があります。

+tcp

+tcp は、TCPでDNS問い合わせを行うオプションです。

dig example.com A +tcp

通常、DNS問い合わせはUDPで行われます。

ただし、応答サイズが大きい場合やDNSSEC関連の問い合わせなどでは、TCPが使われることがあります。

UDPでうまく応答が返らない場合や、DNSサーバーのTCP応答を確認したい場合に使います。

+time

+time は、タイムアウト時間を指定するオプションです。

dig example.com A +time=3

この例では、応答待ち時間を3秒に設定しています。

DNSサーバーの応答遅延やタイムアウトを調べたい場合に便利です。

+tries

+tries は、再試行回数を指定するオプションです。

dig example.com A +tries=1

障害調査で、何度もリトライせずに結果を確認したい場合に使います。

+time と組み合わせることもあります。

dig example.com A +time=3 +tries=1

+nocmd

+nocmd は、冒頭のコマンド情報を非表示にするオプションです。

dig example.com A +nocmd

出力を少し整理したい場合に使います。

+nostats

+nostats は、Query timeやMSG SIZEなどの統計情報を非表示にするオプションです。

dig example.com A +nostats

ANSWER SECTIONなど、主要な情報だけを見たい場合に使います。

+nocomments

+nocomments は、コメント行を非表示にするオプションです。

dig example.com A +nocomments

スクリプトやログで出力を整理したい場合に使いやすいオプションです。

権威DNSとキャッシュDNSの違い

dig を使ううえで重要なのが、権威DNSとキャッシュDNSの違いです。

この違いを理解していないと、DNS変更後に「設定したのに反映されない」と誤解しやすくなります。

キャッシュDNSとは

キャッシュDNSは、利用者の代わりにDNS問い合わせを行い、その結果を一定時間保存するDNSサーバーです。

一般的には、以下のようなDNSサーバーが該当します。

• 自宅や会社のルーター
• ISPのDNSサーバー
• Google Public DNS
• Cloudflare DNS
• Quad9 DNS

たとえば、以下のコマンドではGoogle Public DNSに問い合わせます。

dig @8.8.8.8 example.com A

キャッシュDNSは、一度取得したDNS情報をTTLの範囲内で保存します。

そのため、DNSレコードを変更しても、キャッシュDNSに古い情報が残っている間は、古い結果が返る場合があります。

権威DNSとは

権威DNSは、そのドメインの正式なDNS情報を持っているDNSサーバーです。

たとえば、example.com のNSレコードが以下だったとします。

example.com.  86400  IN  NS  ns1.example-dns.com.
example.com.  86400  IN  NS  ns2.example-dns.com.

この場合、ns1.example-dns.com や ns2.example-dns.com が example.com の権威DNSです。

権威DNSに直接問い合わせると、キャッシュDNSを経由せずに、現在公開されているDNS情報を確認できます。

dig @ns1.example-dns.com example.com A +noall +answer

DNS変更後は、まず権威DNSに新しい設定が反映されているかを確認すると、問題の切り分けがしやすくなります。

DNS伝播とは

DNS変更後によく使われる言葉に「DNS伝播」があります。

実務ではよく使われる表現ですが、厳密にはDNS情報が世界中へ一斉に配信されるわけではありません。

DNSの変更は、各キャッシュDNSに保存されている古い情報のTTLが切れたあと、新しい情報を取得することで順次反映されていきます。

つまり、DNS伝播とは、実務上は以下のような状態を指します。

古いDNS情報を持つキャッシュが残っている
  ↓
TTLが切れる
  ↓
キャッシュDNSが権威DNSへ新しい情報を問い合わせる
  ↓
新しいDNS情報が返るようになる

そのため、DNS変更後の確認では、以下のように複数のDNSサーバーへ問い合わせます。

dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

すべてのDNSサーバーで新しい値が返っていれば、主要なパブリックDNSでは新しい情報が取得されていると判断できます。

DNSトラブル時の確認手順

まず現在のAレコードを確認する

Webサイトが表示されない場合や、サーバー移転後の確認では、まずAレコードを確認します。

dig example.com A +noall +answer

IPアドレスだけ見たい場合は以下です。

dig example.com A +short

期待しているサーバーのIPアドレスが返っているか確認します。

wwwあり・なしを両方確認する

Webサイトでは、example.com と www.example.com が別々に設定されている場合があります。

そのため、両方確認することが重要です。

dig example.com A +noall +answer
dig www.example.com A +noall +answer
dig www.example.com CNAME +noall +answer

example.com は正しく設定されているのに、www.example.com だけ古い設定のまま、というケースもあります。

SEOやリダイレクト確認の前段階としても重要です。

NSレコードを確認する

次に、対象ドメインのネームサーバーを確認します。

dig example.com NS +short

ここで、現在どのDNSサービスが使われているかを確認できます。

DNS管理画面で設定している内容と、実際に委任されているネームサーバーが違う場合、設定変更が反映されません。

たとえば、CloudflareでDNSを設定しているつもりでも、実際のNSが別サービスを向いていれば、Cloudflare側で変更しても公開DNSには反映されません。

権威DNSに直接問い合わせる

NSレコードを確認したら、そのネームサーバーに直接問い合わせます。

dig @ns1.example-dns.com example.com A +noall +answer

権威DNSに直接問い合わせることで、キャッシュDNSを経由しない現在の公開状態を確認できます。

ここで新しいIPが返っているのに、Google Public DNSやCloudflare DNSでは古いIPが返る場合、キャッシュが残っている可能性があります。

一方、権威DNSでも古いIPが返る場合は、DNS管理画面の設定、ゾーン反映、ネームサーバーの委任などに問題がある可能性があります。

パブリックDNSごとの差を確認する

権威DNSで正しい値が返っている場合は、主要なパブリックDNSでも確認します。

dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

返ってくるIPアドレスとTTLを見ます。

古いIPが返っていてTTLが残っている場合は、そのキャッシュDNS上で古い情報がまだ残っていると考えられます。

委任経路を確認する

NSの委任やDNSの経路に問題がありそうな場合は、+trace を使います。

dig example.com +trace

これにより、ルートDNSからTLD、権威DNSまでの委任経路を確認できます。

途中で応答が止まる場合や、想定外のネームサーバーへ委任されている場合は、レジストラ側のNS設定やDNSSEC設定、Glueレコードなどに問題がある可能性があります。

メール設定の確認に使うdigコマンド

MXレコードを確認する

メール受信に関する設定を確認する場合は、MXレコードを見ます。

dig example.com MX +noall +answer

Google WorkspaceやMicrosoft 365を使っている場合、サービス側が指定するMXレコードになっているか確認します。

SPFを確認する

SPFは、送信元メールサーバーの正当性を示すための設定です。

通常、TXTレコードとして公開されます。

dig example.com TXT +short

出力されたTXTレコードの中から、v=spf1 で始まるものを探します。

例：

"v=spf1 include:_spf.google.com ~all"

SPFレコードが複数存在すると問題になる場合があるため、重複していないかも確認します。

DMARCを確認する

DMARCは、_dmarc というサブドメインのTXTレコードとして設定されます。

dig _dmarc.example.com TXT +short

出力例は以下です。

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none、p=quarantine、p=reject などのポリシーを確認します。

DKIMを確認する

DKIMは、セレクタ名を含むホスト名のTXTレコードとして設定されます。

dig selector._domainkey.example.com TXT +short

たとえば、セレクタが google の場合は以下です。

dig google._domainkey.example.com TXT +short

セレクタが default の場合は以下です。

dig default._domainkey.example.com TXT +short

DKIMのセレクタ名は、メール配信サービスやメールサーバーによって異なります。

Google Workspace、Microsoft 365、SendGrid、Mailchimp、Amazon SESなど、それぞれ指定される値を確認してから dig で調べます。

よくあるエラーと確認ポイント

NXDOMAIN

NXDOMAIN は、問い合わせた名前がDNS上に存在しないことを示します。

status: NXDOMAIN

たとえば、以下のようなコマンドを実行したとします。

dig notfound.example.com A

このとき NXDOMAIN が返った場合、notfound.example.com という名前が存在しないことを意味します。

注意したいのは、親ドメインである example.com 全体が存在しないとは限らない点です。

原因としては、以下が考えられます。

• ドメイン名やサブドメイン名の入力ミス
• サブドメインがDNSに登録されていない
• 対象のDNSゾーンが存在しない
• ネームサーバーの委任に問題がある

NOERRORだがANSWERがない

以下のように、status: NOERROR であっても回答がない場合があります。

status: NOERROR
ANSWER: 0

これは、問い合わせ自体は正常に処理されたものの、対象のレコードタイプが存在しない状態です。

たとえば、ドメイン自体は存在するがMXレコードが設定されていない場合、以下のような結果になることがあります。

dig example.com MX

この状態は、実務上「NODATA」や「回答なし」と表現されることがあります。

SERVFAIL

SERVFAIL は、DNSサーバー側で処理に失敗したことを示します。

status: SERVFAIL

原因としては、以下が考えられます。

• 権威DNSサーバーの障害
• DNSSEC設定ミス
• ゾーン設定の不整合
• ネームサーバーの応答不良
• 委任情報の問題

DNSSECを有効化した直後に SERVFAIL が出る場合、DSレコードや署名設定に問題がある可能性があります。

REFUSED

REFUSED は、DNSサーバーが問い合わせを拒否したことを示します。

status: REFUSED

原因としては、以下が考えられます。

• 問い合わせ先DNSサーバーが再帰問い合わせを許可していない
• アクセス制限が設定されている
• 対象ゾーンの権威DNSサーバーではない
• DNSサーバー側のポリシーで拒否されている

特に、権威DNSサーバーとキャッシュDNSサーバーでは役割が異なるため、問い合わせ方によっては REFUSED が返る場合があります。

digでよく見るフラグ

digの出力には、以下のようなフラグが表示されます。

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

代表的なフラグは以下です。

フラグ	意味
qr	応答であることを示す
rd	再帰問い合わせを要求したことを示す
ra	再帰問い合わせが利用可能であることを示す
aa	権威ある回答であることを示す
ad	応答した検証リゾルバがDNSSEC検証済みと判断したことを示す
cd	DNSSEC検証を無効化する指定に関係する

特に重要なのは、aa と ad です。

aaフラグ

aa は、Authoritative Answerの略です。

対象ゾーンに対する権威DNSサーバーからの正式な回答であることを示します。

権威DNSサーバーに直接問い合わせると、対象ゾーンの回答で aa が付くことがあります。

dig @ns1.example-dns.com example.com A

ただし、問い合わせ内容やゾーンの関係によっては、権威DNSへ問い合わせても必ず期待通りの aa が付くとは限りません。

adフラグ

ad は、Authenticated Dataの略です。

DNSSEC検証に対応したリゾルバが、返答データを検証済みと判断した場合に付くフラグです。

ただし、ad フラグの有無だけでDNSSECの設定全体を完全に判断できるわけではありません。

DNSSECの調査では、問い合わせ先のリゾルバがDNSSEC検証に対応しているか、+dnssec を付けたときにどのレコードが返るか、DSレコードやDNSKEY、RRSIGなどが正しくつながっているかを確認する必要があります。

Glueレコードとは

Glueレコードは、ネームサーバー名が対象ドメイン自身の配下にある場合に必要になる補助的なAレコードまたはAAAAレコードです。

たとえば、example.com のネームサーバーが以下だったとします。

ns1.example.com
ns2.example.com

この場合、example.com のDNS情報を調べるためには、まず ns1.example.com のIPアドレスが必要です。

しかし、ns1.example.com 自体も example.com の配下にあります。

そのため、上位のDNS側に、ネームサーバーのIPアドレス情報を登録しておく必要があります。

これがGlueレコードです。

ns1.example.com = 192.0.2.10
ns2.example.com = 192.0.2.11

Glueレコードに問題があると、DNSの委任が正しく機能しない場合があります。

dig example.com +trace を使うと、委任の流れを確認できるため、Glueレコード関連の問題に気づきやすくなります。

digとnslookupの違い

DNS確認では、nslookup もよく使われます。

nslookup example.com

nslookup は比較的シンプルで、基本的な名前解決の確認には十分です。

一方、dig は出力が詳しく、オプションも豊富です。

DNSの詳細調査やトラブルシューティングでは、dig のほうが使いやすい場面が多いです。

比較項目	dig	nslookup
出力の詳細さ	詳しい	比較的シンプル
DNSレコード確認	柔軟	可能
トラブル調査	向いている	簡易確認向き
スクリプト利用	しやすい	やや扱いにくい
+trace のような詳細調査	得意	不向き

初心者が簡単にIPアドレスを調べるだけなら nslookup でも問題ありません。

ただし、DNSの状態を詳しく確認したい場合は dig を使うのがおすすめです。

digとhostコマンドの違い

host コマンドもDNS確認に使えます。

host example.com

host は出力がわかりやすく、簡易的なDNS確認に向いています。

一方、dig はより詳細な情報を確認できます。

比較項目	dig	host
簡単な確認	可能	得意
詳細なDNS調査	得意	やや限定的
オプションの豊富さ	多い	少なめ
障害調査	向いている	簡易確認向き

日常的な簡易確認では host、詳細調査では dig と使い分けるとよいでしょう。

digコマンドのインストール方法

macOSの場合

macOSでは、標準で dig が使えることが多いです。

確認するには以下を実行します。

dig -v

もし利用できない場合は、HomebrewでBIND関連パッケージをインストールします。

brew install bind

Ubuntu / Debianの場合

UbuntuやDebianでは、以下のコマンドでインストールできます。

sudo apt update
sudo apt install dnsutils

インストール後、以下で確認します。

dig -v

CentOS / RHEL系の場合

CentOSやRHEL系では、bind-utils をインストールします。

sudo yum install bind-utils

または、環境によっては以下を使います。

sudo dnf install bind-utils

Windowsの場合

Windowsでは、標準環境で dig が使えない場合があります。

利用する方法としては、以下があります。

• WSLを使う
• BIND toolsをインストールする
• Chocolateyなどのパッケージ管理ツールを使う

WSLのUbuntuを使う場合は、以下でインストールできます。

sudo apt update
sudo apt install dnsutils

Windows環境でDNS確認を行うだけであれば、まずは nslookup を使い、より詳しい調査が必要になったらWSL上で dig を使う方法もあります。

実務でよく使うdigコマンド集

WebサイトのIPアドレスを確認する

dig example.com A +short

TTL込みでAレコードを確認する

dig example.com A +noall +answer

IPv6アドレスを確認する

dig example.com AAAA +short

wwwのCNAMEを確認する

dig www.example.com CNAME +noall +answer

ネームサーバーを確認する

dig example.com NS +short

メールサーバーを確認する

dig example.com MX +noall +answer

TXTレコードを確認する

dig example.com TXT +short

DMARCを確認する

dig _dmarc.example.com TXT +short

DKIMを確認する

dig selector._domainkey.example.com TXT +short

逆引きDNSを確認する

dig -x 8.8.8.8 +short

Google Public DNSで確認する

dig @8.8.8.8 example.com A +noall +answer

Cloudflare DNSで確認する

dig @1.1.1.1 example.com A +noall +answer

権威DNSに直接問い合わせる

dig @ns1.example-dns.com example.com A +noall +answer

DNSの委任経路を確認する

dig example.com +trace

DNSSEC関連データを確認する

dig example.com A +dnssec

digコマンドを使ったDNS確認の流れ

DNSトラブルが起きたときは、以下の順番で確認すると原因を切り分けやすくなります。

現在のAレコードを確認する

dig example.com A +noall +answer

まず、対象ドメインがどのIPアドレスを返しているか確認します。

wwwあり・なしを確認する

dig example.com A +noall +answer
dig www.example.com A +noall +answer
dig www.example.com CNAME +noall +answer

Webサイトでは、wwwあり と wwwなし の設定が異なる場合があるため、両方確認します。

NSレコードを確認する

dig example.com NS +short

現在どのネームサーバーに委任されているかを確認します。

権威DNSに直接問い合わせる

dig @ns1.example-dns.com example.com A +noall +answer

キャッシュDNSを経由せず、現在公開されているDNS情報を確認します。

パブリックDNSで確認する

dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

複数のキャッシュDNSで結果を比較します。

必要に応じてtraceする

dig example.com +trace

委任経路やネームサーバー設定に問題がありそうな場合に使います。

まとめ

dig は、DNS情報を確認するための強力なコマンドです。

ドメインがどのIPアドレスを向いているかだけでなく、ネームサーバー、メールサーバー、TXTレコード、DNSSEC関連情報、逆引きDNS、DNSの委任経路なども確認できます。

特に実務では、以下のコマンドを覚えておくと便利です。

dig example.com A +short

dig example.com A +noall +answer

dig example.com NS +short

dig example.com MX +noall +answer

dig example.com TXT +short

dig @8.8.8.8 example.com A +noall +answer

dig example.com +trace

DNS調査では、単に「どのIPが返っているか」だけでなく、以下の観点で確認することが大切です。

• どのDNSサーバーに問い合わせているか
• キャッシュDNSに聞いているのか、権威DNSに聞いているのか
• TTLはいくつか
• A、AAAA、CNAME、MX、TXTなど必要なレコードが存在するか
• wwwあり と wwwなし の両方が正しく設定されているか
• DNS変更が権威DNSに反映されているか
• パブリックDNSごとに返答が異なるか
• NXDOMAIN、SERVFAIL、REFUSED などのエラーが出ていないか

最初は、+short と +noall +answer だけ覚えれば十分です。

慣れてきたら、@DNSサーバー指定、+trace、-x、+dnssec なども使えるようになると、DNSトラブルの原因をより正確に切り分けられるようになります。

以上、DNSのdigコマンドについてでした。

最後までお読みいただき、ありがとうございました。