DNS Aレコードが持つことができるIPの最大数はいくつですか？

私は奇妙なアイデアを持っています-複数の人/組織が同じアプリケーションをホストし、すべてのノードが単一のドメイン名を介してアクセスできるようにします。それは、例えば、ユーザビリティを犠牲にしない、本当に分散されたソーシャルネットワークを持つためです（つまり、ユーザーは異なるプロバイダーのURLを覚える必要がなく、あるプロバイダーがダウンしたときに別のプロバイダーに切り替えます）

それを実現するために、複数のIPを持つDNSレコードを使用できると考えました。

それでは、1つのDNS Aレコードが保持できるIPの数はいくつですか？この答えは、それがおよそ30であると言いますが、そこでのユースケースは異なります。上記のシナリオでは、特定のISPが30だけをキャッシュしても、別のISPがもう30をキャッシュする限りは気にしません。

免責事項：違反はありませんが、これは本当に悪い考えです。実生活でこれを行うことはお勧めしません。

しかし、退屈したIT担当者にラボを提供すると、面白いことが起こります。

この実験では、Server 2012 R2で実行されているMicrosoft DNSサーバーを使用しました。Active DirectoryでDNSゾーンをホストすることは複雑であるため、AD統合されていない testing.comという名前の新しいプライマリゾーンを作成しました。

このスクリプトの使用：

$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
    for ($y = 1; $y -lt 256; $y++)
    {
        for ($z = 1; $z -lt 256; $z++)
        {
            Write-Host "1.$x.$y.$z`t( $Count )"
            $Count++
            dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
        }
    }
}

testing.testing.com.1.1.1.1から1.1.255.255までのすべてのIPv4アドレスを使用して、名前の65025ホストレコードをエラーなしで作成しました。

それから、エラーなしで合計65536（2 ^ 16ビット）のAレコードを突破できることを確認したかったので、おそらく16581375（1.1.1.1から1.255まで）に到達できたと思います。 .255.255））しかし、私はここに座ってこのスクリプトが一晩中実行されるのを見たくありませんでした。

したがって、サーバー上の異なるIPを持つ同じ名前のゾーンに追加できるAレコードの数に実質的な制限はないと言っても安全だと思います。

しかし、それは実際になります動作し、クライアントの視点から？

Wiresharkから見たクライアントから得たものは次のとおりです。

（フルサイズの画像を新しいブラウザタブで開きます。）

ご覧のとおり、nslookupまたはpingをクライアントから使用すると、UDPとTCPの2つのクエリが自動的に発行されます。既にご存知のように、UDPデータグラムに詰め込むことができるのは512バイトなので、その制限を超えると（20〜30個のIPアドレスなど）、代わりにTCPを使用する必要があります。しかし、TCPを使用しても、testing.testing.comのAレコードの非常に小さなサブセットしか取得できません。TCPクエリごとに1000レコードが返されました。Aレコードのリストは、ラウンドロビンDNSが機能すると予想される方法とまったく同じように、連続するクエリごとに1ずつ適切にローテーションします。これらすべてをラウンドロビンでラウンドするには何百万ものクエリが必要です。

これがどのようにあなたがあなたの非常にスケーラブルで回復力のあるソーシャルメディアネットワークを作るのに役立つかわかりませんが、それでもあなたの答えがあります。

編集：フォローアップコメントで、なぜこれが一般的に悪い考えだと思うのかを尋ねます。

• 私は平均的なインターネットユーザーであり、あなたのサービスに接続したいとします。Webブラウザにwww.bozho.bizと入力します。コンピューター上のDNSクライアントは1000レコードを取得します。残念ながら、リストの最初の30レコードは応答しません。これは、Aレコードのリストが最新に保たれていないか、インターネットの大部分に大規模な停止が影響している可能性があるためです。私のWebブラウザーは、IPごとに5秒のタイムアウトがあり、次のIPに移行する前にタイムアウトするとします。だから今、私はここに座って、あなたのサイトがロードされるのを待って、2分半回転する砂時計を見つめています。誰も時間がありません。そして、私のウェブブラウザまたはあなたのサービスにアクセスするために使用するどんなアプリケーションでも、最初の4つまたは5つ以上のIPアドレスを試みることさえしようとしているだけです。それはおそらくないでしょう。

