これは、独自のドメインのDNS解決を外部委託するかどうかに関する正規の質問です

現在、ドメインにDNSを提供しているISPがありますが、レコードの追加には制限があります。したがって、私は自分のDNSを実行することを考えています。

独自のDNSをホストすることを好むのですか、それともISPにこれをさせる方がよいのですか？

検討できる選択肢はありますか？

私は自分のDNSサーバーを実行しません。私の場合、私のWebサイトをホストするホスティング会社が無料のDNSサービスを提供しています。DNSホスティング（DNS Made Easyが思い浮かびますが、他にもたくさんあります）以外は何もしない会社は、おそらく検討すべき種類のものです。

私が自分でやらない理由は、DNSがかなり信頼できるはずであり、地理的に分散した独自のサーバーのネットワークがない限り、すべての卵を1つのバスケットに入れることです。また、専用のDNSサーバーがたくさんあり、新しいサーバーを起動する必要はありません。

私たちは常に自分のDNSをホストしています（好ましい逆引きDNSも）。これにより、サードパーティに依存せずに緊急変更を行うことができます。複数の場所がある場合、DNSサーバーの許容レベルの冗長性を簡単に設定できます。

複数のサイトがない場合は、変更用のWebインターフェイスでDNSホスティング（ISPではない）を具体的に行う人を検討します。また、24時間365日のサポートとまともなSLAを探してください。

ドメインに適切で信頼性の高いDNSセットアップを行うには、次のものが必要です

• ドメイン用の最低2つの信頼できるDNSサーバー。
• DNSサーバーは、異なる物理ネットワークと電源に接続する必要があります。
• DNSサーバーは地理的に異なる場所に配置する必要があります。

上記のネットワークインフラストラクチャにアクセスする可能性は低いため、上記のネットワークインフラストラクチャを持つ信頼できるDNSホスティングプロバイダー（他の人が推奨している）を選択することをお勧めします。

長年、私はBIND（バージョン8および9）を使用して、大きな手間をかけずに独自のDNSサーバーを実行していました。ゾーンファイルを検証するコミット後チェックを使用してバージョン管理内に構成を保存し、DNSサーバーに定期的にゾーンファイルをチェックアウトさせました。問題は、コミットがプッシュされるたびにSOAシリアル番号が更新されることを常に保証することでした。そうしないと、キャッシュサーバーは更新されません。

数年後、私はdjbdnsを使って作業しました。このフォーマットは、ゾーンを管理する自動スクリプトを持つのに理想的であり、BINDを使用して対処しなければならなかった同じSOAシリアル番号の問題に悩まされなかったからです ただし、特定のリソースレコードセットをフォーマットして受け入れられるようにする必要があるという独自の問題がありました。

トラフィックの多くはDNSであり、DNSニーズにEasyDNSを使用するようになったレジストラを満足させるために、プライマリとセカンダリの両方のDNSサーバーを維持する必要がありました。Webインターフェイスは管理が簡単で、RRセットを管理するために必要な柔軟性を提供します。また、入力可能なRRセットを制限する1＆1などの一部のホスティングプロバイダーや、Windowsを使用してDNSを管理する場合にのみ機能するNetwork Solutionsなどのドメインレジストラーで提供されるものよりも簡単に操作できることがわかりました。

私の個人ドメイン（および私が手伝ってくれる友人のドメイン）には、独自のDNSをホストし、私のレジストラ（Gandi）はセカンダリDNSを提供します。または、別のネットワーク上の友人がセカンダリを提供します。Gandiはゾーンをすぐには更新せず、24時間ごとに1回程度チェックするようですが、変更は非常にまれです。私たちにとって十分に機能し、彼らのサーバーはおそらく私たちのものよりもはるかに信頼性があります。

私の仕事では、独自のDNSを使用し、アップストリームネットワークプロバイダーがセカンダリDNSを提供しています。ただし、私たちは大学であり、ユーザーの99％がオンサイトです。ローカルネットワークがダウンしている場合、DNSがダウンしているかどうかは関係ありません。また、クラスB（/ 16）に約2万5,000個のDNSレコード（もちろん、2万5,000個の逆DNSレコード）があります。これは、Webインターフェースで管理するのが少し面倒です。ローカルDNSサーバーは可用性が高く、高速です。

