なぜDNSが高い稼働率の静かなキラーなのか
DNSの障害は内部の監視システムからは見えないことがよくあります。再帰的な解決チェーンとTLDの遅延が、インフラを静かにダウンさせる仕組みを学びます。
DNS障害が引き起こす目に見えないダウンタイム
オンコールを長く経験している人なら、その感覚がわかるでしょう。PagerDutyのアラートが点灯し、ダッシュボードが赤くなり、カスタマサポートに連絡が殺到します。データベースは正常です。アプリケーションサーバーも稼働しています。ロードバランサーは切断がゼロだと報告しています。
では、いったい何がダウンしているのでしょうか？
多くの場合、それはあなたのインフラそのものではありません。トラフィックを玄関口まで届ける結合組織、つまりDNSです。 トラフィックが消えるまで、すべてが正常に見える。DNS障害が明らかになることは稀です。ユーザーとエッジの間のレイヤーに存在するからです。なぜこれが発生するのか、そしてスタックを外部から内部へどう検証するかを解き明かしましょう。
ローカル稼働率のイリュージョン
ほとんどの監視設定は「インサイドアウトの盲目」に陥っています。内部サービスは、プライベートIPまたはVPCローカルの解決を使用して互いに通信します。彼らは100%の稼働率を報告します。クラウドプロバイダーの壁に囲まれた庭の中では完璧に通信できるからです。
しかし、ユーザーから見れば、サイトへの移動はパブリックインターネットの電話帳を通る複数ステップの旅です。この解決に失敗すると、内部メトリックダッシュボードは幸せそうに緑色のままで、収益はゼロになります。
技術的ディープダイブ：再帰的なDNS解決チェーン
DNSが失敗する理由を理解するには、それがどう解決されるかを理解する必要があります。ユーザーがURLを入力したとき、デバイスがサーバーのIPを「ただ知っている」わけではありません。地球を巡る再帰的な旅が始まります：
1. スタブリゾルバー
クライアントのOSが、設定されたDNS（通常はISPまたは1.1.1.1）に問い合わせます。これがDNSの「ファーストマイル」です。
2. 再帰的リゾルバー
ISPのリゾルバーがキャッシュを確認します。空の場合、ルートネームサーバー にTLDの場所を問い合わせます。
3. TLDネームサーバー
ルートは、リゾルバーを.comまたは.ioのネームサーバーに向けます。これらはレジストリレベルで管理されます。
4. 権威ネームサーバー
最後に、リクエストがDNSプロバイダー（Route53、Cloudflareなど）に到達します。このとき初めて、最終的なIPレコードがユーザーに返されます。
これらジャンプのすべてが潜在的な障害ポイントです。権威サーバーがパケットをドロップしていると、再帰的リゾルバーがタイムアウトし、SERVFAIL を返す可能性があります。さらに悪いことに、TLDサーバーに古いデータがあると、トラフィックが宙に浮きます。
本番環境での一般的なDNS障害モード
ダウンタイムは単一の障害によって引き起こされることは稀です。DNSでは、連鎖的なイベントのシーケンスであることがよくあります：
| 障害モード | 症状 | 検出方法 |
|---|---|---|
| TTLの麻痺 | 修正の反映に24時間以上かかる | シリアルナンバー監視 |
| レコードのドリフト | 一部地域で誤ったIPが返される | グローバルな権威チェック |
| TLD障害 | グローバルな全面SERVFAIL | 合成再帰的検証 |
2016年 Dyn DDoSインシデント
2016年、Dyn DNS（権威プロバイダー）に対する大規模なDDoS攻撃がTwitter、Netflix、GitHubをダウンさせました。この攻撃は企業を標的にしたのではなく、DNSプロバイダーのネームサーバーを標的にしました。結果？ 世界中の再帰的リゾルバーが権威ソースを見つけられず、大規模なSERVFAILの連鎖を引き起こしました。
DNS解決問題のデバッグ方法
DNSの問題が疑われる場合は、ブラウザーの使用を中止してください。権威ソースに直接話しかける必要があります。標準的な診断パスは次のとおりです：
権威応答の確認
直接問い合わせるために dig を使用します。これにより、ISPのキャッシュが回避されます：
dig @ns1.your-dns-provider.com yourdomain.com A
トレースでボトルネックを特定する
解決が遅い、または失敗している場合は dig +trace を使用して、解決チェーンのどこで切断されているかを正確に確認します：
dig yourdomain.com +trace
DNS解決の遅延とエラーの監視
成熟したSREプラクティスには、特定のDNSシグナルの監視が必要です。複数のグローバルな視点から p99の遅延 と エラー率 を検証します：
- 解決遅延（P99）： 特定の地域での遅延の増加は、ルーティング問題または容量オーバーのネームサーバーを示します。
- SERVFAIL率： 突然のスパイクは、上位プロバイダーに対するDDoSをシグナルすることがよくあります。
DNSインフラの保護
- プライマリデータベースと同じ厳格さでDNSインフラを扱います。
結論
DNSは退屈ですが、会社を破壊するまでは。Heimdall Observerのようなツールは、これらのモードをエンドユーザーに影響を与える前に検知するために存在します。
DNS、ネットワーク、そしてアプリケーションが到達可能かどうかを決定する見えない層に焦点を当てたインフラストラクチャエンジニア。
"本記事のような事象を監視するために Heimdall Observer を構築しました。"