エニーキャストでは、代替ルートを試すことができますか？
少しつまらないタイトルですが、より適切なタイトルを思い付くのに十分な主題がわかりません。
エニーキャストは負荷分散の優れたソリューションであり、DNS負荷分散の推奨ソリューションであることを何度も読みました。ただし、エニーキャストには負荷分散の利点があるように見え、冗長性の助けにはなりません。一方、負荷分散のないプレーンDNSソリューション（つまり、複数のAレコードのみ）は、負荷分散を提供しませんが、より優れた冗長性を提供するように見えます。
私はDNSサービスを詳しく調べていて、2016年にDynが停止したことに気づきました： https://en.wikipedia.org/wiki/2016_Dyn_cyberattack 。しかし、2つのことがあります。
1）特定のエニーキャストアナウンスの背後にあるサーバーで問題が発生した場合、他のルートが自動的に試行されますか？もしそうなら、なぜDynはそのような停止に苦しんだのですか？それともこれはUDPで実行されているDNSが原因ですか？
たとえば、青いノードに接続しようとして、ルート1-2-6をたどり、ルート6が壊れている（サーバーに接続できない、またはエラーがある）場合、ルート1-2-5または1- 3-4は自動的に試されますか？
2）この問題を軽減するためにクライアントができることはありますか？
3）エニーキャストは、他のリージョンをオンラインに保つために特定のリージョンを犠牲にする可能性が高いように思われます。これは、同じパフォーマンスを提供しないが、そのような攻撃のクッション性を高めるDNSラウンドロビンの問題とは対照的です。それで、なぜ（私の考えが正しいと仮定して）エニーキャストには大きなプッシュがあり、ユーザーに関連するサーバーの順序を返すラウンドロビンDNSサービスにはプッシュが少ないように見えるのはなぜですか？.
私はこの質問を知っています 複数のデータセンターとHTTPトラフィック：DNSラウンドロビンは即時フェイルオーバーを保証する唯一の方法ですか？ 私は興味があるのでこれを重複とは見なしませんがエニーキャストが失敗する理由。
それでは、最初に、DNSにエニーキャストを使用することによって何が暗示されるかを簡単に確認しましょう。
指定されたIPアドレスaは、より利用しやすくしたいリゾルバーです。 aホストは[〜＃〜] a [〜＃〜]/24サブネットのメンバーです。エニーキャストは特定のホストルート（つまりa/32）で実行できますが、これは一般にプライベートネットワーク内でのみ見られ、一般的なインターネットでは見られません。
[〜＃〜] a [〜＃〜]サブネットは、対応するDNSサービスが動作している場合にのみ動的にアナウンスされるようなメカニズムがあります。広告自体は、リゾルバーを実行するサイト内の単一のホストから、リゾルバーの複数のインスタンスを含む物理サイト全体（つまり、多くのホスト）から送信される可能性があることに注意してください（これは本当に重要です）リゾルバーを実行し、サイト全体が単一のルートを共有します）。
同じルート（[〜＃〜] a [〜＃〜]）は、パブリックインターネット上の複数のポイントからアドバタイズされます。これは、外部ネットワークとの相互接続の各ポイントで同じルートを提示する大規模なプロバイダー（読み取り：世界中に分散するポイント）、または複数のキャリア内でホストされるポイントからの同じルートの形をとることがあります。
したがって、任意のクライアントがエニーキャストIPに向けてパケットを送信すると、そのパケットはアドバタイズの「最も近い」ポイントに到達する傾向があります。ルーティングトポロジがどのようにレイアウトされているか、および途中でルーターにどのようなポリシーが適用されているかという意味でのみ近いため、最も近いものに皮肉の引用符を付けました。エニーキャストアドレスの最も近いインスタンスが実際に物理的に最も遠い可能性は十分にあります。
次に、このルートがアドバタイズされるポイントに障害が発生した場合（...ホストでのサービスの障害とルートの撤回、または従来のネットワーク到達可能性の問題の結果である可能性があります）、エニーキャストアドレスにバインドされたパケットは次のようになります。ルートの次に近い（ルーティングプロトコルの用語で）インスタンスにルーティングされます。ネットワークの再コンバージェンス中に、クライアントの解決が失敗して再試行される可能性があります。再試行では、より長いパスをたどって、明らかに同じアドレスに到達します。これはすべて、クライアントプロセスとユーザーの両方に対して透過的であり、ネットワークの観点からは、特定のネットワークへの代替パスをたどると考えるのが最適です。
エニーキャストネットワークを論理的な構成要素と考えると役立つ場合があります。これは、関心のあるサービスを含む仮想サブネットです。その仮想サブネットには、ネットワークを介した多くのパスを介して到達できます。
とはいえ、エニーキャストデザインの主な注意点は次のとおりです。
エニーキャストIPへの特定のパケットが同じ物理ホストに到達するという保証はないため、このアプローチは実際にはコネクションレス型プロトコルにのみマッピングされます。
ソリューションの信頼性は、サービスの正しい動作をルートのアドバタイズに結び付けるロジックと同じくらい優れています。サービスが停止し、ルートが引き続きアドバタイズされる場合、潜在的に重大なブラックホールが発生します。
エニーキャストルートアドバタイズメントを適切に取得し、適切に-パブリックインターネット全体に配信することは簡単ではありません。ホットスポットを作成するのは非常に簡単です。ほとんどのクライアントよりもたまたま好まれるエニーキャストルートの特定のインスタンスです。これは（より簡単なタイプの障害のために）潜在的にまともなHAソリューションですが、負荷分散については説明していません。
さて、最後に、これらすべてがレイアウトされているので、あなたの質問は答えるのが簡単です：
エニーキャストには、DDoSに対する耐性を高めるものは何もありません固有。 DDoSトラフィックの潜在的に数百万のフローのそれぞれは、最も近いインスタンスへの道を見つけ、そうでなければこれらのポイントにルーティングされる他の正当なクライアントが利用できなくなる可能性があります。
ここで、使用中のボットネット上のホストの大部分がたまたま東ヨーロッパにあり、エニーキャストルートの1つがたまたま近くのPoPで発信された場合（ルーティングトポロジの観点からは「近く」）このトラフィックは1つのポイントに沈められますが、世界の他の地域の多くは、他の大陸の便利なポイントでもホストされていた同じルートに解決し続けました。この特定のケースでは、エニーキャストは間違いなくbestメカニズムの1つであり、DDoS攻撃の被害を最小限に抑えます。これは、エニーキャストルートがどのように配布され、ポリシーがどのように構成されているかに大きく依存します（上記の＃3を参照してください-些細な問題ではありません）。
明らかに、このユースケースは、本当に分散であるDDoS攻撃の場合ほど説得力がありません。ただし、適切に設計されている場合、エニーキャストルートのローカリゼーションは、攻撃の負荷を地理的に分散した任意の数の物理ホストに分散できることを意味します。これにより、ターゲットに対する攻撃の影響が薄れるだけでなく、ネットワークのより大きなチャンク全体に影響が広がる可能性があります。繰り返しますが、hugeの金額は、物事がどのように設計および構成されているかによって異なります。
なぜこれがラウンドロビンの勝利と見なされるのですか？個々のIPに個別のロードバランサーを必要とせずに任意の数のホストをデプロイでき、特定のクライアントが別のリゾルバーに移行することを決定するためのタイムアウト値に依存しないという理由だけで。文字通り1000のホストを展開することができますwithin同じIPを持つ単一のデータセンターとそれに応じてトラフィックのバランスをとる（nb-ECMPテーブルのサイズなどに基づく明らかに大規模な実用上の制限）または地理的に異なる1000を展開することができますサイトeach千のホスト。これはすべて、クライアント構成を変更せずに、ロードバランサーの（明らかに通常はクラスター化された）障害点などなしで実現できます。要するに、適切に設計されていれば、インターネット全体と同様に拡張できます。