DNSサーバーは既にエニーキャストを使用しています。IPを追加するとスケーラビリティが向上しますか？

RFC 1034では、DNSサーバーに少なくとも2つのIPアドレスを割り当てる必要があります。ただし、エニーキャストアドレス指定を使用すると、単一のIPアドレスで冗長性を既に実現できます。BGPエニーキャストは、数百または数千のサーバーにまで拡張できるようです。

もしそうなら、それでもDNSサーバーに複数のIPアドレスが必要なのはなぜですか？すでにエニーキャストを実施している場合、それは実際に冗長性を高めます（可用性に貢献します）か、それとも単なる神話ですか？

単一のIPアドレスのみを使用する場合、どのような問題やエラーに直面する可能性がありますか？

つまり、セカンダリDNSアドレスを完全に省略1.2.3.4するか、いくつかのセットアップで少なくとも2つ必要な場合は、2番目のアドレスに偽のIP（例:)を使用します。

単一のエニーキャスト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つのサーバー、および2つのエニーキャストIPがある場合、各大陸にまたがる1つのプールを作成しません。ヨーロッパの2つを北アメリカの3つのプールに入れ、残りの5つを他のプールに入れます。

エニーキャストプールが3つ以上ある場合は、物理サーバーを一時的に複数のプールに入れることができます。ただし、物理サーバーがすべてのプールに同時に存在することを許可しないでください。

エニーキャストとユニキャストの組み合わせは可能ですが、注意が必要です。2つのプールのIPがある場合は、組み合わせません。ただし、使用するエニーキャストIPが1つしかない場合は、ユニキャストIPを含めることもできます。問題は、ユニキャストIPを含めても、優れた遅延と負荷分散が得られないことです。

物理サーバーがユニキャストとエニーキャストの両方で使用できるようになっている場合、ユーザーがプライマリとセカンダリとして同じサーバーに到達し、サーバーがダウンした場合にアクセスできなくなる可能性があります。これは、エニーキャストプールにないサーバーのユニキャストアドレスのみを使用するか、常にユーザーに2つのユニキャストアドレスを提供することで回避できます。

ミックスに入れるユニキャストアドレスが多いほど、エニーキャストアドレスに送信されるクエリが少なくなり、レイテンシとスケーラビリティに関してエニーキャストから得られるメリットが少なくなります。

ベストプラクティスは、異なるプレフィックスから少なくとも2つのアドレスを使用し、それらに2つの異なるTLDで名前を付けることです。必要に応じて、これらのアドレスはどちらもエニーキャストにすることができます。IPアドレスが1つしかない場合、単一障害点が発生します。そのアドレスへのルーティングが機能しない場合（構成エラー、エニーキャストインスタンスが正しく機能していない、プレフィックスがハイジャックされているなど）、ドメイン全体に到達できなくなります。

すべてのエニーキャストアドレスには、BGPでルーティングできるように/24、少なくともIPv4または/48IPv6プレフィックスが必要です。通常、小さい（長い）プレフィックスは、多くの場所のグローバルルーティングテーブルで受け入れられません。

決してこれまでの DNSサーバとして偽のIPアドレスを入れていません。リゾルバに深刻な遅延を引き起こします。

RFC 1034には、2つのDNSサーバーが必要であるとのみ記載されています。これは必須の要件ではありませんが、推奨事項なので、必要に応じて実行してください。とにかく、HAが必要な場合は、エニーキャストを使用して2つのDNSサーバーに同じIPを割り当てることができ、1つのDNSサーバーに障害が発生したときにエンドユーザーが気付くのは、ネットワークが再収束するときに接続が一時的に失われることだけです。

つまり、要約すると、エニーキャストを使用すれば、RFC 1034に準拠するには十分です。