DNS Aレコードが持つことができるIPの最大数はいくつですか？
私は奇妙な考えを持っています-複数の人/組織に同じアプリケーションをホストさせ、それらのすべてのノードに単一のドメイン名を介してアクセスできるようにします。これは、使いやすさを犠牲にすることなく、実際に分散したソーシャルネットワークを実現するためです（つまり、ユーザーは異なるプロバイダーのURLを覚える必要がなく、プロバイダーがダウンしたときに別のプロバイダーに切り替えます）。
そのために、複数のIPを持つDNSレコードを使用できると思いました。
では、1つのDNS AレコードでいくつのIPを保持できるのでしょうか。 この答え は30前後だと言っていますが、ユースケースは異なります。上記のシナリオでは、特定のISPが30のみをキャッシュするかどうか、別のISPが別のISPをキャッシュするかどうかは気にしません。
免責事項：違反はありませんが、これは本当に悪い考えです。実際にこれを行うことはお勧めしません。
しかし、退屈なIT担当者にラボを提供すると、面白いことが起こります。
この実験では、Server 2012 R2で実行されているMicrosoft DNSサーバーを使用しました。 Active DirectoryでDNSゾーンをホストすることの複雑さのために、testing.comという名前の新しいプライマリゾーンを作成しましたnot AD統合されています。
このスクリプトを使用する：
$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.の65025 Hostレコードを作成しました。文字どおり、1.1.1.1から1.1.255.255までのすべてのIPv4アドレスを使用します。
次に、エラーなしで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レコードのリストは、連続するクエリごとに1ずつ適切にローテーションします、ラウンドロビンDNSが機能することを期待するのとまったく同じように、これらすべてのラウンドロビンに何百万ものクエリが必要です。
これが非常にスケーラブルで回復力のあるソーシャルメディアネットワークを作成するのにどのように役立つかはわかりませんが、それでも答えはあります。
編集：フォローアップコメントで、これが一般的に悪い考えだと私が思う理由を尋ねます。
私は平均的なインターネットユーザーで、サービスに接続したいとします。 Webブラウザーにwww.bozho.bizと入力します。コンピューターのDNSクライアントが1000レコードを取得します。まあ、残念ですが、リストの最初の30レコードは応答しません。Aレコードのリストが最新の状態になっていないか、インターネットのチャンクに影響を与える大規模な停止があるためです。 WebブラウザーのIPごとに5秒のタイムアウトがあり、次のIPブラウザーに移動して試行するとします。だから今私はここに座って、あなたのサイトがロードされるのを待って、回転する砂時計を2分半見つめています。そのための時間は誰にもありません。また、私のWebブラウザーや、サービスへのアクセスに使用するアプリケーションが、最初の4個または5個以上のIPアドレスを試行することさえ想定しているだけです。それはおそらくしません。
自動清掃を使用し、Aレコードのリストを最新の状態に保つことを期待して、DNSゾーンへの検証されていない、または匿名の更新を許可する場合...それがどれほど安全でないか想像してみてください！クライアントがゾーンを更新するためにクライアントから事前に取得したクライアントTLS証明書を必要とするシステムを設計したとしても、侵害されたクライアントが地球上のどこにいてもボットネットを開始し、サービスを破壊します。従来のDNSはクラウドソーシングを行わないため、現状のままでは不安定で危険です。
膨大な帯域幅の使用と無駄。すべてのDNSクエリが32キロバイト以上の帯域幅を必要とする場合、それはまったく適切にスケーリングされません。
DNSラウンドロビンは、適切なロードバランシングに代わるものではありません。あるノードがダウンしたり、途中で使用できなくなったりした場合に回復する方法はありません。接続先のノードがダウンした場合に、ユーザーに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回に増加します。しかし、さらに悪いことに、TCPを介したDNSが機能しないように構成を誤ることがあります。
DNS層で問題を引き起こさずに14を超えるアドレスを応答に詰め込むことができたとしても、それが非常に役立つことはほとんどありません。多くの場合、1つのアドレスをあきらめて次のアドレスに進む前にクライアントが使用するタイムアウトは重要です。
一度でもそのタイムアウトを待つ必要があると、ユーザーエクスペリエンスが低下する可能性があります。クライアントが応答を受け取る前に14のアドレスを経由する必要がある場合、ユーザーは13のタイムアウトを待つ必要があります。
あなたが説明しているのは、特に新しいアイデアではありません。他の回答がすでにカバーしているので、1つの応答で使用できるAレコードの数には制限がありますが、合計でAレコードがいくつあるかについては何も言えません。
たとえば、ランダムなIPでAレコードのクエリに応答するDNSサーバーを実装できます。十分な回数のクエリを実行すると、4294967296の一意のAレコードが生成されます（各IPv4アドレスに1つ）。
私が言ったように、これは新しい考えではありません。実際、それは一部です Akamaiの仕組み （そしておそらく他の多くのCDN）。アカマイドメインで取得する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
きっとやってみれば、違う答えが返ってくるでしょう。 Akamaiが特定のリソースを提供しているエッジサーバーはいくつありますか？ 2つ以上、私は賭けます。
他の人がそれを詳細として述べましたが、実際的な見地から、ハード制限は512バイトのUDPパケットサイズ制限です。切り捨てが検出されたときにTCP=に切り替えることは可能ですが、実際には多くの/ほとんどのクライアントはそれを行わないでしょう（そしておそらくそうすべきではありません。それはほとんどのアプリケーションに悪いユーザーエクスペリエンスを与えるでしょう。私はゾーン転送またはその他の特別な目的のルックアップのみがTCPをサポートすることを期待します。そのため、IPv4（Aレコード）の場合は約30アドレス、IPv6（AAAA）の場合はそれよりも大きいという制限を検討しています。 。ドメイン名の長さがこれに割り込んで、数をさらに制限します。
短い答え：UDPパケットに収まる約25 Aのレコード。それを超えると、DNSはTCPに切り替わり、それほど速くありません。また、「最も近い」IPを選択できるDNSリゾルバーを使用していないクライアントにも問題があります。また、 、wifiとモバイルでは、「最も近い」ものは適切なサーバーではないことがよくあります。
より長い答え：
それをしないでください。より適切な方法は、適切なサーバーを指すユーザーごとに個別のCNAMEレコードを設定することです。 IMAPに使用されるserver-fとserver-rの2つのサーバーがあるとします。サーバー名を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はDNSレコードを拡張し、MXクエリが> 512バイトを返すようにしました。これはRFCに違反し、多くのSMTPサーバー（現時点ではqmailが人気のサーバー）を破壊し、システム管理者に多くの問題を引き起こしました。修正には patching 、または静的ルートの追加が必要でした。
現在の状況はわかりませんが、数年前に最後にqmailに触れたとき、パッチはまだ残っていました。