ローカルキャッシュへの依存をやめましょう。連鎖的なDNS障害を隔離するためにSREが使用するワークフローとコマンドを学びます。
重大なアラートが発報し、顧客からサービスアクセス不能の報告が届いたとき、反射的にポッドを再起動しがちです。しかし内部メトリクスが正常な場合、DNS問題の可能性が高いです。
優秀なSREは憶測しません。障害ドメインを隔離します。DNSのデバッグは、インフラの外へ出てユーザーから権威ネームサーバーまでのパケットの流れを再現することです。
エンジニアが犯しがちなミスは、ローカル環境の'ping'やブラウザによるテストです。OSが負の応答（NXDOMAIN）を受け取ったばかりの場合、キャッシュが切れるまでそれを返します。
非常に効果的な手法は、意図的にDNSを無視してバックエンドの健全性を証明することです。curlを使用して既知のIPへの接続を強制します：
curl -v --resolve yourdomain.com:443:192.0.2.1 https://yourdomain.com
これで成功すればサーバーやロードバランサーは健全です。名前解決のみが破損しています。
dig @1.1.1.1 yourdomain.com A
dig +trace yourdomain.com
出力を観察してください。権威サーバーまでの流れが失敗する場合、ゾーンが破損しています。
SERVFAILは解決チェーンが壊れていることを意味します。トラフィックを回復するために、DNSSEC検証失敗や不完全な委任を修正する方法を学びます。
外部の障害に対して内部のメトリクスを信頼しないでください。SREチーム向けの「外部から内部(Outside-In)」のDNS監視原則を学びます。
DNSレイテンシはアプリがリクエストを記録する前に発生します。Anycastルーティングの失敗と、エッジからの真のP99測定方法を学びます。
DNS、ネットワーク、そしてアプリケーションが到達可能かどうかを決定する見えない層に焦点を当てたインフラストラクチャエンジニア。
