で 最近の投稿では、自己ホスト型の権威ドメイン ネーム システム (DNS) の落とし穴について、新興企業や中堅企業が DIY システムを組み立てる観点から概説しました。 バインドDNS または他のオープンソース ツール。主なアイデアは、すべての企業が自己ホスト型の自社製の権威 DNS システムを超えて成長する段階に達するということでした。機能、コスト、信頼性、リソースなど、理由が何であれ、ほとんどの企業は自然に マネージドDNSの必要性 サードパーティによって提供されるサービス。

それにもかかわらず、自己ホスト型の権威 DNS が異なる種類のロジックで動作する特定のクラスの大企業が存在します。世界的な拠点を持ち、複雑な技術プロジェクトでも社内で解決できる十分な規模を備えているこの種の企業は、多くの場合、他社の製品を購入するのではなく、解決策を構築することをデフォルトとしています。

大企業にとってのセルフホスティングの利点

大企業が独自に権威 DNS サービスを構築してホストしたい理由はいくつかあります。

特定の機能要件: 大企業は多くの場合、アプリケーション、サービス、コンテンツをカスタマイズされた方法で配信したいと考えています。これには、DNS クエリの超特殊なルーティングから、コンプライアンス要件に対する特有のアプリケーション アーキテクチャのシステム レベルのサポートまで、あらゆるものが含まれます。

既存のリソースの使用: 企業がすでにサーバーと技術リソースを世界中に大規模に展開している場合、そのフットプリントを使用して権威 DNS を提供することが、論理的な次のステップのように思えることがよくあります。

管理: 一部の企業は、特に権威 DNS のようなビジネスクリティカルなものについては、ベンダーに依存したくない場合があります。他の企業には、技術スキルを育成する社内アプローチを開発することに価値を見出す「構築する」文化があります。

理論と現実

これらはすべて、少なくとも理論的には、DNS を大規模に自己ホストする正当な理由です。さまざまな業界の大企業と話をしてわかったことは、自己ホスト型の権威 DNS の利点が認識されていないことが多いということです。セルフホスティングの背後にあるロジックは PowerPoint では適切に見えますが、実際のビジネス価値は得られません。

自己ホスト型の権威 DNS の現実が理論と一致しない領域をいくつか示します。

回復力: 大規模なビジネスはおそらく、ダウンタイムが発生すると収益に壊滅的な影響を与えるほど重要です。そのため、ほとんどの権威ある DNS 管理者は、災害が発生した場合に備えてセカンダリ オプションまたはフェイルオーバー オプションを主張します。自己ホスト型の権威 DNS にはこれが含まれることはほとんどありません。保険としてセカンダリ システムを構築して維持するにはリソースを大量に消費します。

脆いアーキテクチャ: ほとんどの権威 DNS インフラストラクチャは BIND 上に構築されており、通常、スクリプトを実行するには Rube Goldberg マシンが必要です。新しい機能や動作要件を考慮すると、時間の経過とともに、これらのスクリプトの複雑さを維持することが困難になる可能性があります。単一のコーディング エラーなど、1 つの誤った操作により、権威 DNS インフラストラクチャ全体が簡単にダウンし、顧客向けサイトがオフラインになる可能性があります。大規模で複雑な企業の場合、脆弱な BIND アーキテクチャとスクリプトは特に危険です。

技術的負債: 独自の権威 DNS を実行すると、大量の機能リクエストのバックログがたまりやすくなります。これは、DevOps、NetOps、または CloudOps チームが期限に向かって取り組んでいる場合に特に当てはまります。正直に言って、これらの DNS 機能のほとんどは、アプリケーション開発チームが要求するよりもはるかに長いスケジュールで提供されることになります。

費用: セルフホスト型の大企業は、計算を行って、権威 DNS システムの構築、展開、保守には投資する価値があると結論付けているかもしれません。しかし、実際には、こうした決定は通常、意図的な費用対効果の分析なしに行われます。長期的には支出コストは および 自己ホスト型の権威 DNS の隠れた機会コストは、認識されている経済的メリットを上回る傾向があります。

離職: DIY アーキテクチャは、それを構築した人 (またはチーム) が会社に在籍している限り機能します。その人が何らかの理由で会社を辞めると、DIY 建築がどのように建てられたかについての組織的な知識はその人のもとから去っていきます。一部の企業は、回復が困難なダウンタイム インシデントが簡単に発生する可能性があるため、何かを変更することを恐れる状況に陥っています。

オートメーション: BIND にはアプリケーション プログラミング インターフェイス (API) がなく、あらゆる形式の自動化をサポートするように構築されていません。 DIY アーキテクチャは通常、Ansible や Terraform などの標準の自動化プラットフォームをサポートするように構築されていません。サードパーティのツールを使用して DIY アーキテクチャを調整することはほぼ不可能です。 DIY の権威 DNS を持っている場合は、おそらく手動による変更に悩まされ、アプリケーション開発の作業が大幅に遅くなっている可能性があります。

マネージド DNS は理にかなっています

のプロバイダーとして マネージド DNS ソリューション、確かに私たちは偏見を持っています。ただし、私たちの観点からすると、通常は独自のシステムを構築することがデフォルトである大企業にとっても (特に)、自己ホスト型の権威 DNS の短所が利点を明らかに上回ります。権威 DNS システムを維持するための長期的なコスト (CapEx ハードウェアと OpEx 要員の両方) を考慮すると、マネージド DNS ソリューションは経済的に合理的です。

マネージド DNS ソリューション また、IT チームがより少ないリソースでより多くの成果を達成できるように支援します。権威 DNS ネットワークを大規模に運用するために必要な管理時間を考慮すると、それらのリソースを他の戦略的優先事項に振り向ける方がはるかに価値があります。私たち自身、インターネットの大部分を代表して権威 DNS を 10 年間運用してきたので、それがいかにコストがかかり、困難な作業であるかを知っています。

DNS移行リスクへの対処

分かりました。変えるのは難しい。大企業は、セルフホスト型の権威 DNS アーキテクチャから移行する準備ができている場合でも、マネージド DNS サービスへの移行に伴う重大なリスクを考慮して躊躇することがよくあります。既存の DNS ツールが企業の技術 DNA に組み込まれると、変更する必要がある複雑な依存関係について考えることさえ困難になることがあります。

ここでセカンダリ DNS がライフラインを提供します。マネージド DNS サービス (NS1 など) は、独立したプラットフォームまたはフェイルオーバー オプションとして、セルフホスト型の権威 DNS システムと並行して動作できます。セカンダリ DNS レイヤーを配置すると、管理者はアプリケーションのワークロードを時間をかけて移行し、管理対象システムの機能をテストし、内部システムへの複雑な接続を徐々に解くことができます。

セカンダリ DNS をテスト環境として運用すると、マネージド DNS サービスが提供する高度な機能に対する信頼も高まります。 交通誘導, API、DNS データ分析や、明確な価値を提供するその他の要素ですが、ほとんどの自己ホスト型サービスでは利用できません。

自己ホスト型の権威 DNS から移行する準備はできていますか?

より多くの機能を備えた DNS を入手: IBM NS1 Connect