インテリジェント・フォワーディング

仕組み

EdgeがDNSクエリを受信すると、適切なDNSネームスペースを選択するためのゾーンを決定します。この際、一致する宛先ゾーン、送信元IPまたはネットワーク、セキュリティポリシー、およびフォワーダーの優先順位が考慮されます。

ゾーンを特定した後、Edgeは解決に適切なDNSネームスペースを選択します。Edgeがクエリを送信する候補となるフォワーダーのセットを決定すると、選択された各ネームスペースを順番に試行し、有効な応答を探します。 リゾルバーがネームスペースから否定応答を受信した場合、その応答を記憶し、次のネームスペースに移行して、肯定応答が得られるまでクエリの解決を試み続けます。すべてのネームスペースを網羅しても肯定応答が得られない場合、クライアントには否定応答が返されます。

インテリジェント・フォワーディングを活用するには、1つ以上のDNSフォワーダーを指定してネームスペースを構成し、必要に応じて一致ドメインリストや例外ドメインリストを含めることができます。 Edge内の各サイトには、少なくとも1つ、最大10個までのネームスペースが関連付けられています。DNSキャッシュはネームスペースごとに分割されており、異なる解決パスからの応答が混在するのを防ぎます。Edgeは、クエリのパフォーマンスを完全に最適化し、さまざまなDNSオーソリティ間で状態を維持することで、最適なクライアント体験を確保します。

また、ネームスペースではゾーンの重複も可能です。権威サーバー上のゾーン内の個々のレコードを追加または変更する際、そのゾーン内のすべてのリソースレコードが利用可能である必要はありません。 クラウドコンピューティングなどの動的な環境では、異なるネットワークが同じゾーンを使用しながらも、レコードのサブセットに対して異なる応答を必要とする場合があるため、ゾーンの重複が求められます。従来の条件付き転送ルールや他のリゾルバソリューションとは異なり、Edgeの転送ポリシーは、シンプルな管理でこの柔軟性を提供し、DNSリソースレコードの管理を容易にします。

図1. AWSとAzureにリソースを持ち、xyz.comというドメインを持つネットワーク環境。クエリに一致するものがない場合、外部リゾルバーに転送されます。

9種類のユースケース

このセクションでは、Edgeインテリジェントフォワーディングを使用して従来のDNSフォワーディングを拡張し、ハイブリッド環境や分散環境全体での名前解決をより細かく制御することのメリットを示す、9つの実例を紹介します。

ユースケース 1: スプリットビュー DNS ゾーン

企業では、プライベートDNSとパブリックDNSで、同じゾーンの異なるビューを使用することがよくあります。これにより、同じ名前を持つ同じサービスを、内部と外部の両方で解決できるようになります。スプリットビュー（スプリットブレインやスプリットホライズンとも呼ばれる）により、各ビューをあたかも異なるゾーンであるかのように個別に管理することが可能になります。

しかし、外部ゾーンビューのリソースレコードは、内部ビューでも維持されなければなりません。これがエラーの原因となります。 企業は、Webプロキシを使用してサービスの場所を決定することで、この問題を解決しようと試みてきました。一部の環境では、「内部ルート」がパブリックルートゾーンを上書きし、これらのDNSネームスペースを完全に分離しています。ダイレクトインターネットアクセスへの移行により、この仕組みは機能しなくなり、企業はスプリットビューレコードを解決する手段を失ってしまいます。

EdgeはDNSレベルで介入し、DNSゾーンのスプリットビューに対処します。クライアントは複数のビューを解決できるほか、企業のDNSインフラストラクチャ外のゾーンに対してはダイレクトインターネットアクセスを利用できます。

Edgeの役割：インテリジェント・フォワーディングにより、xyz.comに対して内部用と外部用の2つのネームスペースを作成できます。Edgeは、ネガティブレスポンスを受けた後も解決が成功するまで解決を試み続けます。 xzy.com を宛先とするクエリには、内部および外部の xyz.com ネームスペースの両方でクエリを実行すべきであることを示す一致するゾーンが設定され、内部の回答が見つからない場合にのみ外部の回答が返されます。これにより、スプリットビュー DNS を管理する必要がなくなります。