私は両方をしました。独自のホスティングには利点があります。上司がDNSの処理に時間がかかる理由を尋ねるとき、DNSがどのように機能するかを確実に学ぶことができます。また、あなたはあなたのゾーンをもっとコントロールできるようになります。これは、DNSの階層的な分散の性質のために、主にDNSの性質上、必ずしも本来あるべきほど強力ではありませんが、ときどき便利になります。二重に、プロバイダーにIPブロックのリバースDNSのSOAとして割り当ててもらうことができれば、それがあると仮定します。

ただし、上記に組み込まれている多くの耐障害性を実際にどのように構築するべきかについての上記のコメントはすべて受け入れられています。地理的に異なる地域の異なるデータセンターにあるサーバーは重要です。2003年に北東部で大規模な停電が発生したため、同じ都市、州、州の2つの異なるデータセンターにボックスを設置するだけでは必ずしも十分な保護ではないことがわかりました。バッテリーを認識し、ディーゼル発電機があなたの尻を救ったときに興奮する興奮は、スペアタイヤで運転しているという認識に起因する恐怖にすぐに置き換えられます。

ただし、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にはいくつかの特殊なケースがありますが、最も重要な違いは、権限サーバーとキャッシュネームサーバーの展開の違いです。

1. インターネットリソースを解決するためだけにDNSサーバーが必要な場合は、一部の無料のDNSキャッシュリゾルバーが賢明な選択です。私は個人的にLinuxでPowerDNS再帰（pdns-recursor）を使用しています。

2. WebサイトやMXなどの外部インフラストラクチャのサービスには、内部NSを使用しません（ここでSOHOについて話している場合）。DNSmadeasyのような優れた信頼性の高い防弾サービスを使用してください。私は彼らのビジネスパッケージを使用していますが、非常に手頃な価格でありながら、それは揺れ動きます。

Zoneditまたは何年も使用しました。その安い（または無料）と私は多くのCNAME、A、MX、TXT、SRV、およびその他のレコードを追加しました。

最近、すべてのサービスを社内に持ち込んだときに、パブリックDNSを社内に持ち込みました。これにより、必要に応じて迅速にすべてを更新できます。Webサーバーはすべて同じサイトにあるため、現在のところ、地理的に分散したDNSを持つことは要件ではありません。

私は両方の長所を持っています。

私は自分のWebサイトとMXレコードのパブリックDNSを「どこか別の場所」でホストしています。信頼性が高く、安全で、機能します。自由に変更できます。私はサービスの代金を支払い、その価値に満足しています。

しかし、自宅では、ISPに依存するのではなく、独自のキャッシュDNSサーバーを実行しています。私のISPはDNSを失い、遅いDNS、無効なDNSを持っている傾向があり、時々、DNSを変質させて、私が興味があると思われる場所に障害が発生するようにします。だから、私は自分のキャッシングDNSサーバーを持っており、それを自分でやります。最初（2時間程度）に設定するのは少し手間がかかりましたが、クリーンで信頼できるDNSがあります。月に一度、cronジョブはルートサーバーに問い合わせを行い、ヒントテーブルを更新します。doubleclick.comを127.0.0.1などに送信するなど、1年に1度はいじる必要があります。それ以外は、介入を必要とせず、うまく機能します。

神の愛のために独自のDNSをホストすることにした場合、サイトごとに2つのDNSサーバーがあります。外部DNS用に1つ、ファイアウォールに直接接続して、世界中の人が見つけられるようにします。また、社内DNSの場合は、ネットワーク内に別のものがあります。

まだコメントできませんが、freiheitと同じことをしています。ここでプライマリDNSをDMZで実行し、ISPには、プライマリDNSで変更を行った直後に更新が行われる全国に複数のスレーブDNSサーバーがあります。

両方の長所を提供します。即時制御と冗長性。

