DNSのタイムアウトの原因について

DNSのタイムアウトとは、ドメイン名の名前解決に対して、クライアントやリゾルバが定めた時間内に有効な応答を受け取れない状態を指します。

たとえば、ブラウザやアプリ、OSが example.com のIPアドレスを取得しようとしてDNS問い合わせを送っても、返答が返ってこない、途中で失われる、あるいは応答が遅すぎる場合にタイムアウトが発生します。

DNSの問題というと「DNSサーバーが落ちている」と考えられがちですが、実際には原因はもっと広く、ネットワーク経路、ファイアウォール、権威DNSの設定、DNSSEC、端末設定、アプリケーションの実装なども関係します。

DNSタイムアウトはどこで起きるのか

Webサイトへアクセスするとき、最初にDNSによる名前解決が行われます。大まかな流れは次の通りです。

1. ブラウザやアプリがドメイン名の解決を要求する
2. 端末が設定されたDNSリゾルバへ問い合わせる
3. 必要に応じて、リゾルバが権威DNSサーバーへ再帰的に問い合わせる
4. IPアドレスが返される
5. その後にHTTP/HTTPS通信が始まる

DNSタイムアウトは、この過程のどこかで必要な応答が期限内に得られないときに起こります。

ユーザー側では、次のような症状として見えることがあります。

• ページ表示が極端に遅い
• ドメイン名が解決できない
• 一部サイトだけ表示できない
• メール送信やAPI接続が失敗する
• DNS関連のエラーメッセージが表示される

ただし、表示されるエラー文言はOSやブラウザ、アプリによって異なり、必ずしも「DNSタイムアウトそのもの」を直接示しているとは限りません。

DNSタイムアウトの主な原因

DNSサーバー自体の遅延・障害

もっとも基本的な原因は、問い合わせ先のDNSサーバーが正常に応答できていないことです。

たとえば次のような状況です。

• DNSサーバーが高負荷になっている
• メモリやCPU不足で応答が遅れている
• プロセス停止や障害が発生している
• 権威DNSサーバーの一部ノードが故障している
• anycast構成の一部拠点で問題が起きている

この場合、同じDNSサーバーを利用している複数端末で同時に症状が出やすくなります。

ネットワーク遅延やパケットロス

DNSの応答自体ではなく、通信経路の品質悪化が原因でタイムアウトすることもよくあります。

DNSは伝統的にUDPを多く利用してきましたが、TCPも標準的に利用されます。

いずれにしても、ネットワーク上で遅延やパケットロスが発生すると、問い合わせや応答が正常に届かずタイムアウトの原因になります。

代表的な要因は次の通りです。

• Wi-Fiの不安定さ
• モバイル回線の品質低下
• VPN経由による遅延増大
• ISP側の経路障害
• 拠点間ネットワークの混雑
• MTU不整合や断片化の問題

DNS障害のように見えても、実際には経路上の問題であるケースは少なくありません。

DNS通信の遮断

DNSでは通常、UDP/53 と TCP/53 が利用されます。

そのため、これらの通信が遮断されると名前解決が不安定になったり失敗したりします。

よくある原因は以下です。

• ファイアウォールで53番ポートが制限されている
• セキュリティ製品がDNS通信を遮断している
• クラウドのセキュリティグループやACL設定ミス
• 社内ネットワークやVPN機器による制御
• DockerやKubernetes環境での名前解決経路の不備

なお、最近はブラウザやOS、アプリが DoH（DNS over HTTPS） や DoT（DNS over TLS） を利用することもあります。

この場合、従来の53番ポートだけでなく、HTTPSやTLS経由のDNS通信が影響している可能性もあります。

権威DNSサーバー側の設定不備

利用者側のリゾルバが正常でも、問い合わせ先のドメインを管理する権威DNS側に不備があると、最終的に名前解決は失敗または遅延します。

代表例は次の通りです。

• NSレコードの設定誤り
• レジストラに登録された委任情報と実サーバー設定の不一致
• glueレコード不備
• 権威DNSサーバーの片系障害
• 親ゾーンと子ゾーンの整合性不良
• 権威設定の不整合による委任異常

特定のドメインだけタイムアウトする場合、この領域に原因があることが多いです。

DNSSECの不整合

DNSSECを利用している場合、署名や鍵の整合性が崩れると、リゾルバが応答を信用できず、名前解決に失敗します。

