最初に確認すること

DNS障害の調査を始める前に、対象サービスのIPアドレスが分かる場合は、 名前を使わずに通信できるかを確認します。

# 例：接続先IPアドレスへの到達性を確認
ping 192.0.2.20

# 例：HTTPSの待ち受け確認（Windows PowerShell）
Test-NetConnection 192.0.2.20 -Port 443

# 例：HTTPSの待ち受け確認（Linux）
curl -vk https://192.0.2.20/

DNS名前解決の流れ

端末が名前を解決するときは、端末のキャッシュだけで完結する場合もあれば、 再帰DNSサーバーが権威DNSサーバーへ問い合わせる場合もあります。 どの区間に障害があるかを考えるため、流れを分解しておきましょう。

症状から原因候補を整理する

同じ「名前解決できない」という申告でも、実際の症状によって確認場所は異なります。 まず影響範囲と再現条件を整理してください。

調査開始時に確認する情報

• 失敗する名前はFQDNか、短いホスト名か
• いつから発生し、変更作業や切り替えがなかったか
• 全端末か、一部端末か、特定セグメントだけか
• 社内名・外部名のどちらで失敗するか
• 毎回失敗するか、断続的か
• 利用しているDNSサーバーのIPアドレス
• 返されるエラーがNXDOMAIN、SERVFAIL、タイムアウトのどれか
• IPアドレスを直接指定した場合に通信できるか

DNS障害を切り分ける7ステップ

1. 影響範囲と対象名を確定する 全端末か一部端末か、社内名か外部名か、FQDNか短い名前かを確認します。 「つながらない」という表現だけで調査を始めず、失敗する名前と時刻を記録します。
2. IPアドレスでの到達性を確認する 接続先IPアドレスが分かる場合は、IPで通信できるか確認します。 IPでも失敗するなら、DNS以外のネットワーク・サービス障害を並行して調べます。
3. 端末が利用するDNSサーバーを確認する DHCPで想定どおりのDNSサーバーが配布されているか、手動設定やVPNによって上書きされていないかを確認します。 複数のDNSサーバーがある場合は、すべて個別に問い合わせます。
4. DNSサーバーまでの通信を確認する DNSサーバーのIP到達性、UDP/TCP 53の許可、ACL、ファイアウォール、 NAT、VRF、戻り経路を確認します。ping成功だけでDNS通信が正常とは判断しません。
5. 問い合わせ先を指定して名前解決する 既定のDNSサーバーだけでなく、サーバーを明示して問い合わせます。 サーバーAでは失敗し、サーバーBでは成功するなら、端末全体よりサーバーA側を優先できます。
6. 応答コードと回答内容を確認する タイムアウト、NXDOMAIN、SERVFAIL、REFUSED、NOERRORを区別します。 応答が返っていても、A／AAAA／CNAMEなどの内容が設計どおりか確認します。
7. DNSサーバー・ゾーン・パケットを確認する サービス状態、ログ、ゾーンロード、レコード、フォワーダー、委任、 キャッシュを確認します。必要に応じてパケットを取得し、問い合わせと応答を時系列で追います。

Windowsでの確認方法

ipconfig /all

Get-DnsClientServerAddress

nslookup app.example.local

Resolve-DnsName app.example.local

nslookup app.example.local 10.20.0.53