それぞれのアプローチには長所と短所がありますが、内部DNSを内部でホストすることは間違いありません。外部でホストする場合、基本的なネットワークサービスに依存しているもののリストは気が遠くなるでしょう。CEOは、外部でホストすることでDNSサーバーの費用を節約するのが賢明だと思うかもしれませんが、インターネットリンクがダウンした場合にメールを受け取れない場合はどうなるでしょうか？

経験から、サービス拒否攻撃を引き付けたい場合は、独自のDNSをホストしてください。そしてあなた自身のウェブサイト。

私はあなたがあなた自身をしてはいけないいくつかの事があると信じています。DNSホスティングはその1つです。多くの人が言っているように、冗長なサーバー、接続、物理的な場所が必要になりますが、それでも小規模なホスティング会社の回復力に近づくことはありません。

独自のDNSをホストする最大の利点は、すぐに変更を加えることができることです。今後の移行のためにTTLを短縮する必要がありますか？おそらく、自分のサーバーでそれを行うスクリプトを作成できます。ホスト型DNSの場合は、ログインして手動でレコードを変更するか、さらに悪いことにプロバイダーに電話して、最終的にDNSのスペルが可能なものに到達するまで3レベルのサポートを行う必要があります。 2-3日で変化します。

LinuxサーバーでBINDを使用して独自のDNSを実行しています。私は現在、イギリスのロンドン、フロリダ州マイアミ、カリフォルニア州サンノゼ、シンガポールに4つあります。うまく機能し、完全に制御できます。データセンターの安定性は非常に重要であるため、サーバーを実行するために適切なDCを選択しました（ISPまたはその他の「不明な」インフラストラクチャに依存しません）。厳格な基準に基づいて選択した世界クラスのDCを使用して、世界中のどこにでもDNSサーバーやその他のサービスをセットアップできます。堅実なDNSは、私が実行する電子メールとWebサービスに不可欠です。

独自のネームサーバーをホストする必要がありますか？

はい、そしてあなたも、大きなサードパーティのDNSプロバイダーの1つ以上を使用する必要があります。ハイブリッドソリューションは、特にSLAのマナーや顧客に対する契約上の要件を抱えている企業の場合、複数の理由から最も安全な長期アプローチです。あなたがb2bであるならば、さらにそうです。

マスターDNSサーバー（非表示またはパブリック）が真実のソースである場合、ベンダー固有の機能にロックされないように運用上自分自身を保護します。基本的なDNSを超える優れた機能の使用を開始すると、これらの機能を複製する必要があるため、別のプロバイダーへの切り替えや独自のDNSのホストが問題になる場合があります。例としては、DynおよびUltraDNSが提供するサイトヘルスチェックとDNSフェールオーバーがあります。これらの機能は優れていますが、1回限りの機能であり、依存関係ではありません。また、これらの機能はプロバイダー間でうまく複製されません。

サードパーティベンダーしかない場合、ターゲットを絞ったDDoS攻撃を受けているときに稼働時間が影響を受ける可能性があります。独自のDNSサーバーしかない場合、DDoS攻撃の標的になったときに稼働時間が影響を受ける可能性があります。

1つ以上のDNSプロバイダーと、制御する非表示のマスターDNSサーバーのスレーブとなる独自の分散DNSサーバーがある場合、特定のベンダーにロックされておらず、常にゾーンの制御を維持していることを確認します。攻撃は、サーバーと、サーバーに従属する1つ以上の主要プロバイダーの両方を停止する必要があります。それに満たないものはすべて、サービスの低下対重大な停止になります。

独自のマスター（理想的には非公開、非公開）サーバーを持つことのもう1つの利点は、独自のAPIを構築し、ビジネスニーズに合った方法でAPIを更新できることです。サードパーティのDNSプロバイダーでは、そのAPIに適応する必要があります。各ベンダーには独自のものがあります。または、場合によっては、Web UIのみがあります。

さらに、マスターが管理下にあり、ベンダーに問題がある場合は、マスターに到達できるスレーブサーバーが更新を取得します。これは、大規模なDDoSインシデントの際にマスターとしてサードパーティを持つことが間違いであり、攻撃を受けていないプロバイダーのサーバーを変更できないことに気付いた後に望むことです。

