dig コマンド: Linux の DNS 照会と +short、+trace 出力の読み方
ドメインに設定された DNS レコードを、DNS サーバーの応答ヘッダーまでそのまま確認するときは dig コマンドを使います。AlmaLinux 9 と Debian 12 のサーバーで example.com のレコードを種類ごとに照会し、問い合わせる DNS サーバーを変えてみたところ、応答ヘッダーの status と flags だけで、名前が存在しない場合、DNS サーバーが答えを出せなかった場合、レコードを管理するサーバーが直接答えた場合を見分けられました。
以下の出力は AlmaLinux 9.8 サーバー (root アカウント) と Debian 12 サーバー (一般アカウント) で実行した結果です。サーバーに設定された DNS サーバーのアドレスは例示用の値 192.0.2.53 に、dig のバージョン番号も例示用の値に置き換えています。
1️⃣ dig コマンドの使い方
基本の形は [dig @サーバー 名前 種類] で、サーバーと種類は省略できます。公式マニュアルによると、サーバーを書かなければ /etc/resolv.conf に設定された DNS サーバーに問い合わせ、種類を書かなければ A レコードを照会します。
dig example.com; <<>> DiG 9.16.20-RH <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62441
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 62 IN A 104.20.23.154
example.com. 62 IN A 172.66.147.243
;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:18 UTC 2026
;; MSG SIZE rcvd: 72セミコロンで始まる行は説明の行で、セミコロンのない行が実際に受け取ったレコードです。セクションごとに確認する内容は以下のとおりです。
| 出力 | 確認できるもの |
|---|---|
| ; <<>> DiG 9.16.20-RH <<>> example.com | 実行した dig のバージョンと入力した引数 |
| ->>HEADER<<- … status: NOERROR, id: 62441 | 応答コード (status) と問い合わせ番号 (id) |
| flags: qr rd ra | 応答ヘッダーのフラグ — 応答したサーバーが再帰照会をしたか、レコードを管理するサーバーか |
| QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 | セクションごとのレコード数 |
| OPT PSEUDOSECTION · EDNS … udp: 4096 | EDNS の拡張情報と UDP で受け取れる応答サイズ (バイト) |
| QUESTION SECTION | 送った質問 — 名前、クラス (IN)、レコードの種類 |
| ANSWER SECTION | 受け取ったレコード — 名前、TTL (秒)、クラス、種類、値の順 |
| Query time: 1 msec | 応答が届くまでの時間 |
| SERVER: 192.0.2.53#53(192.0.2.53) | 応答した DNS サーバーのアドレスとポート番号 |
| WHEN · MSG SIZE rcvd: 72 | 照会した時刻と受け取った応答のサイズ (バイト) |
flags 行の qr は応答、rd は再帰照会の要求、ra は再帰照会に対応していることを意味します (RFC 1035)。aa がなく ra だけがあるので、この応答はレコードを管理するサーバーではなく、再帰照会を行う DNS サーバーが送ったものです。
ANSWER セクションの 62 は TTL で、このレコードをキャッシュに置いておける残り時間 (秒) です。直後に同じ名前を 8.8.8.8 に問い合わせると 300 と出て、DNS サーバーごとにキャッシュした時点によって数字が違いました。
同じ照会を nslookupコマンドで行うと、応答コードと TTL は既定の出力に表示されません。二つのコマンドの出力で違った点は以下のとおりです。
| 比較 | dig | nslookup |
|---|---|---|
| 応答コード | HEADER 行の status に常に表示 | エラーのときだけ server can't find の行で表示 |
| TTL | ANSWER のレコード行ごとに表示 | -debug を付けたときだけ表示 |
| 応答した DNS サーバー | 最下部の SERVER 行 | 最上部の Server · Address 行 |
| NXDOMAIN の終了コード | 0 | 1 |
インストールされている dig のバージョンは -v で確認します。AlmaLinux 9 サーバーは 9.16、Debian 12 サーバーは 9.18 でした。
dig -vDiG 9.16.20-RH2️⃣ dig でレコードを照会
名前の後ろにレコードの種類を書くと、そのレコードだけを照会します。種類ごとに入る値と、この記事で照会した結果は以下のとおりです。
| 種類 | 入る値 | 照会結果 |
|---|---|---|
| A | IPv4アドレス | example.com → 104.20.23.154 ほか 1 件 |
| AAAA | IPv6 アドレス | example.com → 2606:4700:10::6814:179a ほか 1 件 |
| MX | メールサーバーと優先度 | example.com → 0 . (メールを受け取らない) |
| NS | レコードを管理するネームサーバー | example.com → hera · elliott.ns.cloudflare.com. |
| TXT | 決まった形式のない文字の値 (SPF など) | example.com → v=spf1 -all ほか 1 件 |
| CNAME | 別の名前の別名 | www.github.com → github.com. |
| SOA | ゾーンのプライマリネームサーバーと時間の値 | example.com → elliott.ns.cloudflare.com. … |
| PTR | IP アドレスに結び付いた名前 (逆引き) | -x 8.8.8.8 → dns.google. |
メールサーバーは MX レコードで確認します。example.com の MX を照会すると、ANSWER セクションに [0 .] の 1 行が表示されました。
dig example.com MX; <<>> DiG 9.16.20-RH <<>> example.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN MX
;; ANSWER SECTION:
example.com. 300 IN MX 0 .
;; Query time: 5 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:23 UTC 2026
;; MSG SIZE rcvd: 550 は優先度で、メールサーバー名の位置にドットが一つだけある MX は、このドメインがメールを受け取らないことを示す Null MX です (RFC 7505)。種類を小文字で mx と書いても同じ結果でした。
レコードの行だけを見るときは [+noall +answer] を付けます。公式マニュアルによると、+noall は出力セクションをすべてオフにし、+answer は ANSWER セクションだけを再びオンにします。
dig example.com NS +noall +answerexample.com. 12192 IN NS hera.ns.cloudflare.com.
example.com. 12192 IN NS elliott.ns.cloudflare.com.example.com のネームサーバーは二つでした。この二つが example.com のレコードを直接管理する権威ネームサーバーです。
dig example.com TXT +noall +answerexample.com. 300 IN TXT "v=spf1 -all"
example.com. 300 IN TXT "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"TXT レコードには決まった形式なしに文字の値を入れられます。v=spf1 -all は、このドメイン名でメールを送れるサーバーがないことを示す SPF の値です。
dig www.github.com CNAME +noall +answerwww.github.com. 291 IN CNAME github.com.www.github.com は github.com の別名 (CNAME) でした。種類を書かずに同じ名前を照会すると、CNAME の行の後ろに github.com の A レコードが続けて表示されました。
SOA レコードは +multiline を付けると、数字ごとに名前と時間がコメントとして付いて読みやすくなります。
dig example.com SOA +multiline +noall +answerexample.com. 1765 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. (
2418004112 ; serial
10000 ; refresh (2 hours 46 minutes 40 seconds)
2400 ; retry (40 minutes)
604800 ; expire (1 week)
1800 ; minimum (30 minutes)
)serial はレコードを変更するたびに増える通し番号で、refresh、retry、expire はセカンダリネームサーバーがプライマリサーバーとレコードを合わせるときに使う時間の値です。minimum は、存在しない名前やレコードについての応答をキャッシュに置いておく時間です。
値だけが必要なときは +short を付けます。A レコードは IP アドレスだけ、MX は優先度とメールサーバー名だけが残りました。
dig +short example.com172.66.147.243
104.20.23.154dig google.com MX +short10 smtp.google.com.[+noall +answer] の後ろに +stats を加えると、照会時間と応答したサーバーの行も一緒に表示されます。Debian 12 サーバーの dig 9.18 では SERVER 行の末尾に問い合わせを送った方式 (UDP) が付き、AlmaLinux 9 サーバーの dig 9.16 にはこの表記がありませんでした。
dig example.com +noall +answer +statsexample.com. 235 IN A 172.66.147.243
example.com. 235 IN A 104.20.23.154
;; Query time: 0 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Thu Oct 29 00:10:26 UTC 2026
;; MSG SIZE rcvd: 723️⃣ dig での DNS サーバー指定と逆引き
名前の前に @ と DNS サーバーを書くと、サーバーに設定された DNS サーバーの代わりにそのサーバーに問い合わせます。8.8.8.8 に問い合わせると SERVER 行が 8.8.8.8 に変わり、flags に ad が加わりました。
dig @8.8.8.8 example.com; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61431
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE rcvd: 72ad は、応答したサーバーが DNSSEC の署名を検証し、応答のレコードを信頼できると判断したことを示すフラグです (RFC 4035)。サーバーに設定された DNS サーバーの応答には ad がありませんでした。
NS の照会で出たネームサーバーを @ の後ろに書くと、example.com のレコードを管理するサーバーに直接問い合わせることになります。
dig @elliott.ns.cloudflare.com example.com; <<>> DiG 9.16.20-RH <<>> @elliott.ns.cloudflare.com example.com
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61828
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154
;; Query time: 4 msec
;; SERVER: 2606:4700:58::a29f:2ce4#53(2606:4700:58::a29f:2ce4)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE rcvd: 72今回は flags に aa が出て、権威ネームサーバーが直接答えたことを確認できました。このサーバーはほかのサーバーを経由して名前を探す再帰照会に対応していないため ra が外れ、[WARNING: recursion requested but not available] の行が付きました。
(6 servers found) は、ネームサーバーの名前が IPv4 アドレス三つと IPv6 アドレス三つに解決されたという意味です。SERVER 行には、そのうち答えを送った IPv6 アドレスが表示されました。
-x の後ろに IP アドレスを書くと、PTR レコードを照会してそのアドレスに結び付いた名前を探します。
dig -x 8.8.8.8 +noall +answer8.8.8.8.in-addr.arpa. 300 IN PTR dns.google.dig は 8.8.8.8 を逆順に書いて in-addr.arpa を付けた名前を照会し、その PTR の値 dns.google. が 8.8.8.8 の名前でした。
4️⃣ dig +trace の委任経路
+trace を付けると、dig がルートネームサーバーから順に問い合わせ、名前がどのサーバーに引き渡されたかを段階ごとに出力します。公式マニュアルによると、+trace は DNSSEC の署名の行も一緒に要求するため、委任経路だけを見るよう +nodnssec も付けました。
dig +trace +nodnssec example.com; <<>> DiG 9.16.20-RH <<>> +trace +nodnssec example.com
;; global options: +cmd
. 86333 IN NS j.root-servers.net.
. 86333 IN NS g.root-servers.net.
. 86333 IN NS b.root-servers.net.
. 86333 IN NS e.root-servers.net.
. 86333 IN NS k.root-servers.net.
. 86333 IN NS f.root-servers.net.
. 86333 IN NS l.root-servers.net.
. 86333 IN NS m.root-servers.net.
. 86333 IN NS h.root-servers.net.
. 86333 IN NS c.root-servers.net.
. 86333 IN NS d.root-servers.net.
. 86333 IN NS a.root-servers.net.
. 86333 IN NS i.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 1 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 836 bytes from 2001:7fd::1#53(k.root-servers.net) in 30 ms
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.
;; Received 359 bytes from 2001:503:d414::30#53(f.gtld-servers.net) in 66 ms
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Received 72 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 3 ms段階ごとに最後の [Received … from] の行に、その応答を送ったサーバーが表示されます。四つの段階で問い合わせたサーバーと受け取ったものは以下のとおりです。
| レベル | 問い合わせたサーバー | 受け取ったもの |
|---|---|---|
| 1 | サーバーに設定された DNS サーバー (192.0.2.53) | ルート (.) ネームサーバー 13 台 |
| 2 | k.root-servers.net | .com ネームサーバー 13 台 (gtld-servers.net) |
| 3 | f.gtld-servers.net | example.com のネームサーバー 2 台 |
| 4 | elliott.ns.cloudflare.com | example.com の A レコード 2 件 |
+trace の出力は、書留郵便の追跡記録のようなものです。
最後の段階の A レコードは example.com のネームサーバーが直接送った値なので、キャッシュを経由していない現在の値です。ネームサーバーを変えた直後は、まず 3 段階目で .com のサーバーが新しいネームサーバーを返すかを確認します。
5️⃣ dig の応答エラーとオプション
🔲 応答エラー
存在しない名前を照会すると、status が NXDOMAIN と表示されます。.invalid は実際には使われないよう予約されたトップレベルドメインなので、この応答の確認に使いました。
dig example.invalid; <<>> DiG 9.16.20-RH <<>> example.invalid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23779
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.invalid. IN A
;; AUTHORITY SECTION:
invalid. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE rcvd: 96ANSWER は 0 で、AUTHORITY セクションにはそのゾーンの SOA レコードが入っていました。SOA の最後の数字 10800 は、この応答をキャッシュに置いておける時間 (秒) です。
no-such-host.example.com は NXDOMAIN ではなく、status が NOERROR、ANSWER が 0 で終わりました。エラーコードなしにレコードだけが空の応答なので、status と ANSWER の数を一緒に確認します。
dig no-such-host.example.com; <<>> DiG 9.16.20-RH <<>> no-such-host.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;no-such-host.example.com. IN A
;; AUTHORITY SECTION:
example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800
;; Query time: 7 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE rcvd: 115SERVFAIL は、DNS サーバーが答えを作れなかったことを示す応答コードです (RFC 1035)。DNSSEC 検証の失敗を試すための公開ドメイン dnssec-failed.org を 8.8.8.8 に問い合わせると、SERVFAIL と一緒に EDE の行が表示されました。
dig @8.8.8.8 dnssec-failed.org; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57521
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;dnssec-failed.org. IN A
;; Query time: 333 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:41 UTC 2026
;; MSG SIZE rcvd: 97EDE はエラーの理由を添える拡張エラーコード (RFC 8914) です。9 (DNSKEY Missing) は上位ゾーンの DS レコードと合う DNSKEY が見つからなかったという意味で、8.8.8.8 は署名を確認できない名前に対してアドレスの代わりに SERVFAIL を返しました。
DNS サーバーが応答しないと、status の行なしに [connection timed out; no servers could be reached] で終わります。文書の例示用アドレス 192.0.2.1 に [+timeout=2 +tries=1] で問い合わせると、2 秒後にこの行が表示されました。
dig @192.0.2.1 example.com +timeout=2 +tries=1; <<>> DiG 9.16.20-RH <<>> @192.0.2.1 example.com +timeout=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reachedオプションなしで同じアドレスに問い合わせると、15 秒後に同じ行が表示されました。公式マニュアルの既定値が応答一つにつき 5 秒、試行 3 回だからです。Debian 12 サーバーの dig 9.18 では [communications error to 192.0.2.1#53: timed out] の行が先に表示され、最後の行は [no servers could be reached] でした。
スクリプトで終了コードによって結果を分けるときは、NXDOMAIN でも 0 になる点に注意します。example.invalid を +short で照会したあと終了コードを出力すると、空の結果とともに 0 が表示され、応答のなかった 192.0.2.1 の照会は 9 でした。
dig +short example.invalid; echo $?0応答エラーごとに、出力で確認する行と次に確認することは以下のとおりです。
| 出力 | 意味 | 次に確認すること |
|---|---|---|
| status: NXDOMAIN | その名前が存在しない | ドメインのつづりと登録状態、+trace で委任経路 |
| status: NOERROR · ANSWER: 0 | その種類のレコードが応答にない | レコードの種類とネームサーバーのレコード設定 |
| status: SERVFAIL | DNS サーバーが答えを作れなかった | EDE の行、ほかの DNS サーバー (@8.8.8.8 · @1.1.1.1) の応答 |
| connection timed out | DNS サーバーが応答しない | DNS サーバーのアドレスと 53 番ポートをふさぐファイアウォール |
🔲 dig コマンドのオプション
📌 主なオプション: この記事で実行した結果
| オプション | 作業 | この記事で確認した結果 | |
|---|---|---|---|
| @サーバー | サーバーに設定された DNS サーバーの代わりに指定したサーバーに問い合わせる | @8.8.8.8 で SERVER 行が 8.8.8.8 に変わり flags に ad が加わる、権威ネームサーバーに問い合わせると aa | |
| 種類 | 名前の後ろに書いたレコードの種類だけを照会 | example.com MX で [0 .] の 1 行、小文字の mx でも同じ結果 | |
| -x アドレス | IP アドレスの PTR レコードを照会 | -x 8.8.8.8 で dns.google. | |
| -v | バージョンを出力 | AlmaLinux 9 サーバーは 9.16、Debian 12 サーバーは 9.18 | |
| -r | ホームフォルダーの .digrc を読まない | .digrc に +short を入れても、-r を付けるとレコードの行がそのまま表示される | |
| +short | レコードの値だけを出力 | A は IP アドレス二つ、google.com MX は 10 smtp.google.com. | |
| +noall +answer | 出力セクションをすべてオフにし、ANSWER セクションだけを再びオン | example.com NS でネームサーバーの行二つだけが残る | |
| +multiline | SOA のような長いレコードを複数行に分けてコメントを付ける | serial、refresh などの名前と時間が数字ごとにコメントとして付く | |
| +stats | 照会時間と応答したサーバーの行も一緒に出力 | Debian 12 サーバーの dig 9.18 で SERVER 行の末尾に (UDP) | |
| +trace | ルートネームサーバーから順に問い合わせて委任経路を出力 | 四つの段階ごとに、最後の [Received … from] の行に応答したサーバーが表示される | |
| +nodnssec | DNSSEC の署名レコードを要求しない | +trace と一緒に付けて委任経路だけを残す | |
| +timeout=秒 | 応答一つを待つ時間、既定 5 秒 | 192.0.2.1 に +timeout=2 +tries=1 で問い合わせると 2 秒後に [connection timed out]、オプションなしでは 15 秒 | |
| +tries=回数 | 問い合わせを送る回数、既定 3 回 | +timeout=2 と一緒に 1 にすると、一度だけ問い合わせて 2 秒後に終了 | |
| +tcp | 問い合わせを UDP の代わりに TCP で送る | Debian 12 サーバーの dig 9.18 で SERVER 行の末尾が (UDP) から (TCP) に変わり、レコードは同じ |
📎 その他のオプション: 公式マニュアルより
| オプション | 作業 | |
|---|---|---|
| -4 | IPv4 だけで問い合わせ | |
| -6 | IPv6 だけで問い合わせ | |
| -t 種類 | 照会するレコードの種類を指定 | |
| -q 名前 | 照会する名前を指定、ほかの引数と紛れないようにするとき | |
| -p ポート | 53 番の代わりに指定したポートで問い合わせ | |
| -b アドレス | 問い合わせを送る送信元 IP アドレスを指定 | |
| -f ファイル | ファイルに 1 行ずつ書いた照会を順に実行 | |
| +norecurse | 再帰照会の要求 (RD) をオフにして問い合わせ | |
| +dnssec | DNSSEC のレコードも一緒に要求 | |
| +nssearch | 権威ネームサーバーを探し、サーバーごとに持っている SOA レコードを出力 | |
| +nocmd | 先頭のバージョンとオプションの説明行を除いて出力 | |
| +nocomments | 応答ヘッダーやセクション名などの説明行を除いて出力 | |
| +ttlunits | TTL を s、m、h、d、w の単位で出力 | |
| +retry=回数 | 最初の問い合わせを除いて再送する回数、既定 2 |
🔲 dig コマンドシミュレーター
下のシミュレーターでは、レコードの種類、DNS サーバー、出力オプションを変えながら dig を直接入力できます。
🔢 FAQ & おすすめコンテンツ
ℹ️ 提携について
当サイトのコンテンツにはアフィリエイトリンクが含まれています。訪問者がこのリンクを通じて商品やサービスを購入すると、当サイトは販売元から手数料を受け取ります。この過程において、購入者が支払う金額（イベント割引適用で金額が下がります↓）は上昇しません。掲載されている価格・割引・在庫情報は作成時点のものであり、実際とは異なる場合がありますので、ご購入前に販売元にて最終確認をお願いいたします。商品の選定および評価は独自の基準に基づいて行われており、手数料の支払いの有無は紹介順や評価内容に影響を与えません。