パブリッククラウドのDNSだけでは 、 オンプレミス、クラウド、 エッジを 網羅することはできません 。また、環境が 拡大する につれて 、フォワーダーの乱立、 IPアドレスの 重複 、プロバイダーの「 ウォールドガーデン」が可視性を損ない、 サービス停止を 招く恐れがあります 。 このピラーでは 、 クラウド DNS が不十分である 理由 、 AWS、Azure、 GCP 間でネーミングを標準化する方法 、DNS セキュリティ のトレードオフ、および一元化された フォワーディングアプローチに必要な要件について 解説します 。 環境の 配置場所に応じて 、 2 つのアプローチ が選択可能です 。Micetro はオンプレミスの Microsoft DNS をその場で 近代化し 、 Horizon は可観測性を備えたクラウド DDI を実行します 。
パブリッククラウドのDNSサービスは、単一のプロバイダーのテナント内のワークロードに対応するように設計されており、テナント間の ハイブリッド企業が求めるクロスクラウドおよびオンプレミスの接続性において、このギャップが可用性、コンプライアンス、およびセキュリティ上のリスクを生み出しています。
クラウドDNSは、独自の環境内でのコンピューティング向けに最適化されており、その境界を越えたゾーンの委任、再帰、転送に関するメカニズムは限定的であるか、あるいは矛盾している場合があり、クラウド経由で提供されるサービス外でのネームサーバー間の相互運用性はほとんどありません。分析で指摘されているように、「クラウドDNSが、企業が依存する唯一のDNSサービスとなる可能性は低い」のです。
クラウドDNSのみに依存すると、チームはIP割り当てを推測せざるを得なくなり、DDIが個別のサイロに分断され、設定ミスやサービス停止を招く複雑な転送ルールが強制されます。 「企業には、オンプレミスからクラウドに至るまで、異種アーキテクチャ全体に展開・拡張可能な高可用性のネットワークサービスが必要です」。つまり、オンプレミスのDDIをクラウドに拡張する必要があるということです。
Read article
Unsure about cloud DNS services and hybrid-cloud enterprises? Learn more with BlueCat, including why it isn't so simple for managing networks.
クラウド間でDNSの命名規則を標準化するには、DDIチームを早期に巻き込み、アカウントやVPCにまたがる一元化されたDDIプラクティスやサードパーティ製ツールを活用して一貫性を確保する必要があります。 各パブリッククラウドはDNS機能のサポートが異種であり、境界を越えて名前が容易に重複してしまうため、クラウド自体が橋渡ししない境界において、プロトコルサービスとテレメトリはお客様の環境内に留まります。
セルフサービスの導入により「クラウドの孤島」が生まれ、多くのチームがDDIの専門知識を持たずにアカウント、VPC、ゾーン、レコードを立ち上げています。「この分散化により、DNS管理が細分化され、可視性と制御が低下し、異種スタック間の相互運用性の問題が増大します」その結果、境界をまたぐ重複した名前や、その場限りの転送ルールが生じることになります。
また、プロバイダーによって、サポートされるレコードタイプ、DNSSEC（AWSとGCPはサポートしていますが、Azureはサポートしていません）、およびホストゾーンの制限が異なるため、境界をまたぐ解決は依然として不安定なままです。 各クラウドは自社の壁を越えて相互運用しないため、外部から一貫性を強制する必要があります。「組織は、クラウド導入の早い段階で DDI チームを関与させ、サードパーティの検出および管理ツールによってサポートされる、オンプレミスおよび複数のクラウドにまたがる一貫性のあるエンタープライズグレードの DNS を設計すべきです。
AWS、Azure、GCPでは、ホストゾーンの上限がそれぞれ10、250、10,000に設定されています。これは、回避策を余儀なくさせ、マルチクラウド環境全体での命名規則を複雑にする多くの不整合の一つです。
Read article
The public cloud presents major challenges for DNS management. Examine various capabilities and limitations of Azure, AWS, and GCP with BlueCat.
ハイブリッドおよびマルチクラウド・ネットワーキングでは、セグメント化された仮想ネットワーク、重複するIPアドレス空間、断片化されたDNSネームスペースなどが導入され、 また、従来のアドホックなDNSスティッチングを管理不能にし、チームを不安定な条件付きフォワーダーの寄せ集めへと追い込むような、新たなセキュリティ境界も存在します。
クラウドネットワーキングでは、従来のレイヤー2ドメインや明確なパブリック／プライベート境界が、プロバイダーを横断するVPC、ピアリング、ゲートウェイ、プライベートエンドポイントに置き換えられます。マイクロサービスやKubernetesによってDNS名が急増する一方で、マルチクラウド設計は「IP空間の重複やネームスペースの断片化を生み出し、一般的なクラウドチームのスキルでは対応しきれない状況」を引き起こしています。
手動で管理される条件付きフォワーダーやスタブゾーンは、環境の拡大に伴い可視性とセキュリティを損なう「無法地帯」と化してしまいます。DDIチームは、DNS、DHCP、IPAMに関する単一かつ信頼できる「真実の源」を確立することで制御権を取り戻します。なぜなら、「いかなるレベルの自動化も成功させるには、単一の真実の源が不可欠」だからです。
ハイブリッドクラウド環境では、数千もの条件付きDNS転送ルールが日常的に蓄積され、リスクと運用負担が少数のDNS専門家グループに集中しています。
Read article
Hybrid multicloud DNS should centralize DDI, governance, and cloud integration to avoid brittle forwarding and restore visibility.
ハイブリッド環境における効果的なDNSセキュリティには、完全性と可視性の両方が不可欠です。DNSSECは、信頼の連鎖を通じてオリジン認証を提供し、 一方で、平文のDNSクエリに対する企業の可視性を維持することは、脅威の検出に不可欠であり、多くの組織がDNS over HTTPSに対して慎重な姿勢をとっている理由でもあります。
DNSSECとDoHは、それぞれ異なる問題を解決します。DNSSECはDNSデータに署名を行い、リゾルバーが応答が本物であり改ざんされていないことを検証できるようにします。一方、DoHはプライバシー保護のためにDNSの転送を暗号化します。これらは競合するものではなく、互いに補完し合う関係にあります。しかし、「DNSSECは信頼の連鎖を通じて発信元の認証を提供しますが、設定や保守が困難です。」
DoHによるDNSの暗号化は、「平文DNSに依存する従来のエンタープライズ監視を妨げる」ため、セキュリティツールがマルウェアを検知したりトラフィックをルーティングしたりするための可視性が低下し、解決処理が少数のパブリックリゾルバーに集中してしまいます。このトレードオフこそが、ハイブリッドな脅威検知戦略において、クエリレベルの可視性を維持することを優先する理由です。
Read article
We rounded up industry experts to discuss the intersection of networking, cloud, storage, and virtualization. Here is their conversation.
各チームは、各データソースをネームスペースとして扱い、順序付けられ優先順位が付けられた転送を行う一元化されたアプローチを検討すべきです。 オンプレミスおよびあらゆるクラウド環境にわたって単一の信頼できる情報源を維持し、すべての主要プロバイダーに対応し、手動でのコマンドライン操作を必要とせずにDNSSECを自動化します。
「DNSインフラの分散型または並列管理では、自動化の達成が困難になる状況が生じかねません。」したがって、最初の基準は、一元化されたインテリジェントな解決です。リゾルバーが最初のホップである場合、管理者が指定した優先順位に従って各ネームスペースを順に確認し、前のソースから応答が得られなかった場合にのみ転送を行います。
2つ目は、クラウド中立性と低負荷のセキュリティです。AWS、Azure、Google Cloud、プライベートクラウドで解決策の認証を受けており、資産がどこにあってもDNSを一貫して管理できます。さらに、手動での鍵生成や信頼アンカーの再配布を必要とせず、親ゾーンと子ゾーン全体に自動的に伝播するDNSSECも備えています。
Read article
DNS can be a major headache in the cloud, but it doesn't have to be. When centrally managed with tools for intelligent routing, DNS can be an asset.
スリムなチームは、BlueCat Micetro を使用してオンプレミスの DNS および DHCP の移行をその場でオーケストレーションすることで、オンプレミス環境を最新化します。これにより、手動でのエクスポートや深夜の切り替え作業が、ウィザード駆動型の、 Microsoft、BIND、Kea、Cisco IOSにわたるトランザクションワークフローを実現し、ワンクリックでのロールバックパスを維持しつつ、作業負荷を軽減します。
Micetroは、REST APIと同じオブジェクトモデルを使用して、すべての移行を安全なトランザクションとして扱うため、データの一貫性が保たれます。また、プレフライト検証により、変更が適用される前に設定の競合や依存関係の欠落を検出します。「プレフライト検証により変更に伴うリスクを排除」し、エラー発生時の自動停止と即時ロールバック機能により、切り替え時の不安を解消します。
さらに、キャッシュされたメタデータやバックアップを活用して、オフラインまたは廃止されたハードウェアからDNSゾーンやDHCPスコープを復元することも可能です。これにより、レガシーのMicrosoftサーバーをオンラインに戻すことなく廃止できます。すべての機能がREST API経由で公開されているため、一括移行をAnsibleやTerraformと連携させ、オンプレミスの段階的な近代化を実現できます。
組み込みの検証機能を備えたウィザードベースの移行により、手動でのエクスポートやスクリプト作成によるプロセスと比較して、移行の労力を推定60～80％削減でき、移行後のインシデントも減少します。
Read article
Automate cross-platform DNS and DHCP migration with Micetro to reduce risk, eliminate manual effort, and modernize infrastructure faster.
クラウドファーストおよびマルチクラウドを中核とするチームは、BlueCat Horizonを通じてDDIと可観測性を統合しています。BlueCat Horizonは、DNS、DHCP、IPAMをネットワーク可観測性と統合するSaaSプラットフォームであり、アドレスおよび解決データをリアルタイムのテレメトリと関連付けることで、インシデント対応を迅速化します。 これは、組織が選択するクラウドドメインの選択肢であり、オンプレミスの近代化パスとは区別されるもので、それに重ねて実装されるものではありません。
Horizonは、SaaSベースの各種サービスにまたがる共通の制御および統合レイヤーとして機能し、共有APIゲートウェイ、認証、一元化されたAI分析を提供します。EMAは、DDIと可観測性の統合を戦略的な転換と位置付けています。これは、これまでサイロ化されていた製品横断的なワークフロー、コンテキスト主導の運用、インテリジェントなトラフィックステアリング、および閉ループ型のセキュリティ対応を可能にするためです。
このアーキテクチャでは、クラウドベースの制御とローカルデータおよびサービスの配置を分離しています。つまり、制御プレーン、AI、オーケストレーションはクラウド上で実行される一方、プロトコルサービスや大容量のテレメトリデータは、お客様が選択したクラウド環境に留めることができます。プラットフォーム内に統合機能やデータフローがすでに整備されているため、新しいサービスを追加する際の業務への影響を最小限に抑えることができます。
Read article
EMA evaluates BlueCat Horizon, highlighting unified DDI and observability, SaaS control architecture, and AI-driven integration benefits.
最適な道筋は、お客様の環境の重心はどこにあるか、そして当面の優先事項が何であるかによって異なります。可視性の確保、業務を中断することなくオンプレミスを近代化すること、あるいは可観測性を備えたクラウドファーストのDDIを実行することなどです。多くの組織は段階的に進めていきますが、製品はドメインごとに明確に分類されています。お客様のワークロードやリスクが実際に存在する場所に合った製品をお選びください。
ハイブリッドおよびマルチクラウドのDNS転送を設計するチームから寄せられるよくある質問。
まだご質問がありますか？
BlueCatの担当者から具体的な回答を得ましょう。