図2：環境内で内部ドメイン名と外部ドメイン名が同一である場合、最大の課題は、正しい解決パスが確実に利用されるようにすることであることが多い。

ユースケース 2：移行中のサービス停止リスクの軽減

ほとんどのDNS移行では、計画的な切り替え期間を設けてデータを移行します。 組織にとっての大きな懸念は、移行中のサービス停止リスクです。各移行イベント（移行によっては数年間にわたり50件以上のイベントに及ぶ場合もあります）において、新しい環境でのDNSデータの欠落や設定ミスがサービス停止を引き起こすリスクが伴います。このリスクを軽減することは極めて重要です。

Edgeの活用方法：Integrityへの移行中は、インテリジェント・フォワーディングを利用して、耐障害性の高いDNSインフラを構築できます。これにより、DNSレコードの欠落や設定ミスに起因するサービス停止を回避できます。Edgeはまず新しいBlueCatインフラにクエリを送信します。応答がない場合は、レガシーDNSサーバーにクエリを送信します。

図3：従来のDNSからの移行においてEdgeを使用する場合の典型的な初期状態。

ユースケース 3：ステルス移行による迅速な完了とサービス停止リスクの低減

ダウンタイムゼロでのDNS移行は可能です。しかし、インフラストラクチャやサービス中断に対する許容度によっては、移行作業が遅く、手間がかかり、リスクが高く、コストもかかる場合があります。多くの移行では、正確で関連性の高いレコードのみが新しい環境に移行されるよう、移行前に既存のDNSデータをクリーンアップするために多大な労力を費やす必要があります。

Edgeを利用することで、組織はレガシーなDNS環境からIntegrityのDNSインフラストラクチャへ、プログラム的に、受動的かつ効率的に移行することができます。

BlueCatのステルス移行プロセスの初期段階では、EdgeはDNSクエリをレガシーDNS環境に転送するように設定されます。レガシーインフラストラクチャから返されたレコードは再作成され、新しいBlueCat DNSインフラストラクチャにコピーされます。ネガティブレスポンスが返されたクエリは、新しいBlueCat DNSインフラストラクチャに転送されます。

指定された期間が経過すると、ネームスペースの順序が入れ替わります。これにより、新しいBlueCatインフラストラクチャがDNSクエリのプライマリとなります。BlueCatからネガティブレスポンスを受け取ったクエリは、レガシーDNSインフラストラクチャに転送されます。レガシーDNSインフラストラクチャによって解決されたクエリのレコードは、その後、新しいBlueCat DNSインフラストラクチャに再作成されます。

Edgeの活用方法： ステルス移行では、 Edgeのクエリログを活用し、レコードがクエリされるたびにデータを移行します。ネームスペースを活用することで、レコードをオンザフライで移行でき、解決処理を継続させながら、従来のカットオーバー作業を不要にすることができます。

図4：EdgeをDNSステルス移行と併用する場合の典型的な初期状態。

図5：EdgeとDNSステルス移行を併用した場合の典型的な最終状態。

ユースケース 4：M&AにおけるDNSを活用したネットワーク統合

合併や買収をインフラに統合するのは困難な作業です。名前衝突、IPアドレスの重複、複雑な転送ルールによって引き起こされるサービス停止やその他の問題には、多くの場合、手動による対応が必要となります。

Edge を使用すると、レガシーネットワークや買収したネットワークからのクエリが、権威DNSサーバーに直接クエリを送信することで、解決の失敗を回避できます。これにより、ネットワークチームはDNSデータを特定し、問題を解決しやすくなります。前述のステルス移行プロセスと組み合わせることで、受動的でリスクの低いアプローチを維持しつつ、DNSデータの迅速な統合が可能になります。

Edgeの活用方法：管理者は ドメインリストを使用して、クライアントのリクエストを適切なDNSサーバーにルーティングするようEdgeを設定できます。その後、EdgeはステルスDNS移行機能を活用し、組織間で関連性があり正確なデータのみを転送します。移行後、ネームスペースの順序が更新され、最適な解決パスが確保されます。