たとえば次のようなケースです。

• DSレコードとDNSKEYの不一致
• 署名の期限切れ
• ゾーン更新時の鍵ロールオーバー失敗
• 一部レコードだけ署名状態が不正

この場合、ユーザーからは単なる「接続できない」「DNSが引けない」と見えることがあり、通常のDNS障害と区別しづらい場合があります。

DNS応答サイズの問題

近年のDNS応答は、DNSSEC、TXTレコード、大量の追加情報などにより大きくなることがあります。

このとき問題になりやすいのが次の点です。

• 大きなUDP応答が途中で破棄される
• EDNSの扱いに問題がある
• フラグメントされたパケットが失われる
• TCPでの再問い合わせが必要になるが通らない

小さい問い合わせは成功するのに、特定のドメインや特定レコードだけ失敗する場合には、このパターンが疑われます。

キャッシュDNSやフォワーダの不具合

企業ネットワークでは、端末が直接インターネット上の権威DNSへ問い合わせるのではなく、社内のキャッシュDNSやDNSフォワーダを経由する構成が多くあります。

この中継点に問題があると、DNSタイムアウトの原因になります。

たとえば以下です。

• フォワーダ先のDNSサーバーが不安定
• 再帰問い合わせ設定の不備
• キャッシュの破損や異常
• フォワーダのループ構成
• 負荷分散の偏り
• 上流DNSへの到達性問題

実務では、端末ではなく社内DNS基盤側がボトルネックになっていることがよくあります。

端末側のDNS設定不良

DNSタイムアウトは、クライアント側の設定不備でも発生します。

代表例は次の通りです。

• 存在しないDNSサーバーIPが設定されている
• 古いVPN設定が残っている
• resolv.conf やローカルリゾルバ設定が不正
• ローカルのDNSキャッシュサービスが異常動作している
• 優先DNSへの問い合わせ待ちで体感遅延が発生している
• hosts設定や名前解決順序が競合している

なお、複数のDNSサーバーを設定していても、どの順序で、どのタイミングで切り替えるかはOSやリゾルバ実装に依存します。

そのため、「予備DNSがあるから必ず即座に切り替わる」とは限りません。

IPv6起因の問題

最近はIPv4/IPv6のデュアルスタック環境が一般的になっているため、IPv6側だけ壊れているケースにも注意が必要です。

よくある例は次の通りです。

• DNSサーバーのIPv6アドレスには到達できない
• 権威DNSのIPv6経路だけ不安定
• AAAAレコード取得時だけ失敗する
• 端末はIPv6優先だが、実際の経路品質が悪い

この場合、あるネットワーク環境では正常でも、別の環境ではDNSが遅い、という現象が起こります。

レート制限やDDoS対策の影響

問い合わせ数が多すぎる場合、リゾルバや権威DNSが制限をかけて応答しなくなることがあります。

たとえば以下のようなケースです。

• 同一IPから短時間に大量クエリが送られている
• ボットや監視システムが過剰に問い合わせている
• DDoS対策機構がトラフィックを制限している
• 一部の拠点やノードだけレート制限がかかっている

大量アクセス時だけ不安定になる場合には、この可能性があります。

アプリケーション側の実装やタイムアウト設定

DNSサーバーが完全に停止していなくても、アプリケーション側の待ち時間設定が短すぎることで失敗することがあります。

具体例としては次のとおりです。

• APIクライアントのDNS待機時間が短い
• コンテナ環境でリトライ設定が不適切
• 言語ランタイムごとの名前解決挙動の違い
• サーバーレス環境で一時的に名前解決負荷が上がる
• アプリ側がDNSエラーと接続エラーを十分に区別していない

つまり、実際にはDNS応答が返っていても、アプリ側が先に諦めて失敗扱いにしている場合があります。

症状の出方ごとの見分け方

ブラウザだけ遅い場合

• ブラウザ独自のDNSキャッシュ
• DoH設定
• 拡張機能やセキュリティソフト
• OS全体ではなくブラウザ内部の名前解決挙動

社内ネットワークだけで発生する場合

• 社内DNSフォワーダ障害
• VPNやファイアウォールの影響
• split-horizon DNS の不整合
• 社内向け名前解決ポリシーの誤設定

一部ドメインだけ失敗する場合

