DNSサーバーのセルフホスティングとアウトソーシング
多分私はここで何かが欠けていると思います、多分誰かが私を啓発することができます。
独自のDNSをホストすることは悪いニュースだと読み続けています。地理的な冗長性、複数のISP接続、何とか何とか何とかを備えた信頼できるプロバイダーを利用する必要があります。現在、独自のDNSをホストしており、すべてをアップグレード中です。そのため、やむを得ない理由がある場合は、ホストされたDNS（DynDNSなど）に切り替える可能性があります。
なぜそれが重要なのか、私は少し混乱しています。 example.com接続がダウンしたり、電源が切れたりなど、冗長性がない場合、example.comのDNS解決がまだ機能しているとしたらどうでしょうか。
Example.com Webアプリの冗長接続、バッテリーバックアップ電源、およびジェネレーターがある場合は、DNSを同じ冗長インフラストラクチャに配置でき、example.comアプリと同じくらい信頼性があります。
提供しているドメイン上のアプリケーションよりもmore信頼できるDNSを使用する理由はありますか？
DNSが信頼できる必要がある理由の1つは、電子メールです。独自の電子メールサーバーもホストしていると仮定して、何らかの理由でシステムがオフラインになったときに何が起こるかを検討してください。
セルフホスト：メッセージを配信しようとするシステムは、ドメインにDNSがないことを確認し、ほとんどの場合（多少依存します）各システムの構成方法について）は、永続的なエラーとしてあきらめます。
より信頼性の高いシステムで外部的にホストされています：送信者はシステムがダウンしていることを検出し、一時的な障害として扱い、続行します通常の再試行ルーチンを介して。
DNSの信頼性は必須です。セルフホストDNSを使用しても問題はありませんが、常にいくつかの大手プロバイダーとミラーリングする必要があります。ドメインのスレーブとしてXName.org、Afraid.org、Puck.nether.netを使用しています。そして、ns2.mydomain.comなどのブランド名を使用できるように、Xnameにいくらかの寄付をしました。
また、ゾーンの有効期限は十分に長くする必要があります（私の場合は1週間で、RFCによると最大です）。サーバーが惨めにダウンしたり、ISPに大きな問題が発生して時間がかかる場合でも、DNSは引き続き存在します。
ダウンタイムが発生しないことを95％以上確信していない限り、メールサーバーをインフラストラクチャから独立させることをお勧めします。ほとんどのメールサーバーは、有効なDNSで障害が発生した場合に2日間試行します。
同じ理由で私はGoogleアプリを使用しています:)
送信するエラーと、そのエラーを人々がどのように解釈するかによって異なります。
DNSがダウンしているために「そのようなマシンはありません」を取得したメールサーバーは、後で配信を再試行する必要がない可能性がありますが、到達不能なIPに解決できた場合は、後で再試行するためにキューに入れる可能性があります。また、理想的には、すべてのメールをキューに入れるオフサイトバックアップMXがあり、ネットに戻ったらメインのメールサーバーがそれを取得します。
ウェブ上では、サイトからのコンテンツのリバースプロキシを実行している何らかのコンテンツ配信ネットワークを使用しない限り、問題にならない可能性があります。その場合、サイトがダウンしていても、一部のコンテンツはキャッシュされ、表示しても問題ありません。 、ただし、CDNを指すDNSがないと、到達できません。
「サービスを提供しているドメイン上のアプリケーションよりも信頼性の高いDNSを使用する理由はありますか？」
Nileshが述べたように、メール用のGoogle Apps for Domainなどのサービスと自己管理サービスを組み合わせて使用するドメイン設定は、サードパーティのDNSプロバイダーを使用する非常に良い理由です。
私はDNS Made Easyを1年以上使用して、そのような設定のためにドメインを正確に管理してきましたが、DNS Made Easyは、過去8年間で100％の稼働率の記録を誇り、ソリューションは月額3米ドル未満から始まり、コストパフォーマンスに優れており、 Amazon、Google、RackspaceのWebインフラストラクチャ！
インフラストラクチャセットアップの次の段階の準備をしているので、DNS Made Easyやなどのサービスを検討してください。 DynDNSは、スクリプトを介して更新できるダイナミックDNSレコードをサポートします。したがって、たとえば、クラウドサービス上にバックアップWebとデータベースをセットアップする場合があります。たとえば、停止やDDoSが原因で、通常のサーバーインフラストラクチャから別のサイトにトラフィックをリダイレクトする必要がある場合、外部モニターシステムがスクリプトを実行し、DNSAレコードを自動的に調整してIPの変更を反映することができます。アドレス。
このタイプのセットアップに関する有用な記事は、Linux Magazine（UK）の2010年8月号にLinux Pro Magazineと呼ばれていると思います。アメリカ。
また、このアマゾンウェブサービスフォーラムのディスカッションでいくつかのアイデアを見つけることができます： http://developer.amazonwebservices.com/connect/message.jspa?messageID=729
DNSは、サービス拒否攻撃の標的となる一般的なサービスでもあり、他のプロバイダーがより適切に対処できる場合があります。
私はほとんどの場合DNSを実行することを好みますが、冗長性のためだけでなく、DNSに加えて外部DNSプロバイダーを使用することには利点があります。
ステルスDNSを実行することにより、独自のゾーンを直接維持しながら、インターネット上にフットプリントを持たないという利点を得ることができます。外部プロバイダーは、実行しているDNSをスレーブにしますが、ファイアウォールを介してDNSにアクセスできるのはプロバイダーだけです。これは私がよく使用する構成です。