ユースケース 5: DNS クエリのルーティング最適化

従来のハブ・アンド・スポーク型ネットワークでは、ローカル以外のすべてのトラフィックが中央データセンターにバックホールされます。これにより、DNSクエリの応答のローカライゼーションに関する問題が生じることが多く、すでに利用率が高くコストのかかるWAN回線が飽和状態になる可能性があります。

Edgeは、DNSクエリパスを最適化します。これにより、追加のトラフィックを考慮した場合よりも小型のルーターを導入できるようになり、支店拠点でのインフラ要件とWAN全体のコストを削減できます。また、最適化されたクエリパスには、レイテンシの低減や、エンドユーザーによるよりローカルなサービスへのアクセス制限の解消といった、目に見えないメリットも提供されます。

たとえば、サーバーはローカルで store301.xyz.com ゾーンにクエリを送信するため、コアデータセンターへのトラフィックのバックホールが回避されます。 Office 365 などの、あらかじめ定義された信頼できる外部サービスへのトラフィックは、支店の ISP 接続を経由してローカルの外部リゾルバーに直接ルーティングされます。これにより、パフォーマンスが向上し、WAN コストが削減され、よりローカライズされた DNS 応答が提供されます。

Edgeの活用方法：ネームスペースに対してドメインまたはゾーンのマッチリストを設定することで、クエリのルーティングを最適化します。これにより、ローカライゼーションの問題を防止し、WANリンク上の過剰なDNSトラフィックを削減します。

図6：エッジを活用して、ローカルでの解決が適切に行われることを確保しつつ、信頼できるサービスへのローカル・ブレイクアウトを実現する。

ユースケース 6：クラウド DNS 統合のための単一の信頼できる情報源の構築

クラウドネイティブDNSは通常、独立したコンポーネントとして管理されます。そのため、単一のDNSソリューションがネットワークの「真実」の唯一の源泉となることはできません。DNS解決が継続的に機能するようにするため、ハイブリッドクラウド環境では

複雑なフォワーディングルールにより、VPNや専用ネットワーク接続を介したネットワークトラフィックのルーティングが非効率になることがあります。マルチクラウドソリューションに移行する顧客も、複雑なクロスクラウドのフォワーディングルールに悩まされることになります。さらに、クラウドへの移行や導入により、DNSの解決やパフォーマンスに関する問題が発生する可能性がありますが、完全な可視性がなければ、これらの問題をデバッグすることは困難です。

Edge を使用すると、クラウド中心のすべての DNS トラフィックはローカル DNS リゾルバーにルーティングされ、そのリゾルバーがトラフィックを転送するのに最適なリゾルバーを決定します。ネットワークチームは、単一の管理画面からクラウドとオンプレミスの両方の DNS を管理できます。

主要なクラウド間のプライベートリンクサービスでは、仮想プライベートクラウド（VPC）や仮想ネットワーク（VNet）をまたいでゾーンが共有されることがよくあります。しかし、Edgeは重複するゾーンをまたいで解決できるため、特定のプライベートリンクレコードは正しく解決されます。

すべての解決データは、監査やデバッグに利用可能です。各クエリの発信元が追跡され、レイテンシやその他のパフォーマンスデータを完全に可視化できます。

クラウドコンピューティングは通常、DNSの使用状況が予測可能なセグメント化されたサービスに分割されています。これにより、リモートサービスへのアクセスに関するポリシーを用いてDNSをセグメント化したり、システムが悪用されてDNSがコマンド＆コントロールに利用されるリスクを低減したりする十分な機会が得られます。

Edgeの活用方法：Edgeでは 、2つの方法のいずれかでネームスペースを設定できます。 1つ目は、クラウドプロバイダーに応じた適切なドメイン名を含むドメインリストを使用する方法です。2つ目の方法は、優先順位に基づいてネームスペースを設定する方法で、まずVPC内またはVNet内のトラフィックを検索し、次に共有サービスVPCまたはVNetを検索し、最後にオンプレミスのDNSを検索します。

