DNSサーバーは既にエニーキャストを使用しています。 IPを追加すると、スケーラビリティが向上しますか？
RFC 1034 DNSサーバーに少なくとも2つのIPアドレスを割り当てる必要があります。ただし、エニーキャストアドレス指定を使用すると、単一のIPアドレスで冗長性を既に実現できます。 BGPエニーキャストは、数百または数千のサーバーにまで拡張できるようです。
もしそうなら、それでもDNSサーバーに複数のIPアドレスが必要なのはなぜですか？エニーキャストがすでに配置されている場合、それは実際に冗長性を強化しますか（可用性に貢献します）、それとも単なる神話ですか？
単一のIPアドレスのみを使用する場合、どのような問題とエラーが発生すると予想されますか？
つまり、セカンダリDNSアドレスを完全に省略するか、偽のIPを使用することを意味します（例：1.2.3.4）一部のセットアップで少なくとも2つ必要な場合は、2番目のアドレス。
単一のエニーキャストIPアドレスは、別個のIPプレフィックス内の2つのユニキャストIPアドレスと同じ冗長性を提供しません。
多くの場合、冗長性の最も難しい問題は、何かが完全に失敗したときではなく、ヘルスチェックに合格するのに十分なだけの誤動作であるが、実際には機能していない場合です。
DNSサーバーがダウンしたエニーキャストDNSセットアップを見たことがありますが、パケットは引き続きそのDNSサーバーにルーティングされます。プレフィックスのアドバタイズを処理していたものは何でも、DNSサーバーがダウンしたことを単に認識していない可能性があります。
問題のDNSサーバーが信頼できるDNSサーバーではなく、再帰的なリゾルバーである場合は、さらに注意が必要です。
このような再帰的リゾルバーには、クライアントからクエリを受信するためのエニーキャストアドレスと、信頼できるDNSサーバーにクエリを実行するためのユニキャストアドレスの両方が必要です。ただし、ユニキャストアドレスがダウンした場合でも、クエリがルーティングされるほど正常に見える可能性があります。
エニーキャストは、スケーラビリティとレイテンシーの削減に最適なツールです。しかし、冗長性のために、それは独立してはいけません。
ただし、複数の冗長エニーキャストプールは、可用性のための優れたソリューションです。よく知られている例は8.8.8.8と8.8.4.4です。どちらもエニーキャストアドレスですが、同じ物理DNSサーバーにルーティングしないでください（Googleが適切に機能していると想定しています）。
10台の物理DNSサーバーがある場合、各プールに5台のサーバーがある2つのプール、または各プールに2台の5つのプールとして構成できます。 1つの物理DNSサーバーが同時に複数のプールに存在することを避けたいと考えています。
では、いくつのIPを割り当てる必要がありますか？互いに独立してエニーキャストとして構成できるIPが必要です。これは通常、各プールにIPv4アドレス空間の/ 24全体またはIPv6アドレス空間の/ 48を割り当てる必要があることを意味します。これにより、使用できるプールの数が制限される可能性があります。
さらに、信頼できるサーバーについて話している場合、すべてのNSレコードとAおよびAAAA接着剤を含むDNS応答は、単一の512バイトパケットに収まるはずです。ルートサーバーの場合、これは13アドレスになります。しかし接着剤とIPv6が含まれていなかったため、到達する数は少なくなります。
各プールは、可能な限り地理的に分散させる必要があります。ヨーロッパに5台、北アメリカに5台、エニーキャストIPが2台ある場合、各大陸にまたがる1つのプールを作成することはありません。ヨーロッパの2つを北アメリカの3つのプールに入れ、残りの5つを他のプールに入れます。
エニーキャストプールが3つ以上ある場合は、物理サーバーを一時的に複数のプールに入れることができます。ただし、物理サーバーがすべてのプールに同時に存在することを許可しないでください。
エニーキャストとユニキャストを組み合わせることができますが、注意が必要です。 2つのプールのIPがある場合、私は結合しません。ただし、使用するエニーキャストIPが1つしかない場合は、ユニキャストIPも含めるのが理にかなっています。問題は、ユニキャストIPを含めると、レイテンシーと負荷分散がそれほど良くないことです。
物理サーバーがユニキャストとエニーキャストの両方で使用可能になっている場合、ユーザーがプライマリサーバーとセカンダリサーバーと同じサーバーに到達し、サーバーがダウンするとアクセスできなくなるリスクがあります。これは、エニーキャストプールにないサーバーのユニキャストアドレスのみを使用するか、常に2つのユニキャストアドレスをユーザーに提供することで回避できます。
ミックスに入れるユニキャストアドレスが多いほど、エニーキャストアドレスに送信されるクエリが少なくなり、レイテンシとスケーラビリティの点でエニーキャストから得られるメリットが少なくなります。
ベストプラクティスは、異なるプレフィックスからの少なくとも2つのアドレスを使用し、2つの異なるTLDで名前を付けることです。必要に応じて、これらのアドレスはどちらもエニーキャストにすることができます。 IPアドレスが1つしかない場合、単一障害点が発生します。そのアドレスへのルーティングが機能しない場合（構成エラー、エニーキャストインスタンスが正しく機能していない、プレフィックスがハイジャックされているなど）、ドメイン全体に到達できなくなります。
すべてのエニーキャストアドレスは、BGPでルーティング可能であるために、少なくとも/24IPv4または/48IPv6プレフィックスを必要とします。通常、小さい（長い）プレフィックスは、多くの場所のグローバルルーティングテーブルで受け入れられません。
決してever DNSサーバーとして偽のIPアドレスを入力しないでください。リゾルバに深刻な遅延が発生します。
RFC 1034には、2つのDNSサーバーが必要であるとのみ記載されています。これは必須の要件ではありませんが、推奨事項なので、必要に応じて実行してください。とにかく、HAが必要な場合、2つのDNSサーバーにエニーキャストを使用して同じIPを割り当てることができます。1つのDNSサーバーに障害が発生したときにエンドユーザーが気付くのは、ネットワークが再収束するときに接続が一時的に失われることだけです。
つまり、要約すると、エニーキャストを使用すれば、RFC 1034に準拠するには十分です。