独自のネームサーバーをホストする必要がありますか？
これは 標準的な質問 自分のドメインのDNS解決を外部委託するかどうかについてです
現在、ISPにドメインのDNSを提供していますが、レコードの追加に制限があります。したがって、私は自分のDNSを実行することを考えています。
独自のDNSをホストする方が好きですか、それともISPにこれを実行させる方が良いですか。
調査できる代替案はありますか？
自分のDNSサーバーは実行しません。私の場合、私のWebサイトをホストしているホスティング会社が無料のDNSサービスを提供しています。他にも選択肢があります。DNSホスティング（ DNS Made Easy が頭に浮かびますが、他にもたくさんあります）しか行わない企業は、おそらく調査する必要のある種類のものです。
私がそれを自分でやらない理由は、DNSはかなり信頼できると考えられていることです。地理的に分散した独自のサーバーネットワークがない限り、いわばすべての卵を1つのバスケットに入れていることになります。また、そこには専用のDNSサーバーがたくさんあり、新しいDNSサーバーを起動する必要はありません。
私たちは常に自分のDNSをホストします（望ましい逆DNSも）。これにより、第三者に頼ることなく緊急の変更を行うことができます。複数の場所がある場合、DNSサーバーに適切なレベルの冗長性を簡単に設定できます。
複数のサイトがない場合は、変更のためにWebインターフェースを使用してDNSホスティング（ISPではない）を特別に行う誰かを検討します。また、24時間365日のサポートと適切なSLAを探してください。
ドメインの信頼性の高いDNS設定を行うには、...
- ドメインに最低2つの信頼できるDNSサーバー。
- DNSサーバーは、異なる物理ネットワークと電源に接続する必要があります。
- DNSサーバーは、地理的に異なる場所にある必要があります。
上記のネットワークインフラストラクチャにアクセスできる可能性は低いため、上記のネットワークインフラストラクチャを備えた信頼できるDNSホスティングプロバイダー（他の人が推奨している）を選択することをお勧めします。
長年、私はBIND（バージョン8および9）を使用して、大きな手間をかけずに自分のDNSサーバーを実行していました。ゾーンファイルを検証するコミット後のチェックを使用してバージョン管理内に構成を保存し、DNSサーバーにゾーンファイルを定期的にチェックアウトさせました。問題は常に、SOA=シリアル番号が、コミットがプッシュされるたびに更新されるようにすることでした。そうしないと、キャッシュサーバーが更新されませんでした。
そのフォーマットはゾーンを管理するための自動化されたスクリプトを持つのに理想的であり、BINDを使用して対処しなければならなかった同じSOAシリアル番号の問題に悩まされなかったため、数年後、私はdjbdnsを使用しました。特定のリソースレコードセットをフォーマットして受け入れられるようにする必要があることには、独自の問題があります。
トラフィックの多くがDNSであり、DNSのニーズに EasyDNS を使用するように移行したレジストラを満足させるために、プライマリとセカンダリの両方のDNSサーバーを維持する必要があることがわかりました。 Webインターフェイスは管理が簡単で、RRセットを管理するために必要な柔軟性を提供します。また、入力可能なRRセットを制限する 1＆1 のような一部のホスティングプロバイダー、または Network Solutions これは、Windowsを使用してDNSを管理する場合にのみ機能します。
私の個人用ドメイン（および私が手助けするいくつかの友人のドメイン）では、独自のDNSをホストし、レジストラ（Gandi）がセカンダリDNSを提供します。または、別のネットワーク上の友達がセカンダリを提供します。 Gandiはゾーンをすぐには更新しません。約24時間に1回程度確認するようですが、変更は非常にまれです。私たちにとっては十分に機能し、彼らのサーバーはおそらく私たちのものよりはるかに信頼性が高いです。
私の仕事では、独自のDNSを使用し、上流のネットワークプロバイダーがセカンダリDNSを提供しています。ただし、私たちは大学であり、ユーザーの99％がオンサイトにいます。ローカルネットワークがダウンしている場合、DNSがダウンしているかどうかは関係ありません。また、クラスB（/ 16）には約25kのDNSレコード（もちろん、25kの逆DNSレコードも）があり、Webインターフェイスで管理するのは少し面倒です。私たちのローカルDNSサーバーは可用性が高く、高速です。
私は両方をやった。独自にホスティングすることには利点があります。上司がなぜそんなに時間がかかるのかと尋ねてきたら、DNSの仕組みについて多くのことを確実に学びます。また、あなたはゾーンをはるかに制御します。これは、主にDNSの階層的な分散の性質により、本来あるべきほど強力であるとは限りませんが、時々、繰り返し役に立ちます。プロバイダーがあなたにIPブロックの逆引きDNSのためにSOAとして割り当てられるようにさせることができるなら、あなたが持っていると仮定して、二重にそうしてください。
ただし、上記に組み込まれている多くの障害耐性をどのように実際に持つべきかについての上記のすべてのコメントは大いに役立ちます。異なる地理的領域にある異なるデータセンターのサーバーが重要です。 2003年に北東部で大規模な停電を管理したことで、同じ都市、または州や州の2つの異なるデータセンターに1つのボックスを設置するだけでは、必ずしも十分な保護にはならないことがわかりました。バッテリーに気づき、ディーゼル発電機でお尻を救ったときの興奮はすぐにスペアタイヤで運転していることに気づかされた恐怖に取り替えられます。
ただし、LANの内部DNSサーバーは常に実行しています。ネットワークが内部で使用しているDNSを完全に制御することは非常に便利です。オフィスで電源が切れた場合、サーバーラックにあるために内部DNSサーバーはおそらくバッテリーまたはバッテリーとディーゼルにあり、 PCはそうしませんが、サーバーがオフラインになるよりもずっと前にクライアントはオフラインになります。
静的DSL回線からプライマリDNSをホストし、レジストラ（別の大陸にある）にセカンダリDNSを提供することで、これらすべての "要件"に誤って対応できたので、私はこれらのすべてのソリューションを楽しみながら読んでいます。はるかに深刻で信頼できる接続。このようにして、バインドを使用してすべてのレコードを設定する柔軟性をすべて確保しながら、セカンダリがこれらの変更を反映するように更新され、マンホールで火災が発生した場合に利用可能になることを合理的に保証します。
これは効果的に満たされます：
「ドメインに最低2つの信頼できるDNSサーバー。」
「DNSサーバーは、異なる物理ネットワークと電源に接続する必要があります。」
「DNSサーバーは異なる地理的領域にある必要があります。」
Dyn.com を見てください。 DNSホスティング、ダイナミックDNS、MailHopなど、あらゆる種類のDNS関連サービスがあります。信頼できるものであり、おそらく5年間使用しています。
場合によります。
私は80年代後半（BSD 4.3c）以降、さまざまな仕事のために自分のDNSを実行しています。仕事のために、私は常に自分のDNSをホストしてきましたが、私は常に複数のデータセンターの場所を持っているか、パートナーとセカンダリDNSを交換することができました。たとえば、私の最後の仕事で、別の.EDU（それらはMNにあり、私たちはCAにいます）に対してセカンダリDNSを実行しましたが、それらも同じでした。地理的およびネットワークの多様性。
または、現在の仕事では、独自の東西海岸（米国）データセンターを持っています。独自のDNSをホストすることで、GUI DNSサービスの一部でサポートされない可能性のある異常なDNSレコード（SVR、TXTなど）を入れることができます。また、TTLはいつでも変更できます。自分でやることを犠牲にして、私たちはかなり究極の柔軟性を持っています。
家庭用のものについては、私はそれを両方の方法で行いました。通常とは異なる処理を行っている、または柔軟性を必要とする一部のドメインでは、自分の「非表示」マスターDNSサーバーを実行し、同じことをしている他のユーザーとパブリックDNSサービスを交換します。私はRCSを使用して構成管理のためにゾーンファイルのバージョン管理を行っているので、ゾーンの変更履歴全体を最初から確認できます。単一のブログまたは一般的なWebサーバー（1つのAレコードまたは1つのCNAME）を持つドメインのような単純なものの場合、利用可能な場合はドメインレジストラーDNSサービスを使用し、CMを心配する方が簡単です。
それはトレードオフです。究極の制御と柔軟性は、多様性を自分で処理し、複数のサーバーを実行し、ハードウェア/ソフトウェアの障害に対処するなどの犠牲を伴います。柔軟性または完全な制御が必要ない場合は、トップ層のDNSプロバイダーのいずれかがおそらくより低い総コストで問題を解決します。
このスレッドですでに述べたように、DNSにはいくつかの特殊なケースがありますが、最も重要な違いは、信頼できるネームサーバーのデプロイメントとキャッシュネームサーバーのデプロイメントの違いです。
インターネットリソースを解決するためだけにDNSサーバーが必要な場合、無料のキャッシュDNSリゾルバーが賢明な選択です。私は個人的にLinuxでPowerDNSリカーサー（pdns-recursor）を使用しています。
WebサイトやMXなどの外部インフラストラクチャのサービスには、内部NSは使用しません（ここでSOHOについて話している場合）。 DNSmadeasy のような、信頼性の高い優れた防弾サービスを使用してください。私は彼らのビジネスパッケージを使用しています。
独自のネームサーバーをホストする必要がありますか？
はい、およびサードパーティの大手DNSプロバイダーを1つ以上使用する必要もあります。特にSLAまたは顧客への契約上の要件があるビジネスであるビジネスである場合）ハイブリッドソリューションは、おそらく最も安全な長期的なアプローチです。b2bの場合はさらにそうです。
マスターDNSサーバー（非表示またはパブリック）が真実の情報源である場合、ベンダー固有の機能にロックされないように運用上保護します。基本的なDNSを超える優れた機能の使用を開始すると、これらの機能を複製する必要があるため、別のプロバイダーに切り替えたり、独自のDNSをホストしたりすることが問題になる場合があります。例としては、DynとUltraDNSが提供するサイトヘルスチェックとDNSフェイルオーバーがあります。これらの機能は優れていますが、依存関係ではなく、1回限りのものと見なす必要があります。これらの機能は、プロバイダー間でうまく複製されません。
サードパーティベンダーしかない場合は、ターゲットのDDoS攻撃を受けているときに稼働時間が影響を受ける可能性があります。独自のDNSサーバーしかない場合、DDoS攻撃の対象となったときに稼働時間が影響を受ける可能性があります。
1つ以上のDNSプロバイダーと、管理する非表示のマスターDNSサーバーのスレーブとなる独自の分散DNSサーバーがある場合は、特定のベンダーに縛られず、常にゾーンの制御を維持していることを確認します。攻撃は、サーバーと、サーバーのスレーブとなる1つ以上の主要プロバイダーの両方を破壊する必要があります。それ以外のことは、サービスの低下と重大な停止の両方になります。
独自のマスター（理想的には非表示、非公開）サーバーを使用するもう1つの利点は、独自のAPIを構築し、ビジネスニーズに合った方法でそれらを更新できることです。サードパーティのDNSプロバイダーでは、そのAPIに適応する必要があります。各ベンダーには独自のベンダーがあります。または場合によっては、Web UIのみを備えています。
さらに、マスターがあなたの管理下にあり、ベンダーが問題を抱えている場合は、マスターに到達できるスレーブサーバーが更新を取得します。これは、大規模なDDoSインシデントでマスターがサードパーティであることが間違いであり、攻撃を受けていないプロバイダーのサーバーを変更できないことに気付いた後、あなたが望むものです。
法的な観点からは、ベンダーロックインの防止もビジネスにとって重要な場合があります。たとえば、DynはOracleによって購入される可能性があります。これにより、Dynのすべての顧客のDNS統計を収集するためのユニークな立場になります。これには法的リスクをもたらす可能性のある競争面があります。とはいえ、私は弁護士ではないので、法務チームとPRチームに相談してください。
雑草を掘り下げたい場合、このトピックには他にも多くの側面があります。
[編集]これが小規模な個人/趣味のドメインのみの場合、互いに同じデータセンターにない2つのVMで、小さなDNSデーモンを実行するだけで十分です。私は自分の個人的なドメインのためにそれをしています。ドメインがビジネスを意味するのか、趣味だけを意味するのかは明確ではありませんでした。取得できる最小のVMが何であれ、十分以上です。ドメインにはrbldnsdを使用しています。非常に高いTTLを私のレコードに使用します。これは、900 KBのRAMを消費し、人々がそれに投げかけるあらゆる虐待を処理できるためです。
最近、すべてのサービスを社内に導入したときに、パブリックDNSを社内に導入しました。これにより、必要なだけ迅速にすべてを更新できます。 Webサーバーはすべて同じサイトにあるため、地理的に分散したDNSを持っていることは、現時点では私たちの要件ではありません。
私は両方の長所を持っています。
私は自分のウェブサイトとMXレコードの「別の場所」にパブリックDNSをホストしています。信頼性が高く、安全で、機能し、自由に変更できます。サービスの料金を支払い、その価値に満足しています。
しかし、自宅では、ISPに依存するのではなく、独自のキャッシュDNSサーバーを実行しています。私のISPはDNSを失い、遅いDNS、無効なDNSを持っている癖があり、時々彼らは私が興味があるかもしれないと思う場所に失敗するようにDNSをひっくり返したいと思っています。自分のISPのDNSの使用には興味がありません。だから私は自分のDNSサーバーをキャッシュしていて、自分でやっています。最初（おそらく2時間）に設定するのは少し手間がかかりましたが、クリーンで信頼できるDNSを持っています。月に1回、cronジョブがルートサーバーに問い合わせて、ヒントテーブルを更新します。多分年に一度、doubleclick.comを127.0.0.1などに送信するなど、私はそれをいじる必要があります。それ以外は、介入を必要とせず、うまく機能します。
神の愛のために独自のDNSをホストすることにした場合、サイトごとに2つのDNSサーバーを用意します。 1つは外部DNS用で、ファイアウォールに直接接続されており、世界中であなたを見つけることができます。そして、社内DNSのためにネットワーク内で別個のものを使用します。
LinuxサーバーでBINDを使用して自分のDNSを実行しています。私は現在、ロンドン、マイアミフロリダ、サンノゼカリフォルニア、シンガポールに4つあります。うまく動作し、私は完全に制御できます。データセンターの安定性は非常に重要であるため、サーバーを実行するために適切なDCを選択しました（ISPまたは他の「不明な」インフラストラクチャに依存していません）。厳格な基準に基づいて選択したワールドクラスのDCを使用して、DNSサーバーやその他のサービスを世界中のどこにでもセットアップできます。確実なDNSは、私が実行する電子メールおよびWebサービスに不可欠です。
まだコメントはできませんが、フライハイトと同じです。ここではDMZでプライマリDNSを実行しており、ISPには、プライマリDNSに変更を加えた直後に更新される全国のいくつかのスレーブDNSサーバーがあります。
それは両方の世界の最高のものを与えます。即時制御と冗長性。
それぞれのアプローチには長所と短所がありますが、内部DNSを内部でホストすることをお勧めします。外部でホストする場合、基本的なネットワークサービスに依存しているもののリストは、非常に困惑しています。 CEOは、外部でホストすることでDNSサーバーの費用を節約することは賢明だと思うかもしれませんが、インターネットリンクがダウンした場合にメールを受信できない場合はどうなるでしょうか。
経験上、サービス拒否攻撃を引き付けたい場合は、独自のDNSをホストします。そしてあなた自身のウェブサイト。
私はあなたが自分でしてはいけないことがいくつかあると信じています。 DNSホスティングはその1つです。多くの人が言ったように、冗長なサーバー、接続、および物理的な場所が必要であり、さらに小規模なホスティング会社の回復力にさえアプローチしません。
独自のDNSをホストする最大の利点は、変更をすぐに行うことができることです。次の移行のためにTTLを短くする必要がありますか？おそらく、自分のサーバーでそれを行うスクリプトを書くことができます。ホストされたDNSの場合は、ログインしてレコードを手動で変更する必要がある場合があります。さらに悪いことに、プロバイダーに電話し、3つのレベルのサポートを経て、最終的にDNSのスペルを示すものに到達します。 2〜3日で変化します。
Zoneditまたは年を使用しました。その安く（または無料で）たくさんのCNAME、A、MX、TXT、SRV、その他のレコードを追加しました。
DNSホスティングは、公共サービスの基盤と考えてください。私の場合、メールは私たちのビジネスにとって重要です。 DNSを内部でホストし、インターネット接続が不安定になると、DNSレコードが古くなり、ドメインが使用できなくなる場合があります。
したがって、私の場合、ドメインのMXレコードが見つからない場合、メールはすぐに拒否されます。
したがって、私はDNSを外部でホストしています。
MXレコードは使用可能であるがインターネット接続がダウンしている場合、メールはドメインにメールを送信しようとするサーバーのキューに残ります。
それは依存します。™
2002年以降、自分のサーバーを実行し、ドメインを管理しています。
プロバイダのDNSサーバーをよく使用しました。
私のIPにあるサーバーが利用できたが、DNSが利用できなかった回数は、数が多すぎました。
ここに私の戦争の話があります：
モスクワにある1つの弓削プロバイダー（最初のVZベースのプロバイダー）では、VPSが安価な「価値のある」DCにありましたが、そのDNSは最先端のプレミアムDCでした2つの異なる/ 24サブネットで高額なトラフィックが発生する場合 当時の一部のTLDで必要であった 。ある時点で、災害が発生し（おそらく 2005年の停電？ ）、その高価なDCがオフラインになり、私のサイト（まだモスクワにありますが、 "DC）は、そのIPアドレスによってのみアクセスできます。
興味深いことに、インシデントが発生する前であっても、
tracerouteを実行したことをはっきりと覚えています。また、ISPのns1とns2の両方に同じDCがあることに気づき、移動するように依頼しました地理的冗長性のために、「私の」DCにも1つ。サーバーはすでに可能な限り最高のDCに達していたため、地理的冗長性の考えを却下しました。私は別のプロバイダー（最初のISPシステムベースのプロバイダー）を使用しており、1つのnsがオンサイトにあり、別のプロバイダーが海外にあります。簡単に言えば、セットアップ全体が途方もなくバグが多く、「海外」サーバーがゾーンの維持に失敗することが多かったため、ドメイン全体に実質的な障害点があり、サーバー全体がスムーズに稼働していてもアクセスできませんでした。
独自のネットワークを運営するレジストラがいる。オフサイトのサーバーが稼働していたにもかかわらず、時々ダウンしました。 DNSがダウンしました。
私は最近、セカンダリに複数の大きなクラウドプロバイダーを使用しました。自分で非表示のマスターを実行していました。どちらのプロバイダーも、少なくとも一度は設定を変更しました。いかなる公示もありません。ドメインの一部が解決しなくなりました。同じプロバイダーの1つで、私の友人にも起こりました。 これは、サードパーティのサービスでは、人々が公に認めようとするよりも頻繁に発生します。
要するに、 http://cr.yp.to/djbdns/third-party.html は、このトピックに関しては完全に正しいです。
サードパーティのDNSをわざわざわざわざわざわざわざわざ生み出すコストは、多くの場合、メリットに見合う価値がありません。
サードパーティのDNSを使用することの欠点は、見過ごされがちです。
ドメインで既にサードパーティのサービス（Web、メール、音声、テキストなど）を使用している場合を除いて、サードパーティのDNSを追加することはほとんどの場合逆効果であり、あらゆる状況でのベストプラクティスとは決して言えません。 。