図7：典型的なクラウド統合構成。クエリはVPCまたはVNetに入り、次に共有サービスVPCまたはVNetを経由して、オンプレミスのDNSへと送信されます。

ユースケース 7：プロキシバイパスとダイレクトインターネットアクセス

プロキシサーバーは通常、コストを最適化するために中核データセンターに一元的に配置されます。そのため、インターネット向けのトラフィックは中央の拠点を経由せざるを得ず、これがサービスの位置情報の不正確さ、高い遅延、ユーザー体験の低下につながることがよくあります。プロキシサーバーの一元化は、リモートオフィスや支店におけるローカルなインターネット接続をさらに複雑にします。

Edgeを利用することで、クライアントが内部および外部を問わずすべてのクエリを確実に解決できるようにし、信頼できるサービスへのダイレクトインターネットアクセス（Direct Internet Access）のためのローカルブレイクアウトを有効にし、セキュリティチームが必要とする制御と監視を維持することができます。

Edgeの活用方法： Edgeのネームスペースを使用すると 、対象となるドメイン名に基づいて、内部または外部のリゾルバー、あるいはインターネットベースのリゾルバーにDNSトラフィックをクエリするように設定できます。また、Edgeはリモートオフィスや支社にも導入され、ローカルブレイクアウトを実現します。

図8：遠隔支店からのダイレクトインターネットアクセスによるプロキシバイパスの典型的な構成。

ユースケース 8：IoT デバイスのセキュリティ確保

IoT（モノのインターネット）デバイスは、更新頻度が低いことやセキュリティパッチの不足により、サイバー攻撃に対して脆弱です。 IoTデバイスは、ネットワーク上の他のノードと同様に扱われることがほとんどですが、その性質上、そのアクティビティの監視が不十分になりがちです。これに加え、多くのデバイスがDNSデータへの無制限のアクセス権を持っているという事実も相まって、悪意のある攻撃者にとって魅力的な標的となっています。

Edge を使用すると、セキュリティエージェントなどの従来の制御手段が利用できない場合でも、IoT デバイスに対する DNS アクセスを事前に承認された特定のレコードに制限し、それらにセキュリティポリシーを適用することができます。

Edgeの活用方法：Edgeを使用すると 、特定のDNS設定やセキュリティポリシーを実装し、IoTデバイスを一元管理できます。DNSポリシーを適用することで、事前に定義された内部および外部サービスへのアクセスのみを許可します。また、ネームスペースを使用することで、IoTデバイスがクエリを実行できる対象デバイスを指定することも可能です。

図9：IoTデバイスは、特定のセキュアDNSサーバーのみの使用が許可されています。それ以外はすべてブロックされます。

ユースケース 9：IP クエリの発信元に関する可視性を活用して Cisco Secure Access を強化する

Cisco Secure Accessは、特定の脅威に関連するクエリを識別してブロックするためのクラウドベースのリゾルバーを提供します。 このソリューションの欠点の1つは、すべてのDNSリクエストが、Cisco Secure Accessの外部再帰システムに到達する前に、内部DNSサーバーを経由して再帰処理されなければならないことです。このため、Cisco Secure Accessはクエリのクライアントの送信元IPアドレスを把握できなくなり、内部ネットワークに死角が生じることになります。

Edgeの活用方法：BlueCatは、外部向けDNS脅威対策においてCisco Secure Accessと独占的に提携しています。Edgeは、EDNS Client Subnetを使用してクライアントの送信元IPアドレスを維持しつつ、外部からのDNSクエリをフィルタリングのためにCisco Secure Accessに直接転送します。 IDサービスが有効になっている場合、クエリには組織のIDプロバイダーからのユーザーID情報が付加されるため、Cisco Secure Accessの管理者は、すべてのクエリについて送信元IPとユーザーIDの両方を確認し、それに基づいて対応することができ、可視性とポリシー適用が向上します。

図10：内部と外部で同じドメインを使用する場合の設定例。クエリの宛先がインターネットである場合、そのクエリはCisco Secure Accessに転送されます。