「DNSがおかしいみたいです」
障害の報告は、たいていこの一言から始まります。でも「DNSがおかしい」の中身は、端末のキャッシュかもしれないし、社内のキャッシュDNSかもしれないし、権威DNSの設定ミスかもしれません。どこから調べるかを決めずに手当たり次第に試すと、時間ばかりかかります。
第10回までで、DNSの仕組み・運用・調べ方・守り方・クラウドでの使い方をひととおり見てきました。第11回では、その知識を使ってDNSの障害を切り分ける手順をまとめ、よくある障害のパターンと確認コマンドを整理します。最後に、連載全体の早見表と持ち帰りも載せます。
切り分けの手順
DNSの切り分けは、クライアント → キャッシュDNS → 権威DNS → 委任の順に、聞く相手を1段ずつ変えて確かめるのが基本です。
| 段階 | 確認すること | コマンドの例 | 分かること |
|---|---|---|---|
| 0 症状を固める | 誰が・どこから・どの名前・いつから・エラーの文言 | — | 全員か一部か、名前解決の問題か |
| 1 クライアント | 参照先のDNS、hosts、search、端末のキャッシュ、VPN・DoH | resolvectl status、ipconfig /all、getent ahosts 名前 | 端末だけの問題か |
| 2 キャッシュDNS | 同じ名前を直接聞く。応答コード・EDE・TTLの残り | dig @キャッシュDNS 名前、Resolve-DnsName 名前 -Server キャッシュDNS | キャッシュの中身、SERVFAILの理由 |
| 3 権威DNS | すべてのNSに再帰なしで聞き比べる。SOAのシリアル | dig @NS 名前 +norec、Resolve-DnsName 名前 -NoRecursion -Server NS | 設定そのものの正否、NS間の差 |
| 4 委任 | 親から順にNSとDSをたどる | dig +trace 名前（PowerShellは親のNSから -NoRecursion で順に） | 委任の切れ目、レイムデリゲーション |
ポイントは、答えが正しい段と、誤る段の境目に原因があるということです。上流ほど影響範囲が広く、端末の問題ならその端末だけ、権威DNSの問題ならその名前を引く全員に影響します。
最初の「症状を固める」も大切です。「全員が引けない」のか「一部の人だけ」なのかで、疑う場所がまったく変わります。
なお、digはhostsやnsswitchを通らず、指定したDNSに直接聞きます（第8回）。「digでは引けるのにアプリは失敗する」ときは、Linuxならgetent ahosts、WindowsならResolve-DnsNameで、OSと同じ経路を試しましょう。
よくある障害① 変更が反映されない
いちばん多い相談です。原因は主に4つあります。
1. TTLが残っている
キャッシュDNSはTTLが切れるまで古い答えを返します。キャッシュDNSに直接聞くと、TTLの残り秒数から、いつ切れるかが分かります。
$ dig @192.0.2.53 www.example.jp A +noall +answer
www.example.jp. 2873 IN A 198.51.100.10
PS> Resolve-DnsName www.example.jp -Server 192.0.2.53 -DnsOnly # TTL 列に 2873この例なら、あと2873秒（約48分）で新しい答えに変わります。
2. ネガティブキャッシュ
レコードを作る前に誰かが引くと、NXDOMAINがSOAのTTLとMINIMUMの小さい方の時間だけ保存されます（RFC 2308、第3回）。「作ったのに引けない」の典型です。
3. シリアルの上げ忘れ
ゾーンファイルを編集する製品では、SOAのシリアルを上げないとセカンダリへ転送されません（第7回）。NSごとにSOAを比べます。
4. 編集した場所が違う
レジストラーのNSが別のDNSサービスを指していれば、編集したゾーンは使われていません。dig +traceで本当の委任先を確かめます。意外と多いのがこれです。
急ぐときは、自社のキャッシュDNSで該当する名前だけを消します。
- BIND：
rndc flushname 名前 - Unbound：
unbound-control flush 名前 - Windows：
Clear-DnsServerCache（キャッシュ全体）
端末（ipconfig /flushdns、resolvectl flush-caches）やアプリ（Javaなど）のキャッシュも残る点に注意しましょう。
よくある障害② 一部の利用者・一部の場所だけ引けない
まず「どのキャッシュDNSを使っている人が困っているか」で分けます。社内のDNS、拠点のDNS、VPN、自宅やスマホの回線では、キャッシュの状態も経路も違います。
1. NS間の不一致
セカンダリが同期していない、1台だけ古い設定が残っている、といった状態です。どのNSに当たったかで答えが変わります。
$ dig +nssearch example.jp
SOA ns1.example.jp. hostmaster.example.jp. 2026092502 3600 900 1209600 3600 from server 192.0.2.53 in 3 ms.
SOA ns1.example.jp. hostmaster.example.jp. 2026092401 3600 900 1209600 3600 from server 198.51.100.53 in 12 ms.この例では、198.51.100.53のサーバーだけシリアルが古いことが一目で分かります。PowerShellなら、第8回で紹介した「全NSのSOAのシリアルを並べる」スクリプトを使います。
2. レイムデリゲーション
親に登録されたNSの一部が、そのゾーンを持っていない状態です（+norecで聞くとREFUSEDやaaなしの応答）。DNSサービスの移行後に旧NSが残るのが典型で、当たったNSによって失敗や遅延が起きます。
3. キャッシュの差
古いNSや古い答えをキャッシュしているキャッシュDNSだけが失敗します。TTLが切れた場所から順に直るのが特徴です。
4. 経路の差
大きな応答（DNSSECの署名、長いTXT）が、特定の経路のファイアウォールやVPNでフラグメントごと落ちています。dig +bufsize=1232、dig +tcp（PowerShellは-TcpOnly）で比べます（第4回）。
よくある障害③ SERVFAIL
SERVFAILは「キャッシュDNSが答えを得られなかった」という意味で、理由は応答コードだけでは分かりません。手がかりをEDE → +cd → +traceの順に集めます。
| EDE | 名前 | よくある原因 |
|---|---|---|
| 6 | DNSSEC Bogus | 署名の検証に失敗した |
| 7 | Signature Expired | 署名の期限切れ（再署名の停止） |
| 9 | DNSKEY Missing | 親の DS に合う鍵がない（鍵の更新や DNS サービス移行の失敗） |
| 15／18 | Blocked／Prohibited | ポリシーで遮断、またはアクセス制御で拒否 |
| 22 | No Reachable Authority | 権威DNS のどれにも届かない |
| 23 | Network Error | 権威DNS との通信でエラー |
$ dig @1.1.1.1 dnssec-failed.org A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2359
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)（検証失敗を試すための、公開のテスト用ドメインの例です）
- EDEが付いている → 番号で原因の系統へ（6〜12はDNSSEC、15〜18はポリシー、22・23は権威DNSに届かない）
+cd（検証なし）を付けてNOERRORになる → DNSSECの問題。delvで確認（第8回）- それでも分からない →
dig +traceで止まる所を探す。権威DNSの無応答やレイムデリゲーション
PowerShellではEDEが見えないため、Resolve-DnsName -DnssecCdで答えが返るかを確かめます。
よくある障害④ 逆引き・社内だけ引けない
| 症状 | 主な原因 | 確認 | 対処 |
|---|---|---|---|
| SSH のログインが数秒〜数十秒遅い | サーバーが接続元を逆引きし、タイムアウトを待つ（UseDNS yes など） | dig -x 接続元IP、Resolve-DnsName 接続元IP | PTRを登録する。UseDNSはOpenSSH 6.8以降の既定では no |
| ログや許可設定に名前が出ない・一致しない | PTRがない、正引きと逆引きが一致しない | dig -x（Resolve-DnsName IP）、その結果を正引き | 正引き・逆引きをそろえて登録 |
| VPN 接続中だけ社内の名前が引けない | VPNのDNS設定、スプリットDNSの設定漏れ | resolvectl status、Get-DnsClientNrptPolicy | VPNの配布設定で社内ドメインとDNSを指定 |
| 社内の特定のドメインだけ引けない | 条件付きフォワーダーの設定漏れ、転送先の停止 | dig @転送先 名前、Resolve-DnsName 名前 -Server 転送先 | 転送先を2台以上にし、監視する |
| 外からは引けるのに社内から引けない | スプリットホライズンで、社内ゾーンにレコードを追加し忘れ | 社内と社外のDNSで同じ名前を比べる | 追加の手順に両方のゾーンを入れる（第7回） |
| ブラウザーだけ社内の名前が引けない | ブラウザーのDoHが社内のDNSを迂回 | ブラウザーの設定、digとの比較 | 企業ポリシーでDoHを制御（第9回） |
遅さは逆引きの待ち時間、VPNの不具合は問い合わせの振り分け先で決まる、と覚えておくと切り分けが速くなります。
補足として、社内のIPアドレス（10.0.0.0/8など）の逆引きゾーンを社内のDNSに作っておかないと、問い合わせがインターネットへ漏れ、応答を待つ分だけ遅くなります（逆引きゾーンの書き方は第6回）。
原因と確認コマンドの対応表
ここまでの内容を、1枚の表にまとめます。障害対応のときに手元に置いておくと便利です。
| 原因 | 見える症状 | 確認コマンド | 詳しくは |
|---|---|---|---|
| TTLが残っている | 変更前の答えが返る | dig @キャッシュDNS 名前（TTLの残り）、Resolve-DnsName -Server | 第3回 |
| ネガティブキャッシュ | 作成したのにNXDOMAIN | digのAUTHORITYにあるSOAとTTL（PowerShellはSection列がAuthorityのSOA） | 第3回 |
| セカンダリの未同期 | NSによって答えが違う | dig +nssearch ゾーン、Resolve-DnsName ゾーン -Type SOA -Server 各NS | 第7回 |
| レイムデリゲーション | ときどき遅い・失敗する | dig +trace、dig @NS 名前 +norec（aaの有無）、-NoRecursion | 第2回 |
| DNSSECの検証失敗 | SERVFAIL、+cdなら成功 | dig +cd、delv、EDE、Resolve-DnsName -DnssecCd | 第9回 |
| 大きな応答が落ちる | TXTやDNSKEYだけ失敗する | dig +bufsize=1232、dig +tcp、Resolve-DnsName -TcpOnly | 第4回 |
| 逆引きがない | SSHが遅い、ログにIPしか出ない | dig -x IPアドレス、Resolve-DnsName IPアドレス | 第6回 |
| 転送・VPNの設定漏れ | 社内の名前だけ引けない | resolvectl status、Get-DnsClientNrptPolicy、dig @転送先 | 第3回・第10回 |
連載のまとめ：回ごとの要点の早見表
ここで、連載全体を振り返っておきます。困ったときは、この表から該当する回に戻ってください。
| 回 | テーマ | 押さえること | 使う場面 |
|---|---|---|---|
| 第1〜2回 | 全体像、階層と委任 | 3つの登場人物、ゾーンと委任、内部名は所有ドメインのサブドメイン | 設計の最初（第12回 問1） |
| 第3〜4回 | 名前解決の流れ、メッセージ | TTLとネガティブキャッシュ、フォワーディング、TCPは必須、EDNSは1232 | 変更作業（第12回 問2） |
| 第5〜6回 | リソースレコード | CNAMEの制約、MXとSPF・DKIM・DMARC、CAA、HTTPS | ゾーンの見直し（第12回 問5） |
| 第7回 | 権威DNSの運用 | シリアルとゾーン転送、TTLの変更手順、スプリットホライズン | 移設、DNSサービスの移行 |
| 第8回 | コマンドで調べる | dig・Resolve-DnsNameの読み方、@・+norec・+trace、応答の型 | すべての調査 |
| 第9回 | セキュリティ | DNSSECとSERVFAIL、テイクオーバー、暗号化DNS | 監査（第12回 問5） |
| 第10回 | クラウド・社内 | VPC Resolverとエンドポイント、ADのSRV、ndots | ハイブリッド（第12回 問3） |
| 第11回 | トラブルシュート | クライアント → キャッシュDNS → 権威DNSの順、EDE | 障害対応（第12回 問4） |
どの回も、「いま、どのDNSに、何を聞いているか」を意識すると理解しやすくなります。
持ち帰ってほしい3つのこと
1. いま聞いている相手を意識する
スタブリゾルバー・キャッシュDNS・権威DNSを分け、dig @サーバー（WindowsはResolve-DnsName -Server）で段階ごとに確かめる。
2. DNSの変更は、TTLとキャッシュを前提に計画する
事前にTTLを下げ、旧環境を残し、ネガティブキャッシュとシリアルを忘れない。
3. 名前は資産として管理する
内部名は所有ドメインのサブドメインにし、ドメインの更新、使わないレコード、メールの認証、DNSSECを定期的に棚卸しする。
迷ったら「どのDNSに、何を聞いているか」に戻ってください。まずは自分の端末でdig +traceを実行し、毎日使う名前の委任をたどってみることをおすすめします。
参考資料
- RFC：1034・1035（基本）、2181（明確化）、2308（ネガティブキャッシュ）、6891（EDNS）、7766・9210（TCP）、4033〜4035（DNSSEC）、8914（EDE）、9156（QNAME最小化）、9460（SVCB/HTTPS）、9499（用語）。日本語訳はJPRSの「DNS関連技術情報」にあります
- 公式ドキュメント：BIND 9 管理者リファレンス（ISC）、Unboundのドキュメント（NLnet Labs）、Microsoft Learn（Windows ServerのDNS、AD DSの設計）、Amazon Route 53 開発者ガイド、Azure DNSのドキュメント、Kubernetesの「DNS for Services and Pods」
まとめ
- 切り分けはクライアント → キャッシュDNS → 権威DNS → 委任の順。正しい段と誤る段の境目に原因がある
- 「反映されない」はTTL・ネガティブキャッシュ・シリアル・編集場所の4つを疑う
- 「一部だけ」はどのキャッシュDNSを使う人が困っているかで分ける
- SERVFAILはEDE → +cd → +traceの順に手がかりを集める
- 遅さは逆引き、VPNの不具合は問い合わせの振り分け先
次回はいよいよ最終回。ここまでの知識を使って、5つの設計演習に取り組みます。
連載「DNS入門」全12回
- DNSとは？名前解決の全体像と3つの登場人物
- ドメイン名の階層と委任
- 名前解決の流れ
- DNSメッセージとトランスポート
- リソースレコード 前編
- リソースレコード 後編
- 権威DNSサーバーの運用
- コマンドで調べる
- DNSのセキュリティ
- クラウド・社内環境のDNS
- DNSトラブルシュート（この記事）
- DNS設計演習
コメント