ドットコムモニターの記事”2012 年 8 月 15 日の AT&T ドメイン ネーム サーバー (DNS) の停止に関して SpeedAwarenessMonth.com に公開されたカフェイン入りの DNS 監視と AT&T DNS 停止は、DNS 監視のキャッシュされていない方法が修復時間 (TTR) を高速にし、DNS の問題によるダウンタイムをゼロにする理由を示しています。
記事の全文は SpeedAwarenessMonth.com で入手できますが、基本は次のとおりです。
キャッシュまたはキャッシュしない-、つまり DNS 監視の質問
まず、ローカル Java ジョイントのコーヒーのような外部ベースの HTTP リクエストタイプの Web サイトのモニタリングが、キャッシュベースと非キャッシュベースの異なる「グレード」で提供されるということは、一般的にはよく知られていません。 Dotcom-Monitor は、キャッシュされていない監視を採用し、各監視インスタンスを持つ完全な DNS プロセスを通じて伝播します。 キャッシュ ベースの監視 (多くの基本的な監視サービスで使用) は、DNS プロセスを介して伝達されず、DNS の問題を見逃します。
次の DNS の停止状態を効果的に監視する方法
AT&T DNS の停止問題の場合、修復時間 (TTR) を高速化したり、ダウンタイムを回避するのに役立ついくつかの重要な要素があります。
- エラー検出方法: 非キャッシュ方式を使用する監視ソリューションを使用して、各監視インスタンスを持つルート ネーム サーバーに DNS クエリを伝達します。 キャッシュ方式サービスは DNS をキャッシュするため、セカンダリ DNS の問題をまったく検出しないか、問題を検出するのに数日または数週間かかる場合があります。
- 監視の頻度: 1 分ごと 1 時間ごと、1 時間に 1 回など、キャッシュ以外の監視の頻度を速く使用します。 非キャッシュ監視ソリューションが、障害が発生した DNS サービスを使用して影響を受ける Web サイトの管理者を高速に検出して警告する速度が高いほど、DNS フェールオーバー プロバイダに対する切り替えが迅速に行われます。
- Time-to-Live (TTL) 設定の値: プライマリ権限のあるネームサーバーからドメインの IP キャッシュを保持するために DNS 管理者が使用する TTL 設定の値が小さいほど、別の DNS プロバイダーへのフェイルオーバーが早くなります。 通常、障害復旧計画では、TTL を 300 秒に 1 回低く設定できますが、設定値が低いほど、権限のあるドメイン ネーム サーバーの負荷が高くなります。
- 検出された DNS 問題の時点での自動トレース ルートなどの診断は、監視ソリューションによって提供されます (多くの基本的な監視サービスでは診断情報が提供されないことに注意してください)。
- 修復: エラー状態の間の監視を続行して、問題をさらに特定します。 監視対象の結果を DNS プロバイダーに送信します。 必要に応じて 、www.dotcom-monitor.com/WebTools/trace.asp で手動 DNS トレース ルートを実行することもできます (トレース スタイル “DNS” を選択)。
- 防止: DNS の速度低下や断続的な DNS 停止などの”ソフト エラー” DNS の問題に注意を払い、ダウンタイムに直面しているお客様のような”ハード エラー”が発生する前に対処できます。
おかげで、私はカフェイン入りの二重深さの電荷、非キャッシュを取ります
その後、非キャッシュとその他の要因の組み合わせは、2012年8月15日のAT&T DNS停止のような問題によるダウンタイムの露出を制限することが明らかです。 さらに、DNS 監視のキャッシュされていない方法は、TTR を高速化し、ダウンタイムをゼロにするうえで重要な要素です。
最後に、TTR がダウンタイムによる損失を決定することを覚えておくことが重要です。 つまり、DNS の問題の検出、診断、修復にかかる合計時間が長いほど、DNS の問題の影響は悪化します。 逆に、監視ソリューションが速くTTRをスピードアップするほど、損失が減少するか、完全に回避されます。
カフェイン入りのコーヒーの良い強いカップと同様に、非キャッシュ方法は、ダウンタイムの日と速い生産日の違いを作ることができます。
AT&T DNS の停止の詳細については、記事 「DNS 監視の権利: AT&T DNS の停止」を参照してください。
