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

仕組み

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：Edgeを活用して、信頼できるサービスへのローカルブレイクアウトを提供すると同時に、ローカルでの解決が適切に行われることを保証する。

ユースケース 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に転送されます。