法的観点からは、ベンダーのロックインを防ぐこともビジネスにとって重要です。たとえば、DynはOracleによって購入される可能性があります。これにより、Dynのすべての顧客に関するDNS統計を収集するユニークな立場になります。これには、法的リスクをもたらす可能性のある競争的な側面があります。とはいえ、私は弁護士ではないので、その点については法務および広報チームに相談してください。

雑草を掘り下げたい場合、このトピックには他の多くの側面があります。

[編集] これが小さな個人/趣味のドメインだけの場合、2つのVMが互いに同じデータセンターになく、小さなDNSデーモンを実行するだけで十分です。私は自分の個人的なドメインのためにそれをします。あなたのドメインがビジネスを意味するのか、それとも趣味を意味するのかは明確ではありませんでした。取得できる最小のVMが何であれ、それで十分です。ドメインにはrbldnsdを使用しています。レコードに非常に高いTTLを使用しています。900KBのRAMを占有し、人々が投げつけたあらゆる虐待を処理できるからです。

DNSホスティングを公共サービスの基盤と考えてください。私の場合、メールは私たちのビジネスにとって重要です。DNSを内部でホストし、インターネット接続が不安定になると、DNSレコードが古くなり、ドメインが使用できなくなることがあります。

したがって、私の場合、ドメインのMXレコードが見つからない場合、メールはすぐに拒否されます。

したがって、私はDNSを外部でホストしています。

MXレコードは利用できるが、インターネット接続がダウンしている場合、メールはドメインにメールを送信しようとするサーバーのキューに残ります。

依存します。™

少なくとも2002年以来、自分のサーバーを実行し、ドメインを管理しています。

プロバイダーのDNSサーバーをよく使用します。

私のIPで私のサーバーが利用可能であったが、私のDNSは利用できなかった回数は、少なすぎました。

ここに私の戦争の物語があります：

• モスクワのあるyugeプロバイダー（最初のVZベースのプロバイダー）は、私のVPSを安価な「バリュー」DCに搭載していましたが、DNSは、当時の一部のTLDで要求されていた異なる/ 24サブネット。ある時点で、災害（おそらく2005年の停電？）が発生し、それらの高価なDCがオフラインになり、私のサイト（まだモスクワにあるが「価値」DCにある）はそのIPアドレスによってのみアクセスできました。

  興味深いことに、事故が発生する前であっても、ISPのtraceroute両方ns1と同じDCに気づき、ns2地理的冗長性のために1つを「私の」DCに移動するように依頼したことをはっきりと覚えています。サーバーは可能な限り最も高品質のDCに既に存在していたため、地理的冗長性の概念を却下しました。

• 別のプロバイダー（最初のISPsystemベースのプロバイダー）があり、そこでは1 nsがオンサイトにあり、もう1つは海外にありました。要するに、セットアップ全体が途方もなくバグが多く、「海外の」サーバーはゾーンの維持に失敗することが多かったので、私のドメインには事実上余分な障害点があり、サーバー全体がスムーズに実行されてもアクセスできません。

• 独自のネットワークを実行するレジストラがありました。オフサイトサーバーが稼働していても、時々ダウンしました。DNSがダウンしました。

• 私は最近、セカンダリ用に複数のビッグクラウドプロバイダーを使用しました。両方のプロバイダーが少なくとも1回セットアップを変更しました。公的な発表は一切ありません。一部のドメインの解決が停止しました。同じプロバイダーのいずれかで、私の友人にも起こりました。 これは、人々が公の場で認めようとするよりも、サードパーティのサービスで頻繁に起こります。

要するに、http：//cr.yp.to/djbdns/third-party.htmlはこのトピックに関しては絶対に正しいです。

多くの場合、サードパーティのDNSに煩わされるコストは、メリットに値しません。

サードパーティのDNSを使用することのマイナス面は、しばしば不当に見落とされます。

ドメインでサードパーティのサービス（Web、メール、音声、テキストなど）を既に使用している場合を除き、サードパーティのDNSの追加はほとんど常に非生産的であり、あらゆる状況でのベストプラクティスではありません。