• Aレコードのリストを最新に保つことを期待して、自動清掃を使用し、検証されていない、または匿名のDNSゾーンへの更新を許可する場合...それがどれほど安全でないか想像してみてください！クライアントがゾーンを更新するために事前に取得したクライアントTLS証明書を必要とするシステムを設計した場合でも、地球上のどこかで侵害されたクライアントがボットネットを開始してサービスを破壊します。従来のDNSは、クラウドソーシングを使用せずに、不安定な状態のままです。

• 膨大な帯域幅の使用と無駄。すべてのDNSクエリが32キロバイト以上の帯域幅を必要とする場合、それはまったくうまくいきません。

• DNSラウンドロビンは、適切な負荷分散に代わるものではありません。1つのノードがダウンしたり、物事の途中で使用できなくなったりすることから回復する方法はありません。接続しているノードがダウンした場合に、ユーザーにipconfig / flushdnsを実行するように指示しますか？これらの種類の問題は、GSLBやAnycastなどによってすでに解決されています。

• 等。

記載されている質問に答えるには（「単一のDNS AレコードにいくつのIPを保持できますか？」）、答えは非常に簡単です。単一のAレコードに1つのアドレスが保持されます。ただしA、同じ名前に対して複数のレコードが存在する場合があります。

各IPv4アドレスは、応答で16バイトを占有します。各IPv6アドレスは、応答で28バイトを使用します。

応答が512バイトに収まるようにすることを強くお勧めします。これにより、約25個のIPv4アドレスと14個のIPv6アドレスが可能になります（パケットに他の情報も必要であると考えると）。正確な制限は、ドメイン名の長さによって異なります。

25個のIPv4アドレスと14個のIPv6アドレスの両方がある場合、クライアントは別々のクエリでIPv4アドレスとIPv6アドレスを要求します。クライアントが単一のクエリで両方のタイプのアドレスを要求した場合（まれですが）、低くする必要があります。

応答サイズが512バイトを超えても、クライアントとサーバーがEDNSをサポートしている場合、UDPで動作する可能性があります。EDNSがない場合、クライアントは切り捨てられた応答を受信し、TCPで再試行する必要があります。これにより、通信が1往復から4往復に増加します。しかし、さらに悪いことに、DNS over TCPの機能を妨げる設定ミスが時々あります。

DNS層で問題を引き起こすことなく14個を超えるアドレスを返信に絞り込めたとしても、それが非常に役立つことはまずありません。クライアントが1つのアドレスを放棄して次のアドレスに進む前に使用するタイムアウトは、しばしば重要です。

そのタイムアウトを一度でも待たなければならない場合、ユーザーエクスペリエンスが低下する可能性があります。クライアントが応答を取得する前に14個のアドレスを経由する必要がある場合、ユーザーは13個のタイムアウトを待つ必要があります。

あなたが説明していることは、特に新しいアイデアではありません。他の回答で既に説明したように、1回の返信で取得できるAレコードの数には制限がありますが、合計でAレコードがいくつあるかについては言及していません。

たとえば、ランダムIPを持つAレコードのクエリに応答するDNSサーバーを実装できます。十分な回数照会すると、一意のAレコードが4294967296になります（各IPv4アドレスに1つ）。

私が言ったように、これは新しいアイデアではありません。実際、それは一部ですアカマイがどのように機能するか（そしておそらく他の多くのCDN）の一部です。Akamaiドメインについて取得するAレコードは、ブラックマジックDNSサーバーによって決定されます。答えは、動的な負荷分散と地理的な懸念に依存すると確信しています。

たとえば、a338.g.akamaitech.netを選択しました。私のコンピューターで、ComcastからDHCPが割り当てたネームサーバーを使用しているものを見ると：

$ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

GoogleのDNSに問い合わせるとどうなりますか？

$ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

あなたがそれを試してみればきっと違う答えが返ってくるに違いない。アカマイは特定のリソースを提供するエッジサーバーをいくつ持っていますか？2つ以上、私は賭けます。