• 権威DNSの設定不備
• DNSSEC不整合
• 委任情報の異常
• 応答サイズやTCP切り替えの問題

時々だけ起きる場合

• 片系障害
• ノード単位の不調
• 経路変動
• 一時的な負荷集中
• パケットロスの断続的発生

DNSタイムアウトの切り分け方法

DNSトラブルでは、どこで失敗しているかを段階的に切り分けることが重要です。

利用中のDNSサーバーを確認する

まず、端末がどのDNSサーバーを利用しているかを確認します。

• 社内DNSか
• ISP提供DNSか
• パブリックDNSか
• VPN接続時に切り替わっていないか

別のDNSサーバーで比較する

現在利用しているDNSとは別のリゾルバへ同じ問い合わせを行い、結果や応答時間を比較します。

これで差が出る場合、利用中のリゾルバ側に問題がある可能性が高くなります。

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

権威DNSサーバーに直接問い合わせることで、リゾルバの問題か、ドメイン側の問題かを切り分けやすくなります。

UDPとTCPの両方で確認する

UDPでは失敗し、TCPでは成功するなら、途中経路、ファイアウォール、応答サイズ、断片化などの問題が疑われます。

AレコードとAAAAレコードを分けて確認する

IPv4系かIPv6系かを切り分けるために、AレコードとAAAAレコードの両方を確認します。

複数ネットワークで比較する

• 社内回線では失敗
• モバイル回線では成功
• 自宅回線では成功

このような差が出る場合、利用者側ネットワークやISP、VPN経路の問題を疑いやすくなります。

代表的な確認コマンド

Windows

nslookup example.com
nslookup example.com 8.8.8.8

Linux / macOS

dig example.com
dig @8.8.8.8 example.com
dig +tcp example.com
dig AAAA example.com

権威DNSを確認する

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

補助的な疎通確認

ping 8.8.8.8
traceroute 8.8.8.8

ただし、ping や traceroute は補助的な確認手段です。

ICMPの可否だけではDNSアプリケーション層の正常性は判断できないため、主な確認には dig や nslookup を使うべきです。

実務で多い原因

実務上は、次のような原因が特に多く見られます。

1. 社内DNSフォワーダやキャッシュDNSの不調
2. ファイアウォールやVPNによるDNS通信の阻害
3. 権威DNSの片系障害
4. IPv6系だけ到達性が悪い
5. DNSSEC設定ミス
6. 応答サイズやTCP切り替えの失敗

特に企業環境では、DNSサーバーそのものより、中間のネットワーク機器や構成要因が原因になっていることが多くあります。

DNSタイムアウトを防ぐための対策

冗長化

• 権威DNSを複数台構成にする
• 異なるネットワークや事業者へ分散する
• 単一障害点をなくす

監視

• DNS応答時間の継続監視
• UDP/TCP両方の監視
• 権威DNS各ノードの個別監視
• 複数地域からの外形監視

設定の整合性確認

• NSとglueの整合性確認
• DNSSECの検証
• IPv6到達性確認
• EDNSやTCP利用を妨げないネットワーク設定

キャッシュ設計の見直し

• TTLを適切に設計する
• 不要に短すぎるTTLを避ける
• フォワーダや再帰DNSの負荷分散を最適化する

ネットワークの安定化

• VPN経路の見直し
• MTU調整
• パケットロス監視
• セキュリティ製品のDNS介入有無を確認する

まとめ

DNSタイムアウトの原因は、大きく分けると次の5系統に整理できます。

• DNSサーバー自体の障害や高負荷
• ネットワーク遅延やパケットロス
• ファイアウォールやVPNなどによる通信遮断
• 権威DNSの設定不備やDNSSEC不整合
• 端末やアプリケーション側の設定・実装の問題

DNSトラブルは「DNSサーバーの問題」とは限りません。

実際には、ネットワーク、セキュリティ機器、権威DNS、端末設定、アプリケーション挙動まで含めて確認する必要があります。

そのため、切り分けでは次の順で見ると効率的です。

1. どのDNSサーバーを使っているか
2. そのDNSサーバーで正常に解決できるか
3. 別のDNSサーバーではどうか
4. 特定ドメインだけか、全体で発生しているか
5. 権威DNSへ直接問い合わせた結果はどうか
6. UDP/TCP、IPv4/IPv6で差があるか

以上、DNSのタイムアウトの原因についてでした。

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