自動化されたDNSフェイルオーバーには、3つの構成要素があります。基盤となる重複した可用性手法、ドメインに応答するすべてのプロバイダー間でレプリケートされたゾーンコンテンツ、そして障害の検出から応答の変更までのギャップを埋める自動化です。 これらを結びつけるのは、何がどこに存在すべきかという記録を保持するコントロールプレーンです。BlueCat はこの実現に向けて 2 つのアプローチを提供しています。Micetro は、すでに稼働している Microsoft DNS、BIND、および DHCP サービスをオーケストレーションし、Integrity はDNS、DHCP、および IPAM を単一のプラットフォームに統合します。
DNSサーバーが1台しかない場合は、単一障害点となります。 応答が停止すると、名前解決も停止し、基盤となるサーバーの状態がどれほど良好であっても、ネットワークや対外向けサイトにはアクセスできなくなります。
高可用性とは、一定の運用パフォーマンスや稼働時間を保証することを目的としており、多くの場合、サービスレベル契約（SLA）によって特定の割合が義務付けられています。これを実現する構成は、冗長性と回復力を兼ね備えており、障害発生時にその場しのぎで構築するのではなく、障害が発生する前にフェイルオーバーの準備が整っている必要があります。
DNSサービスの高可用性を実現するには、ハードウェアフェイルオーバー、DNSプロトコルの冗長性、分散アーキテクチャ、ロードバランサーのヘルスチェックという4つの方法があります。冗長化されたハードウェアは、同じロケーション内で自動的に引き継ぎを行います。 DNSプロトコルの冗長性により、クライアントは別のサーバーに接続を試みることができます。分散アーキテクチャとは、単一のサーバーがダウンしてもサービスに影響が及ばないことを意味します。ロードバランサーのヘルスチェックは、クライアントが到達する前に、正常に動作していないターゲットをローテーションから除外します。それぞれに制限があるため、これらを組み合わせて利用する必要があり、自動化はこれら4つのいずれかを置き換えるのではなく、そのすべての上に位置づけられます。
DNS サービスの高可用性を実現するには、ハードウェアのフェイルオーバー、DNS プロトコルの冗長化、分散アーキテクチャ、ロードバランサーのヘルスチェックという 4 つの方法があります。これらを組み合わせることで、単一の方法では実現できない、重なり合うセーフティネットが形成されます。
Read article
If you have just one DNS server, what happens if it fails? Four avenues to DNS high availability are the key to a redundant and resilient network.
自動化されたDNSフェイルオーバーは、4つのステップで実行されます。 第一に、ヘルスチェックによってターゲットに到達できないことが検出されます。第二に、その結果を受けて、コンソールではなくDNSコントロールプレーンのAPIを通じて変更がトリガーされます。第三に、レコードまたはゾーンの内容が、すべての権威あるコピーに対して一斉に更新されます。 第四に、キャッシュされた応答の有効期限が切れると、クライアントもそれに追従します。この最後のステップにかかる時間は、自動化の速度ではなく、レコードのTTLによって決まります。
検出が何が障害とみなされるかを決定するものであり、自作のフェイルオーバーの多くがここで失敗します。アプリケーションのエンドポイントに対するヘルスチェックは、それをホストするサーバーへのpingよりもはるかに多くの情報を提供します。また、しきい値は、SLAを確実に満たしつつ、一時的な変動でトリガーされないよう、十分に保守的に設定する必要があります。 変更そのものは、コンソールでの編集ではなくAPI呼び出しで行うべきです。コンソールでの編集は1つのプラットフォームにしか届かず、そこで止まってしまうからです。REST、SOAP、JSON-RPCを網羅した包括的なAPIサポートがあれば、そのようなワークフローをスクリプト化して繰り返し実行でき、プレッシャーのかかる状況下で手作業で行う必要がなくなります。
プロパゲーションこそが、ハイブリッド環境の弱点となる部分です。ゾーンが冗長性グループに複製されている場合、1回のAPI呼び出しがすべてのメンバーに届くため、フェイルオーバーが発生する前にスタンバイ側の回答はすでに正しい状態になっており、インシデント発生中に書き込まれる必要はありません。 その後、再帰的リゾルバーがTTLクロックに基づいて古い応答をエイジアウトします。そのため、計画的な変更に先立ち、DNS AレコードのTTL値を約300秒に下げ、環境が安定したら3600秒以上に戻す必要があります。
Read article
An A record in DNS is the fundamental record type used to assign an IP address to a DNS name. Devices on their own do not understand how to communicate with…
DNSやDHCPは災害復旧計画において見過ごされがちであり、IPアドレス管理についてはほとんど考慮されることがありません。 チームは、サーバーベースのデフォルト設定と手動による追跡で十分だと想定していましたが、計画段階で、環境内に何がどこに存在すべきかを記録しているものが何もないことに気づき、フェイルオーバーをテストすることはできず、試みるだけにとどまってしまいました。
ある組織は、災害復旧計画の策定中に、メインのデータセンター、バックアップサイト、および複数の地理的に分散した施設にあるすべてのドメインコントローラーからDNS応答が返されていることを発見しました。DHCPでは100以上のスコープが管理されており、それらが2台のサーバー間に不自然な形で分割されていました。どのIPアドレスが使用中であるかという記録は、ある担当者のクラウドストレージにバックアップされたExcelスプレッドシートに保存されていました。
問題はサーバーそのものではなかった。問題は、環境の全体像を把握しているシステムが1つも存在しなかったため、トラフィックによって実証されるまでは、スタンバイが正しく応答するかどうかを確認する方法がなかったことだった。 アドレスデータとDNS設定が、暗黙の知識やスプレッドシートではなく単一のプラットフォームに集約されると、フェイルオーバーはチームがリハーサルして確認できるものとなり、テストされたイベントはサービスの損失もなく、人的介入を必要とせずに実行されました。
Read article
A BlueCat customer discusses why organizations can’t afford to overlook DNS, DHCP and IPAM when planning for a disaster.
複数のコンソールで同じゾーンを編集するのではなく、1つのシステムを「真実の源」とし、そこから下流へ同期させることで、ドリフトを低減できます。 その同期は、外部だけでなく内部のビューもカバーする必要があります。なぜなら、パブリックゾーンのみを更新するフェイルオーバーでは、パブリック側の切り替えが成功した後も、内部クライアントが故障したアドレスへの解決を続けてしまうからです。
複数の管理コンソールにわたる手動更新は、サービス停止の原因として報告されており、3つの課題を残します。それは、1つのプロバイダーがゾーンを単独で管理する単一障害点、そのプロバイダーが攻撃を受けた際の対策の限界、そして別々のインターフェースにまたがる可視性の断片化です。 レプリケートされたライブゾーンのコピーから冗長性を構築すると、各サーバーは独自の一意な NS レコードと SOA レコードを維持しつつ、A、CNAME、MX レコードなどは同期されたままとなるため、あるコピーが他のコピーから知らぬ間に乖離してしまうことはありません。
スプリットホライズンDNSでは、変更を加える必要がある箇所が2倍になります。クラウドリゾルバーを指す条件付きフォワーダー、VPCごとのプライベートゾーン、ドメインコントローラー上のActive Directory統合ゾーンなどを加えると、単一の論理的なフェイルオーバーでさえ、4つあるいは5つのシステムに正しい順序で反映させる必要がある変更となってしまいます。 この問題の解決策は、労力ではなくスコープにあります。ゾーンの内部コピーと外部コピーは同じ同期境界内に配置する必要があるため、一度変更を行うだけで両方に反映されます。
Read article
Discover how Micetro’s xDNS® simplifies hybrid cloud DNS management with redundancy, protection against DNS attacks, and enhanced visibility.
次の4つの点を確認してください。ドメインのクエリに応答するすべてのコピー間でゾーンの内容がレプリケートされていること、インフラストラクチャ・アズ・コード（IAC）と統合されたAPIファーストのコントロールプレーン、完全な監査ログを備えた一元化されたロールベースのアクセス制御、そしてテスト済みの復旧ツールです。 これらはそれぞれ、このページの前の部分で説明した障害モードの逆のものです。プラットフォームを、すでに稼働中のサーバー上に展開するか、あるいは組織が標準化するプラットフォームとして展開するかは、チーム規模や近代化計画に基づいて決定される別の課題です。
レプリケーションとAPIによる制御がフェイルオーバーを実現します。レコードは、インシデント発生時に書き換えるのではなく、インシデント発生前にすべての権威あるコピー間で同一である必要があり、それらを変更する操作は、プラットフォームごとにコンソール編集を繰り返すのではなく、単一のAPI呼び出しで済む必要があります。この2つの条件を満たすプラットフォームであれば、チームはプレッシャーの下でフェイルオーバーを試みるのではなく、予定通りにリハーサルを行うことが可能になります。
ガバナンスと復旧策によって、その有効性が決まります。すべてのトランザクションと構成変更は、認証され、ログに記録され、監査可能である必要があります。また、変更管理のための多段階承認ワークフローと、個々のゾーンやDHCPスコープにまで及ぶほどきめ細かなロールベースの権限設定が必要です。データベースの同期、定期的なバックアップ、および文書化された移行・復旧パスを備えたクラスタリングにより、復旧面がカバーされます。
Read article
Learn with BlueCat how visibility and control, process automation, and infrastructure reliability offer three reasons to adopt Unified DDI.
BlueCat Micetroは、既存のサーバーを置き換えるのではなく、サービスを中断しないオーバーレイを通じてオーケストレーションを行うことで、DNSおよびDHCPのサービスレベルを維持しています。 組織は、Microsoft DNS、ISC BIND、ISC DHCP、および Kea DHCP を本番環境で運用し続けながら、それら全体にわたる統一された制御、冗長性、および変更ガバナンスを実現しています。
Micetroは、既存のDNSおよびDHCPサービスへの大規模なアップグレードを必要とせず、仮想マシン、クラウド、またはベアメタル環境に1時間以内にインストールできます。単一のプロキシエージェントがMicrosoftサーバー全体に散在するエージェントを置き換え、個々のDHCPスコープやDNSゾーンに対するきめ細かなロールベースの権限設定により、稼働時間に影響を与えるドメインコントローラーへの不要な変更を制限します。
可用性の面では、xDNSの冗長性により、DNSの単一障害点への曝露を低減し、DDoSやその他のDNS攻撃に対する緩和策を強化します。 冗長性グループは、BIND、Windows DNS、Azure DNS、Amazon Route 53、NS1、Dyn、Akamai Fast DNS にまたがって構成することができ、障害発生時には代替メンバーがゾーンの権威あるサービス提供を引き継ぎます。一元化された DHCP 管理と DNS ワークフローキューにより、すべての変更にはリクエストと承認のプロセスが伴います。
Read article
Today’s enterprise networks span data centers, cloud environments, and distributed edge systems. DNS, DHCP, and IP address management (together known as…
Read article
With Micetro, integrate, orchestrate, and automate your current DNS, DHCP, and IPAM network infrastructure via a single web interface.
BlueCat Integrityは、DNS、DHCP、IPアドレス管理を単一のプラットフォームに統合し、唯一の信頼できる情報源を確保します。これにより、インシデント発生前にスタンバイ構成を検証でき、トラフィックによるテストを行う必要がなくなります。 Integrityと Micetroは、同じ結果に至る2つの手段です。組織はどちらか一方を選択し、両方を採用することはありません。
Integrityは、BlueCat Address ManagerとBlueCat DNS/DHCPサーバーをハブ・アンド・スポーク型アーキテクチャで統合し、1台のエンタープライズグレードのアプライアンスで数千台のDNSおよびDHCPサーバーを管理します。 段階的なアップグレードにより、環境は一度にすべて切り替えるのではなく、順次一元管理下に置くことができます。また、DNS および DHCP のフェイルオーバーにより、IPv4 と IPv6 の両方でサービスの稼働時間を維持します。組み込みの災害復旧機能と高可用性に関する洞察により、チームは準備状況を検証できます。これにより、復旧テストは「不意に発生するもの」ではなく、「予定されたもの」へと変わります。
ガバナンスと自動化も同時に実現されます。ベンダーに依存しないRESTful OpenAPIにより、自動化によってDNS、DHCP、IPAMをプログラム的に制御し、ServiceNowなどのサードパーティサービスと統合してセルフサービスプロビジョニングが可能になります。 ロールベースのアクセス制御、ネットワークテンプレート、IP モデリングツールにより、アドレス空間の構造を一度定義するだけで済み、Prometheus ベースのリアルタイムメトリクスにより、ダウンタイムにつながる前に問題を特定できます。
Read article
BlueCat Integrity X is a software suite that centralizes and automates mission-critical DNS, DHCP, and IP address management (DDI) services across…
Read article
Tame network complexity with Integrity's full-stack DDI management platform and get visibility and control over your DNS, DHCP, and IPAM.
適切なアプローチは、現在の脆弱性がどこにあるかによって異なります。トポロジーにあるのか、一致すべきコピー間の不一致にあるのか、あるいは冗長性は存在するが完全に手動で維持されているという事実にあるのか。上記のセクションから、3つのアプローチが導き出されます。
オンプレミス環境とクラウド環境をまたぐDNSフェイルオーバーを計画する際、ネットワークチームが抱く疑問。
まだご質問がありますか？
BlueCatの担当者から具体的な回答を得ましょう。