他の人はそれを詳細として言及しましたが、実用的な観点から、ハード制限は512バイトのUDPパケットサイズ制限です。切り捨てが検出されたときにTCPに切り替えることは可能ですが、実際には多くの/ほとんどのクライアントはそれを行いません（そしておそらくそうすべきではありません。ほとんどのアプリケーションに悪いユーザーエクスペリエンスを与え、ゾーン転送または他のことだけを期待しますTCPをサポートするための特別な目的の検索）。したがって、IPv4（Aレコード）の場合は約30アドレス、IPv6（AAAA）の場合はそれよりも大きいため、約30アドレスの制限を見ています。ドメイン名の長さはこれをカットし、さらに数を制限します。

短い答え：約25のAレコードがUDPパケットに収まります。それを超えると、DNSはTCPに切り替わり、高速ではなくなります。また、「最も近い」IPを選択できるDNSリゾルバーを使用していないクライアントにも問題が発生します。また、wifiとモバイルでは、「最も近い」サーバーが適切なサーバーにならないことがよくあります。

より長い答え：

それをしないでください。より適切な方法は、適切なサーバーを指すユーザーごとに個別のCNAMEレコードを設定することです。2つのサーバーがserver-fありserver-r、IMAPに使用されているとします。サーバー名がUSERNAME.imap.example.comである各ユーザーのIMAPクライアントを構成します。ここで、「USERNAME」は電子メールユーザー名に置き換えられます。メールクライアントを再構成することなく、サーバー間でユーザーを移動できるようになりました。

server-f.example.com. IN A 10.10.10.10 server-r.example.com. IN A 10.20.20.20 wilma.imap.example.com. IN CNAME server-f.example.com. fred.imap.example.com. IN CNAME server-f.example.com. betty.imap.example.com. IN CNAME server-r.example.com. barney.imap.example.com. IN CNAME server-r.example.com.

ただし、これを行う場合は、ユーザーのデータベースからDNSレコードを自動的に生成することを強くお勧めします。アカウントが作成および削除されると、DNSレコードも作成および削除されるようにする必要があります。そうしないと、混乱と多くの混乱が発生します。

これは文字通り何千人ものユーザーがいる企業で行われているのを見てきましたが、自動化されたため、非常にうまくいきました。

他の人が指摘しているように、それは実世界で使用するためのひどいアイデアです。

現実の世界には、単一のUDPデータグラムに収まらない応答に問題がある非準拠のクライアントとリゾルバーがあり、DNSメッセージサイズの制限に関する特定の、ただしプロトコルに準拠していないアイデアを実施するファイアウォールがあります。

そして、あなたがどんな場合でもあなたの巨大な反応が得られると信じることができたとしても（あなたはそれを強調することはできません）、これが非常に悪い考えである別の理由があります。DNS応答サイズが大きいほど、巨大な増幅係数を提供するため、リフレクション攻撃のペイロードとして魅力的です。DNSで一般的なこのタイプのサービス拒否攻撃では、UDPクエリがオープンな再帰リゾルバーに送信されます。通常、UDPクエリのソースアドレスは簡単にスプーフィングされ、攻撃者はクエリソースを目的のターゲットのIPに設定します。2つの望ましい（攻撃者にとって）効果が得られます：1つ目-（小規模なスプーフィングクエリからの）比較的小さな送信努力により、標的に到着する望ましくないトラフィックの比較的大きな急流が発生します（これが増幅係数です）。2つ目-攻撃の実際のソースはターゲットから隠されています。ターゲットは、リフレクターとして使用されている再帰リゾルバーのアドレスのみを知っています。

このテーマに関する歴史的なトリビアの興味深い点。90年代に、AOLは、MXクエリが512バイト以上を返すようにDNSレコードを拡張しました。これはRFCに違反し、多くのSMTPサーバーを壊し（qmailは当時人気がありました）、システム管理者に多くの頭痛の種を引き起こしました。修正には、パッチを適用するか、静的ルートを追加する必要がありました。

現在の状況はわかりませんが、数年前、最後にqmailに触れたとき、パッチはまだ適用されていました。

http://www.gossamer-threads.com/lists/qmail/users/30503