Resolve-DnsName app.example.local `
  -Server 10.20.0.53

ipconfig /displaydns

ipconfig /flushdns

Resolve-DnsNameの出力例

PS C:\> Resolve-DnsName app.example.local -Server 10.20.0.53

Name                     Type TTL   Section    IPAddress
----                     ---- ---   -------    ---------
app.example.local        A    300   Answer     10.20.30.20

この結果では、DNSサーバー 10.20.0.53 からAレコード 10.20.30.20 が返り、TTLは300秒です。 名前解決が成功しても、このIPアドレスが設計どおりかを確認してください。

タイムアウトの例

PS C:\> nslookup app.example.local 10.20.0.53
DNS request timed out.
    timeout was 2 seconds.
*** Request to 10.20.0.53 timed-out

タイムアウトは「レコードが存在しない」という意味ではありません。 問い合わせがDNSサーバーへ届いていない、DNSサービスが応答していない、 応答が戻れない、途中で破棄されている、といった可能性があります。

Linuxでの確認方法

resolvectl status

cat /etc/resolv.conf

dig app.example.local

dig @10.20.0.53 app.example.local A

getent hosts app.example.local

resolvectl query app.example.local

dig +trace www.example.com

dig NS example.com

digの正常応答例

$ dig @10.20.0.53 app.example.local A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24118
;; flags: qr rd ra; QUERY: 1, ANSWER: 1

;; QUESTION SECTION:
;app.example.local.          IN      A

;; ANSWER SECTION:
app.example.local.   300     IN      A       10.20.30.20

;; Query time: 3 msec
;; SERVER: 10.20.0.53#53(10.20.0.53)

確認するポイントは次のとおりです。

• status: NOERROR になっているか
• ANSWER: 1 以上か
• ANSWER SECTIONのレコード種別と値が正しいか
• 問い合わせ先が意図したDNSサーバーか
• Query timeが通常より極端に長くないか
• TTLが変更計画や切り替え設計と整合しているか

UDPとTCPを分けて確認する

# 通常の問い合わせ
dig @10.20.0.53 app.example.local A

# TCPを明示
dig +tcp @10.20.0.53 app.example.local A

通常の問い合わせはUDPで開始されることが多い一方、 大きな応答や切り詰められた応答ではTCPが必要になる場合があります。 UDPでは成功するがTCPでは失敗する、またはその逆であれば、 ファイアウォールやロードバランサーのポリシーを確認します。

ネットワーク機器での確認方法

ルーターやスイッチ自身がNTP、Syslog、AAA、ライセンスサーバーなどへ名前で接続する場合、 ネットワーク機器側のDNS設定も確認します。 次はCisco IOS系の代表例です。

show running-config | include ip name-server|ip domain
show hosts
ping app.example.local
traceroute 10.20.0.53

DNS応答コードの見方

応答が返った場合は、レコードの有無だけでなく応答コードを確認します。 応答コードによって、次に調べる場所を大きく絞り込めます。

NOERRORでも障害は残る

DNS問い合わせがNOERRORでも、古いIPアドレスや誤ったCNAMEが返れば、 利用者は正常なサービスへ接続できません。 次の3点を確認してください。

• 回答されたレコード種別は期待どおりか
• IPアドレスやCNAMEの値は設計・変更内容と一致しているか
• TTLが長すぎて旧情報が残っていないか

DNSサーバー側の確認項目

端末からの問い合わせがDNSサーバーへ届いている場合は、 サーバー内部と上流側の処理を確認します。

複数DNSサーバーを必ず個別確認する

# Windows
Resolve-DnsName app.example.local -Server 10.20.0.53
Resolve-DnsName app.example.local -Server 10.20.0.54

# Linux
dig @10.20.0.53 app.example.local A
dig @10.20.0.54 app.example.local A

端末にDNSサーバーが2台設定されていても、常に単純な順番で問い合わせるとは限りません。 OSや状態によって利用先や再試行の動作が異なるため、 「プライマリーは正常だからDNS全体も正常」と判断せず、各サーバーの回答を比較します。

パケットキャプチャーで確認する

コマンド結果だけでは、問い合わせがどこで失われているか判断できない場合があります。 そのときは端末側、DNSサーバー側、必要に応じて中継区間でパケットを取得します。

見るべきフィールド

• Transaction ID：問い合わせと応答が対応しているか
• Queries：問い合わせたFQDNとレコード種別
• Response code：NOERROR、NXDOMAIN、SERVFAILなど
• Answers：返されたA、AAAA、CNAMEなど
• Time to live：回答が何秒キャッシュされるか
• Truncated：UDP応答が切り詰められていないか
• Retransmission：同じ問い合わせを再送していないか

DNS障害切り分けでよくある失敗

自分の言葉で説明する課題

参考資料

• RFC 1034：Domain Names – Concepts and Facilities
• RFC 1035：Domain Names – Implementation and Specification
• RFC 2308：Negative Caching of DNS Queries
• RFC 7766：DNS Transport over TCP
• Microsoft Learn：Resolve-DnsName

コマンド、サービス名、ログの場所、DNSクライアントの挙動は、 OS・製品・バージョン・構成によって異なります。 本番環境では対象製品の公式ドキュメントと設計資料を確認してください。