私はいつも、TLD (たとえば .com) の DNS インフラストラクチャがどのように設計されているのか疑問に思っていました。高いレベルの信頼性を維持できるだけでなく、大量のレコードのリアルタイム更新もサポートする必要があります。
ISC の BIND はそのレベルで使用されていると思います。BIND を使用してスケーラブルなインフラストラクチャを構築する方法については、かなり明確なイメージを持っています。不明なのは、数百の DNS ゾーンの追加、削除、変更を数秒ごとに処理できるシステムを設計する方法です。世界には無数のドメイン レジストラがあり、.com だけでも膨大な量のアクティビティが行われていると考えられます。BIND ゾーン ファイル上に構築されたシステムは、どのようにしてそれほど大きな変更に対応できるのでしょうか。
TLD オペレーターがテキスト ファイルを使用して、新しい .com が登録されるたびに BIND に変更を常に再ロードさせているのではないかと疑うのは正しいでしょうか。もしそうなら、彼らは何をしているのでしょうか。SQL または LDAP データベースがバックアップされているのでしょうか。それは拡張可能でしょうか。
答え1
まず、世界では、1 秒あたりのクレジットカード取引よりも多くの更新が、最終的に 2 社か 3 社によって管理されていると本当に思いますか? これらは機能するので、解決可能な問題です :-)
2 番目に、更新がどのように行われているのか混乱するかもしれません。これは、登録プレーンと公開プレーンという 2 つのプレーンが交差する部分で、あまり理解されていないためです。レジストリ ネーム サーバーで実際に何が起こっているのかについても混乱するかもしれません (ドメインのNS委任のレコードのみを維持し、それらのゾーンの完全なコンテンツは維持しません)。
しかし、その前に、更新はリアルタイムであるべきだと想定しているようですが、実際にはそうである必要はなく、またそうではないこともよくあります。DNS では、TTL があるため、とにかく何もリアルタイムではありません。
では、2 つの飛行機に戻りましょう。
- レジストラは、ネームサーバーが変更されたときや、DNS の副作用があるその他の操作 (例: EPP
clientHoldステータスの設定) があったときに、レジストリに更新を送信します。これは登録プレーンであり、DNS 公開とは完全に無関係であり、通常は EPP と呼ばれるプロトコルを使用します。レジストリが「更新が受け入れられました」と応答した場合、それは DNS インフラストラクチャですでに公開されていることを意味するわけではなく、「いつか公開される」という保証にすぎません。 NSレジストリは DNS 公開プレーンを維持し、ネームサーバーがすべての委任、つまり管理する TLD に登録されているすべてのドメインに対して正しいレコードを公開していることを確認します。
そのため、変更の数はおそらくあなたが考えているよりもはるかに少ないでしょう。.com所有者が新しいレコードを使用してゾーンの内容を変更した場合、ほとんどの場合、レジストラを通じて行う操作はなく、レジストリの権威ネームサーバーでは何も変更されません。
そして、これらの変更は DNS 更新メカニズムを通じて行われるわけではありません。変更は、特定のプロトコル (EPP) を使用してレジストラによってプッシュされ、何らかの方法でレジストリ データベースに保存され、その後、新しいデータがレジストリによってその権威ネーム サーバーに公開されます。
また、あなたは「リアルタイム」が必須だと考えているようですが、少なくとも技術的にはそうではありませんし、非効率的な設計である可能性もあります (一部のレジストリが行っているように、新しい変更が意味をなすかどうかをテストする場合は、ネーム サーバーが、まもなく権威としてリストされる名前の解決のために正しく構成されているかどうかをチェックするか、DNSSEC テストなどを検討してください...)。
「更新の 10 分遅延」や「1 時間」などを提供する多くのレジストリで使用されている一般的な設定方法は、指定された期間内に要求されたすべての変更を何らかの内部バッファーに保存し、新しいゾーンを一度に生成して公開し、次の期間に発生するすべての変更を収集するための新しいバッファーを開始するというものです。
ISC の BIND がそのレベルで使用されていると想定します。
いいえ、そうではありません。VerisignはAtlasと呼ばれる独自のネームサーバーソフトウェアを運用しています。例えば、https://www.enterpriseappstoday.com/news/verisign-accelerates-dns.html 2004 年のこの記事ですでに次のように述べられていることに注意してください。
VeriSign Naming and Directory Services (VNDS) は、コア 13 の .com および .net の権威ネーム サーバーを 5 分以内に更新することを約束しています。現在のレートは 1 日あたり約 2 回です。
もちろん、それ以降は改善されています。しかし、DNS の実際の使用には、5 分に 1 回でも十分だと考えています。
契約上の義務もあるかもしれません。特に、ICANNと契約しているgTLDレジストリとレジストラには義務があります。現在のVerisign-ICANN契約は次のとおりです。https://www.icann.org/en/registry-agreements/details/com 付録の§6.6をご覧ください。https://www.icann.org/en/registry-agreements/com/com-registry-agreement-appendix-7-1-12-2012-en更新制約の詳細:
6.6 更新頻度。レジストリ オペレータは、DNS ネーム サーバーと Whois のデータを適時に更新します。ICANN 認定レジストラは、これらの更新を SRS を通じて記録します。その後、SRS は DNS ネーム サーバーと Whois を更新します。レジストリ オペレータは、この更新をほぼリアルタイムで処理します。
DNS ネーム サーバーと Whois の両方の更新頻度に関する確約されたパフォーマンス仕様は、月間期間中のトランザクションの 95% に対して 3 分です。つまり、月間期間中の DNS ネーム サーバーと Whois への更新の 95% は 3 分以内に完了します。更新頻度は、レジストリ オペレータが更新を確認してから、DNS ネーム サーバーと Whois に更新が表示されるまでの時間で測定されます。更新頻度のパフォーマンスは、付録 4 に従って毎月 ICANN に報告されます。
多くの SLA で使用される通常のマーク「95%」に注意してください。したがって、実行可能な場合はほぼリアルタイムですが、実際には通常 3 分です (したがって、上記の一般的なバッファ設定になります)。
BIND を使用してスケーラブルなインフラストラクチャを構築する方法については、かなり明確なイメージを持っています。不明なのは、数秒ごとに数百の DNS ゾーンの追加、削除、変更を処理できるシステムをどのように設計するかということです。
.comVerisign には、、、いくつかの IDN など、いくつかのゾーンしかありません。.net彼らは「何百ものゾーン」を管理していません。そして、毎秒多くの変更が行われる何百ものゾーンを管理することは絶対にありません。
更新頻度が高く、数百万のゾーンをホストしている DNS プロバイダーにもっと興味を持つかもしれません。以下は、CloudFlare が権威 DNS サービスに関してパフォーマンス面で何をしているかを説明している記事です。https://blog.cloudflare.com/how-we-made-our-dns-stack-3x-faster/
世界には無数のドメイン登録業者が存在する
いいえ、すべてではありません。無数ではありません。実際には 2000 未満で、変更量が多いアクティブなのはおそらく 500 程度でしょう。gTLD のすべてのレジストラは ICANN の認定を受けなければなりません。レジストラの全リストは、こちらでご覧いただけます。https://www.icann.org/en/accredited-registrars
TLD オペレーターがテキスト ファイルを使用して、新しい .com が登録されるたびに BIND に変更を常に再ロードさせているのではないかと疑うのは正しいでしょうか?
まともな高レベルのトランザクション ネームサーバー ソフトウェアは、テキスト ファイルでバックアップされません。Bind でさえも、テキスト ファイルでバックアップされません。動的更新が有効になっている場合は、「ジャーナル」ファイル (バイナリ) があり、ゾーンのテキスト ファイル バージョンは特に編集しないでください (最初に更新を凍結し、編集後に再度更新を許可しない限り)。
もしそうなら、彼らは何をするのでしょうか? SQL または LDAP データベースがバックアップされていますか? それは拡張可能ですか?
SQL も LDAP も DNS に適したストレージ エンジンではないと思います。DNS は本質的に階層的であり、さまざまな制約があることを覚えておいてください。
答え2
まず、場合によってはすぐにリロードする必要はありません。
「料金を支払えば、X 時間以内にドメインを登録します」という SLA がある場合は、cron ジョブなどを使用して定期的にリロードすることもできます。そのため、一部のレジストラはフラット ファイルを使用して定期的にリロードしている可能性があります。
複数の DNS サーバーを同じ IP アドレスに関連付けることもできるので (たとえば、エニーキャストを使用)、フラット ファイルをすべての場所で変更し、一度に 1 つの DNS サーバーをリロードする「ローリング デプロイ」メカニズムを設定することもできます。
とはいえ、Bind >9 は DLZ (Dynamically Loadable Zones) をサポートしており、基本的に Bind はデータベースをゾーン データ バックエンドとして使用できるようになります。データベース用の有効な DLZ ドライバーがある限り、データベース (およびデータベース接続) は従来のデータベース スケーリング戦略に従ってスケーリングできます。
最後に、あるコメントにもあるように、垂直スケーリング（つまり、各サーバーに大量の CPU、RAM、IOPS があること）が役立ちます。
2009年版サノグ明らかに少し古くなっていますが、興味深いスライドだと思います。https://www.sanog.org/resources/sanog14/sanog14-devdas-dns-scalability.pdf