F5 Infoblox...

Copyright ©2010 All rights reserved F5 Networks Japan K.K.

TECHNICAL BRIEF

March-2010

ソリューション

F5と InfobloxによるDNS統合アーキテクチャ：安全性と拡張性を備えた完全な DNSソリューションを提供アプリケーション・デリバリ市場のマーケットリーダーである F5とDNS、DHCP、IPアドレス管理（DDI）市場のマーケットリーダーである Infoblox がタッグを組み、完全な DNSソリューションをお客様に提供します。同ソリューションは、優れたDNS管理機能、柔軟でインテリジェントなグローバル・サーバ・ロードバランシング、高性能でスケーラブルな DNS、およびすべてのゾーンをカバーする DNSSEC署名で構成されています。

ネイサン・メイヤー（Nathan Meyer）F5 プロダクトマネージャ

クリケット・リュー（Cricket Liu）Infoblox アーキテクチャ部門バイス・プレジデント

目次

2 前提とされる知識

2 用語

� 序文

� DNSセキュリティ拡張（DNSSEC）の概要

� リアルタイム DNSSEC

� リアルタイム DNSSECの設定

� Infoblox DNSSECの設定

� F�と Infobloxのアーキテクチャの概要

� Delegationアーキテクチャ

� CNAMEエイリアスを使ったショートカット

� Delegationアーキテクチャの DNSSEC設定

� Delegationアーキテクチャのまとめ

� Authoritative Screeningアーキテクチャ

11 Authoritative ScreeningアーキテクチャのDNSSECオプション

11 高度な IP Anycast構成

11 Authoritative Screeningアーキテクチャのまとめ

12 Authoritative Slaveアーキテクチャ

12 Authoritative SlaveアーキテクチャのDNSSECオプション

1� Authoritative Slaveアーキテクチャのまとめ

1� アーキテクチャの選択

1� まとめ

1� 関連資料


TECHNICAL BRIEF

March-2010 2

前提とされる知識

本資料は、読者が標準 DNSアーキテクチャに精通し、DNSSECの仕組みと通常の導入方法に関する基本知識を持っていることを前提に書かれています。さらには、グローバル・サーバ・ロードバランシング技術とその機能についてある程度理解していることも前提となります。DNSとDNSSECについて説明した資料にはさまざまなものがあり、Infobloxと F5のWebサイトでも、製品の機能、導入方法、詳細な設定について詳しく説明しています。

この技術資料では、F5と Infobloxのアプライアンスを統合するための 3つのアーキテクチャをカバーする、ハイレベルなアーキテクチャについて取り上げています。さらには、各種アーキテクチャの導入について理解してもらうために、リアルタイム DNSSECに関する機能情報も提供しています。組織の DNSシステムを設計する方法にはさまざまなものがあり、また設定のコツも多数存在します。本資料は統合DNSソリューションの設計方法について 1つひとつ分析するためのものではなく、もっとも有用で一般的なアーキテクチャを紹介することを目的に作成されたものです。これを読むことで、F5と Infobloxによる統合アーキテクチャの構成を理解し、BIG-IP GTMと Infoblox DNSの導入計画を開始することができます。設定の詳しい情報については、各社のWebサイトで提供している F5 BIG-IP GTMと Infobloxアプライアンスのマニュアルをご参照ください。

用語

本資料では、略語、DNSに関する一般名称、製品固有の用語が複数使われています。

ローカル・ドメイン・ネームサーバ（LDNS） ― クライアントが再帰的な照会をするための DNSサーバ。ほとんどの DNSクエリが、クライアントではなく LDNSサーバから送信されます。

完全修飾ドメイン名（FQDN） ― ホストとドメインの両方を含む完全な DNS 名（例：www.example.

com）。

グローバル・サーバ・ロードバランシング（GSLB） ― 任意のレコードクエリに対して最適な IPアドレス回答を返すために使用されるインテリジェント DNSの機能と方式を表す総称。

BIG-IP® Global Traffic ManagerTM（GTM） ― GSLBサービスの提供に使用される F5 の製品。 BIG-IP GTMはアプリケーション・クライアントとデータセンター間のトラフィックを管理します。

F5 BIG-IP® Local Traffic ManagerTM（LTM） ― 特定のWebサービスやその他の用途でロードバランシングとアプリケーション・デリバリを提供するのに使用される F5の製品。BIG-IP LTMはデータセンターやサーバグループ内のトラフィックを管理します。

ワイド IPアドレス（WIP） ― F5の製品用語。BIG-IP GTMが管理するリソースを表す完全修飾ドメイン名を指します（例：www.example.com、www.gtm.example.com）。

キー署名キー（KSK） ― ZSKなど他のキーの署名に使用されるキー。

ゾーン署名キー（ZSK） ― ゾーンの署名レコードの署名に使用されるキー。


TECHNICAL BRIEF

March-2010 �

スタート・オブ・オーソリティ（SOA） ― DNSゾーンに関する権限情報（プライマリ・ネーム・サーバ、ゾーンの管理者のメールアドレス、ゾーンのシリアルナンバ、ゾーンの更新に関連する複数のタイマなど）を指定します。

正規名レコード（CNAME） ― ドメイン・ネーム・システム（DNS）内のリソースレコードの 1種。そのドメイン名が正規のドメイン名のエイリアスであることを指定します。

アドレスレコード（Aレコード） ― 32ビットの IPv4アドレスを返し、通常、ホスト IPアドレスにホスト名をマップするのに使用されます。

メール交換レコード（MXレコード） ― そのドメインのメッセージ転送エージェントのリストにドメイン名をマップするものであり、通常、Aレコードが返されます（例：mail.example.com）。

序文

多くの組織が、DNS管理、インテリジェントなグローバル・サーバ・ロードバランシング、パフォーマンス、セキュリティのベストオブブリードの機能を提供する、完全な DNSソリューションを求めています。使いやすい管理機能と一口に言っても、DNSアプライアンス・ベンダーが提供するものとグローバル・サーバ・ロードバランシングにフォーカスしたアプリケーション・デリバリ・ベンダーが提供するものとの間には、以前からギャップがありました。DNSSEC機能とは、DNS応答の信頼を保証することでインターネット環境の保護を強化するものですが、その提供に必要な新しい要件を見れば両者のギャップは明らかです。完全なソリューションを単独で提供できるベンダーは 1社もありません。アプリケーション・デリバリ市場のマーケットリーダーである F5とDNS、DHCP、IPアドレス管理（DDI）市場のマーケットリーダーである Infobloxが、完全なDNSソリューションをお客様に提供するためにタッグを組むことになりました。同ソリューションは、優れたDNS管理機能、柔軟でインテリジェントなグローバル・サーバ・ロードバランシング、高性能でスケーラブルな DNS、およびすべてのゾーンをカバーするDNSSEC署名で構成されています。

DNSセキュリティ拡張（DNSSEC）の概要

DNSセキュリティ拡張（DNSSEC）は、DNSの脆弱性の「封じ込め」とDNSシステムの整合性を損なうDNSキャッシュ・ポイズニング攻撃の緩和に欠かせないツールとなる、というのが IOActiveのペネトレーション・テスティング部門ディレクタであるダン・カミンスキー（Dan Kaminsky）氏をはじめ、多くのセキュリティ・エキスパートの見方です。DNS攻撃は、クレジットカード情報やパスワードを収集するための偽サイトにユーザを誘導し、メールをリダイレクトするだけでなく、DNSに依存するあらゆるインターネット・アプリケーションに害をおよぼします。DNSSECを導入することで、システムが DNS情報の信頼性を検証するための、自動化された信頼の基盤が構築されます。

残念なことに、暗号化キーを供給する際の処理の複雑さと、DNS情報の署名に伴うオーバーヘッドがネックとなり、DNSSECはいまだ普及にはいたっていません。F5が革新的なリアルタイム署名機能を開発する以前は、グローバル・サーバ・ロードバランシング（GSLB）システムからの DNS応答を保護するための選択肢は存在しませんでした。ハイアベイラブルなインテリジェント DNSシステムを導入するか、もしくはDNSSECを使ってDNSインフラストラクチャを保護するか、2つに 1つしかなかったのです。

「DNSセキュリティが十分でなければ、インターネットの脆弱性を招くだけでなく、重要なセキュリティ技術の拡張性までも損なわれてしまいます。DNSSECは深刻な脅威に対応するための最適なソリューションを提供します」

IOActive ペネトレーション・テスティング部門ディレクタ、ダン・カミンスキー（Dan Kaminsky）氏


TECHNICAL BRIEF

March-2010 �

F5と Infobloxによる複合ソリューションは、ソリューション同士がたがいに補完しあうことでこれらの問題に対処します。つまり、高性能なDNS機能とGSLB機能で構成され、署名済みのDNSSECデータをサポートする、完全統合型の DNSSECソリューションが市場に登場したことになります。これによって、DNS攻撃に対処できるだけの能力を持ち、拡張性と管理性を備えたセキュアな DNSインフラストラクチャがお客様にもたらされます。

このソリューションは、高度な信頼性と管理性を備えたセキュアな DNSサービスを提供する、自動DNSSEC機能搭載の Infobloxの専用アプライアンスと、リアルタイムの DNS応答署名用に最適化されたF5® BIG-IP® Global Traffic ManagerTM（GTM）を組み合わせたものです。Infobloxの DNSSEC機能は、暗号キーの生成と、ゾーンデータの署名、および DNSデータを管理するあらゆる Infobloxアプライアンスへのサイン済みデータの分散というすべての処理を自動で行う「ワンクリック」プロセスにより、手動によるキー生成とゾーン署名を自動化します。F5は、FIPS 140-2要件を満たす連邦情報処理標準（FIPS）準拠のオプションを提供します。

F5と Infobloxのシステムはいずれも、米国標準技術局（NIST）が推奨するキーポリシーをサポートしています（NISTの『Special Publication 800-81 Secure DNS Deployment Guide』を参照）。

リアルタイムDNSSEC

F5は特許出願中のリアルタイム署名技術を通して DNSSECを実装しており、このことは F5と Infobloxによる 3種のジョイント・アーキテクチャ・ソリューションの設計上の重要な鍵となっています。標準的なDNSSEC 実装の場合、SOA、MX、Aレコードのいずれであっても DNSクエリに対して同じ応答を返す、きわめて静的なゾーン設定が想定され、ゾーンのレコードが変更されることはほとんどありません。ゾーンは通常、適切なキーとハッシングにより事前署名され、すべてが同じ静的なゾーンファイルに保存されます。大規模なゾーンになると、サイズによっては署名に 30分以上かかる場合もあります。Infobloxでは、レコード情報の変更に伴うオーバーヘッドを削減する逐次署名をサポートしています。さらには、市場をリードするシングルステップの DNSSEC署名と自動キー管理により、標準 DNSゾーンの DNSSEC 応答を容易に提供できるようになっています。

グローバル・サーバ・ロードバランシング（GSLB）とは、要求元の LDNSの IPアドレスから得られた情報をもとに、最適な回答をリソースに返すというものです。GSLBの導入の際には、ラウンドトリップ時間の計算や IPジオロケーション、ダイナミック・サーバ・ロード、比率、リソース・モニタリングなど、多数のオプションとモードを指定できるようになっています。LDNSサーバは任意のAレコード要求に対して異なる回答を受信する場合があることから、同じLDNSでもその時々で受け取る回答が変わってくる可能性があります。通常、GSLBサービスは従来の DNSSEC 実装と互換性を持たず、DNSSEC仕様も GSLBを念頭に置いた設計にはなっていません。


TECHNICAL BRIEF

March-2010 �

F5 BIG-IPは、TMOS®というユニバーサルな共有プラットフォーム上で動作します。TMOSは BIG-IPがDNS要求を受信すると同時にそれを遮断し、その要求が正常な DNS要求または DNSSEC要求かどうかを記憶します。続いて、解決のために BIG-IP Global Traffic Manager（GTM）モジュールに要求を送信します。要求のタイプが適切なものであれば、BIG-IP GTMはビジネスルール、モニタリング、グローバル・ロードバランシング機能をすべて考慮した上で要求を処理し、その後 TMOSに送信します。オリジナルの要求が DNSSEC要求であれば、TMOSは高速暗号化ハードウェアを使ってリアルタイムでリソース・レコード・セットへの署名を行い、LDNSサーバに応答を送信します。この方法は、Infobloxアプライアンスに渡される標準 DNS要求に対しても有効に作用します。暗号化ハードウェアと専用の署名 RAMキャッシュにより、TMOSではほとんどのクエリに対するリアルタイムでの高速署名が可能になっています。しかし、GSLBエレメントが含まれないきわめて大規模な静的ゾーンの場合、従来の DNSSEC事前署名方式を使用するほうが、パフォーマンス面でもリソース面でも有利です。TMOSのインテリジェント・アーキテクチャでは、署名済みの DNS応答を通過させることができ、ゾーンごとのハイブリッド DNSSECの導入が可能になります。秘密キーは通常、Secure Vaultという三重に暗号化されたキーストレージに保存されます。軍事レベルのセキュリティが求められる環境では、秘密キーの生成および保管用として各種 F5製品に搭載されているハードウェア FIPSカードを使用することができます。これらの FIPSカードは同じ1つの設定を共有し、FIPSキーを同期できることから、別々の場所に設置したとしても FIPSへの完全準拠が確保されます。

リアルタイムDNSSECの設定

3ステップのプロセスで簡単にリアルタイム DNSSEC署名を設定することができます。

1. キー署名キーを作成する。

2. ゾーン署名キーを作成する。

3. BIG-IP GTMが制御する適切なサブゾーンにこれらのキーを割り当てる。


TECHNICAL BRIEF

March-2010 �

最後に、手動でパブリックKSKをエクスポートし、それを次の上位のゾーンオーソリティに登録します。

Infoblox DNSSECの設定

Infobloxアプライアンスは標準 DNSSEC機能をすべてサポートしています。Infobloxの開発するツールはいずれもきわめて直感的であり、グローバル・グリッド・レベルでデフォルト設定が行えるようになっています。Infoblox管理ツールでは、ワンクリックであらゆるゾーンの DNSSECを簡単にアップグレードし、DNSSEC 応答の提供を開始することができます。最後に、手動でパブリックKSKをエクスポートし、それを次の上位のゾーンオーソリティもしくは独立したトラストアンカーに登録します。

F5と Infobloxのアーキテクチャの概要

本ソリューションの導入の際には以下の点を考慮する必要があります。

■ 権限を持つシステム

■ 設定のホスティング

■ ゾーンの更新

■ Infobloxアプライアンスのロードバランシング

■ GSLBレコードと静的なゾーンレコード間のサービス区分

■ CNAMEレコードを用いたシステム・エイリアシング

■ ゾーンサイズとレコードタイプ

本資料では以下の 3種のアーキテクチャについて取り上げています。

1. Delegation

2. Authoritative Screening


TECHNICAL BRIEF

March-2010 �

3. Authoritative Slave

Delegationはもっとも一般的でシンプルなアーキテクチャであり、DNSアーキテクチャのすべての GSLBエレメントを含む特定のサブゾーンの委任を行います。このシナリオでは、CNAMEを使って、他の名前を委任されたサブゾーンにリダイレクトします。Authoritative Screeningは洗練されたアーキテクチャであり、高度に統合されたソリューションを提供するほか、拡張性にも優れ、Infobloxアーキテクチャを保護します。Authoritative Slaveアーキテクチャでは、BIG-IP GTMで DNS要求が処理される一方で、Infobloxアプライアンスがゾーンの隠しプライマリとして機能します。本資料では、一般的な DNSアーキテクチャの説明に加えて、アーキテクチャごとに項を設け、DNSSECに特化したオプションと導入について解説しています。

Delegationアーキテクチャ

標準 DNSおよび GSLBサービスのゾーン割り当てが分かりやすく、シンプルな設定を希望する組織には、Delegationソリューションがおすすめです。ここで取り上げる例では、Infobloxアプライアンスがトップレベルゾーンの example.comを完全に管理しています。NSレコードは名前をポイントすることで、Infobloxアプライアンスの IPアドレスを間接的にポイントします。BIG-IP GTMはサブゾーンに対する権限を持ち、そのゾーン（例：gtm.example.com）へのすべてのクエリを処理します。GSLBリソースはすべてGTMゾーンのAレコードで表わされ、BIG-IP GTM上で動作するBINDネームサーバにサブゾーンレコードが格納されます。CNAMEエイリアスレコードを使って、GTMが制御するサブゾーンから、トップレベルゾーンのホスト名を参照します。また、サブゾーンを含むほとんどすべてのゾーンから CNAME参照を行うことができます。複数のサブゾーンを委任し、GTMゾーンで管理することが可能です。

www.example.com CNAME www.gtm.example.com

mail.example.com CNAME mail.gtm.example.com


TECHNICAL BRIEF

March-2010 �

CNAMEエイリアスを使ったショートカット

頻繁に参照される名前（www.example.comなど）では、CNAMEを使用することにより余計なリダイレクションや参照が生じ、遅延につながる場合があります。ショートカットを使ってサブゾーンの作成とBIG-IP GTMへの委任を行うことができます。このショートカットはサブゾーンの 1つの名前にしか対応しませんが、同じ方法でゾーンをいくつでも委任できるようになっています。サブゾーン・ショートカットによって、CNAMEのリダイレクトを行わなくても、Delegationアーキテクチャを使い続けることができます。この例では、www.example.comというサブゾーンが作成され、BIG-IP GTMに委任されるようになっています。BIG-IP GTMでのゾーン設定には、上位の example.comゾーンと同じように通常の NSレコードが含まれますが、ゾーンに登録されるホストレコードは 1つだけです。BIG-IP GTM WIPはwww.

example.comと同じように設定され、常にwww.example.comにGSLBサービスを提供します。

Delegationアーキテクチャでの DNSSEC設定

Delegationアーキテクチャを使用する場合の DNSSEC設定はきわめてシンプルです。トップレベルの標準 DNSゾーン（example.comなど）の管理と署名は Infobloxアプライアンスが担当します。Infobloxが管理する他の標準 DNSゾーンやサブゾーンもすべて同じように署名され、Infobloxが管理するゾーンのすべての標準 DNSクエリは DNSSEC 応答に対応します。GTMサブゾーンに送信されるすべての GSLBクエリは、BIG-IP GTMが各クライアントに対する最適な回答を決定した後に、TMOSによってリアルタイムで署名されます。

Delegationアーキテクチャのまとめ

Delegationアーキテクチャは導入が簡単で、DNS応答とDNSSEC応答の両方に対応します。しかし一方で、BIG-IP GTM上でもサブゾーンを設定する必要があり、一部の組織は CNAMEレコードの使用を大規模に管理するのは難しいと感じています。また、遅延の心配があるため、CNAMEレコードの使用は避けたいという組織も存在するようです。サブゾーン・ショートカットは CNAMEレコードの回避に有効ですが、汎用ソリューションとして使用することはできません。Delegationアーキテクチャは、GSLB機能を利用するゾーンとリソースの数が少なく、DNSパフォーマンス要件が緩やかな組織に適しています。

Authoritative Screeningアーキテクチャ

Authoritative Screeningはもっとも強力かつ柔軟なアーキテクチャであり、3つのソリューションが統合されています。BIG-IP GTM 10.1を搭載した Authoritative Screeningアーキテクチャを導入するには、BIG-IP® Local Traffic ManagerTMと BIG-IP GTMの両方のライセンスが必要です。BIG-IP GTM

10.2.0からは、BIG-IP GTMのライセンスだけでこの構成が動作するようになり、バージョン 10.2ではBIG-IP GTM単独でも Authoritative Screeningアーキテクチャを利用できます。

「F�と Infobloxのアプライアンスを組み合わせることで、企業はグローバル・サーバ・ロードバランシングや DNSSECの利用をあきらめることなく、権限を持つDNSインフラストラクチャを構築することができ、このことはパフォーマンスとセキュリティの面で明らかな付加価値をもたらします」

Infoblox アーキテクチャ部門バイス・プレジデント、クリケット・リュー（Cricket Liu）氏


TECHNICAL BRIEF

March-2010 �

Authoritative Screeningアーキテクチャでは、BIG-IP GTMですべての DNSクエリを受信することができ、要求を Infobloxアプライアンスのプールに分散することで大量の DNSの管理が可能になります。また、Authoritative Screeningアーキテクチャは、インテリジェントな GSLBサービスのすべてのメリットをシームレスに提供します。BIG-IP GTMリスナの IPアドレスは、委任されたサブゾーンとしてではなく、ゾーンに対する権限を持つ NSレコード内で設定される必要があります。DNSクエリを受信すると、TMOSはレコードタイプをチェックし、A、AAAA、A6、CNAMEのいずれかである場合は BIG-IP GTMに送信します。BIG-IP GTMは、FQDN名のワイド IP（WIP）リストと一致するものがないか、すべての要求と応答をチェックし、もし一致した場合は、適切な GSLB機能を実行して、要求元のクライアントに合ったIPアドレスを返します。

DNS要求がWIPリストと一致しない場合は、BIG-IP GTMはその要求を Infobloxアプライアンスのプールに転送します。要求を Infobloxアプライアンスのプールにロードバランスすることで、さらなる拡張性と安定性がもたらされ、クエリパフォーマンスの向上とDNSサービスのアップタイムの最適化につながります。

BIG-IP GTMは、TCPとUDPの両方のポート 53の標準 DNSリスナを使って設定され、SOAレコードで参照される ns1.example.comの外部 IPアドレスを使用します。バーチャルサーバの設定で、それぞれが独自の IPアドレスを持つ複数の Infobloxアプライアンスを含むプールを作成します。Infobloxアプライアンスには、内部クライアントのゾーンに対する完全な権限が与えられますが、トップレベルゾーン（example.

comなど）の外部NSレコードはすべて、F5 BIG-IPに割り当てられた外部 IPアドレスのみをポイントします。

BIG-IP GTM Screeningアーキテクチャについて分かりやすく説明するために、MXレコードが要求された場合の流れを見てみることにしましょう。BIG-IP GTMにあるのはWIPクエリを処理するためのWIPリストと設定のみであり、すべてのゾーンレコードは Infobloxアプライアンスで保持されます。要求は以下の順序でシステムを通過します。


TECHNICAL BRIEF

March-2010 10

1. TMOSが example.com のMXクエリを受信し、最初にレコードタイプをチェックします。A、AAAA、A6、CNAMEの要求のみが BIG-IP GTMに送信されます。他のレコードタイプはただちにDNSに送信されます。この例の場合、MXレコード要求であることから、TMOSは設定済みの比率ロードバランシング方式を使ってクエリを直接 Infobloxアプライアンスに送信します。

2. Infobloxアプライアンスは、example.comのMXレコードが Aレコードのmail.example.comに変換されることを示す応答を返します。

3. TMOSはその要求を BIG-IP GTMに送信し、WIPと一致するかどうかをチェックします。

4. BIG-IP GTMはWIPリストでmail.example.comと一致するものを探し、mail.example.com用の設定に従いクエリを処理します。この場合、BIG-IP GTMは IPジオロケーションを使ってクライアントにもっとも近いメールサーバを探し、最適な IPアドレスで応答します。

5. TMOSがオリジナルのMXレコード要求（mail.example.com）に応答し、BIG-IP GTMによりグローバルにロードバランスされた IPアドレスを使ってAレコードの回答を書き換えます。

6. DNSSECが要求されている場合、応答は TMOSで署名された後に、要求元の LDNSに送信されます。

最初のレコードタイプがAレコードである場合、要求は次の順序で処理されます。

1. ftp.example.comに対する初期クエリを送信します。TMOSは最初にレコードタイプをチェックします。この場合 Aレコードであることから、TMOSは要求を BIG-IP GTMに転送してWIPリストと照合します。

2. ftp.example.comに一致するWIPがある場合、BIG-IP GTMが処理を担当し、応答を TMOSに送信します。この例では、ftp.example.comが一致しないため、要求は DNSに送信されます。


TECHNICAL BRIEF

March-2010 11

3. 要求がロードバランスされ、MXレコードの場合と同じように Infobloxアプライアンスで処理されます。

4. InfobloxからAレコードの server.example.comを含む CNAME応答が返されると、TMOSはその応答を BIG-IP GTMに送信して、server.example.comに一致するWIPがないかどうかチェックします。

5. server.example.comがWIPと一致すると、BIG-IP GTMはその要求を処理し、応答を TMOSに送信します。

Authoritative Screeningアーキテクチャの DNSSECオプション

TMOSでは、すべてのゾーンの DNSSEC署名をオンデマンドでリアルタイムに実行することができます。BIG-IP GTM設定において動的な GSLB名を含むあらゆるゾーンが、TMOSによりリアルタイムで署名されるようになっています。

BIG-IP GTMで設定されたWIP 名が含まれない標準 DNSゾーンがある場合、ネイティブの Infoblox

DNSSEC機能を使ってそれらのゾーンを署名することが可能です。このようなハイブリッド構成において、BIG-IP GTMは DNSSEC署名された応答を検出し、変更や再署名を行うことなく要求元の LDNSサーバにそれを転送します。このハイブリッド構成では、Infobloxにより署名されるゾーン用として異なる KSKとZSKが必要になります。

高度な IP Anycast設置

このアーキテクチャでは、1つの外部 IPアドレスを使って、複数の F5製品を世界中のさまざまなロケーションに導入することが可能です。この機能は一般的に「IP Anycast」と呼ばれていますが、F5では「ルート・ヘルス・インジェクション（RHI）」という名称を採用しています。各 F5製品が同じ IPアドレスをネクストホップルータに示し、ルーティングシステムが LDNSサーバからの要求をもっとも近い BIG-IP GTMに転送します。IP Anycastとルーティングシステムを使ってDNSクエリを地理的に分散することにより、DNSの遅延が軽減され、一定レベルの DNSサービス拒否（DoS）防御が実現します。

Authoritative Screeningアーキテクチャのまとめ

Authoritative Screeningアーキテクチャは、Aレコードに変換されるあらゆるレコードタイプのインテリジェント DNSとグローバル・サーバ・ロードバランシングを可能にします。それぞれの長所を活かしたアーキテクチャであり、Infobloxアプライアンスがすべての DNSレコードのサポートと管理を担当しつつ、同時に特定のサービスやサイトに対してロードバランシングとインテリジェント DNSの機能を提供できるようになっています。ロードバランスされた名前のゾーンが指定されることはなく、CNAMEリダイレクトを使用する必要もありません。BIG-IP GTMは Infobloxアプライアンスに送信される DNSトラフィックをチェックし、BIG-IP GTM設定で指定された名前に一致した要求と応答のみを遮断します。BIG-IP GTMがGSLBに特化したWIP設定情報の管理を担当するのに対して、Infobloxアプライアンスはすべてのゾーンレコードを保持し、管理します。DNSSECの実装法は複数ありますが、簡単なのはすべてのゾーンに対してリアルタイム DNSSEC署名を利用するという方法です。また、一部のゾーンの署名と管理を Infobloxアプライアンスが担うハイブリッド構成という選択肢もあります。IP Anycast機能を導入すれば、パフォーマンスの向上とDNS DoS防御を可能にする高度なアーキテクチャが実現します。設定が面倒なことを除けば、Authoritative Screeningアーキテクチャは多くのメリットを提供し、リスクもほとんどありません。


TECHNICAL BRIEF

March-2010 12

Authoritative Slaveアーキテクチャ

Authoritative Screeningとよく似ており、どちらのアーキテクチャも BIG-IP GTMを外部の権威ネームサーバとして導入します。主な違いは、Authoritative Slaveではすべての DNS要求が BIG-IP GTMで処理され、ロードバランシングや Infobloxアプライアンスへの転送は行われないという点です。BIG-IP

GTMには標準 BINDネームサーバが搭載されており、これが BIG-IP GTMモジュールで処理されないクエリや、外部ネームサーバにロードバランスされないクエリに回答しようとします。Authoritative Slaveアーキテクチャでは、ローカルの BINDネームサーバがすべての標準 DNSクエリに回答し、Infobloxプライマリ・マスタ・サーバのスレーブとして振る舞います。標準ゾーン転送により、ゾーン設定がBIG-IP GTM BINDネームサーバにコピーされます。Authoritative Screeningアーキテクチャと同じようにWIP照合が行われますが、一致しない名前はローカルの BINDネームサーバで処理され、Infobloxアプライアンスに転送されることはありません。

Authoritative Slaveアーキテクチャの DNSSECオプション

クライアントが DNSSEC認証された応答を要求した場合、TMOSは DNSSEC署名をオンデマンドでリアルタイムに実行するようになっています。設定手順は、リアルタイム DNSSECの設定の項で説明したものとまったく同じです。GSLB WIP名を含むあらゆるゾーンで、TMOSがリアルタイムの DNSSEC署名を実行する必要があります。

BIG-IP GTMで設定されたWIP 名が含まれない標準 DNSゾーンがある場合、ネイティブの Infoblox

DNSSEC 機能を使ってそれらのゾーンを署名することが可能です。このようなハイブリッド構成では、Infobloxにより事前署名された DNSSECゾーンは BIG-IP GTMに転送され、通常のゾーンファイルとして使用されます。TMOSは DNSSEC署名された応答を検出し、変更や再署名を行うことなく、要求元のLDNSサーバにそれを転送します。このハイブリッド構成では、Infobloxにより署名されるゾーン用として異なる KSKと ZSKが必要になります。


TECHNICAL BRIEF

March-2010 1�

Authoritative Slaveアーキテクチャのまとめ

Authoritative Slaveは Authoritative Screeningによく似ていますが、Aレコードに変換されるあらゆるレコードタイプのインテリジェント DNSとGSLB機能を使用するという点が異なります。このソリューションは Authoritative Screeningソリューションの一部のメリットを提供するほか、リアルタイムの純粋な DNSSEC設定か、一部のゾーンの署名と管理を Infobloxアプライアンスが担うハイブリッド構成のいずれかを選択できるようになっています。Authoritative Slaveでは DNSクエリが複数の高性能 Infobloxアプライアンスに分散されることがないため、標準 BINDレコードの高性能応答には対応しません。DNSクエリの大半を GSLBリソースが処理し、他のレコードタイプとわずかな標準 DNSクエリを処理するためだけに BINDが使われるという場合に最適なソリューションです。

アーキテクチャの選択

最終的には、組織ごとの要件、既存のインフラ、トラフィックパターン、アプリケーション、成長計画、政策などによって、どのアーキテクチャから始めるべきかが決まってきます。アーキテクチャごとに考えられるバリエーションを以下にいくつか紹介します。

■ これまで GSLBを使ったことがなく、大量の DNS要求の処理に対応する複雑な Infoblox DNSアーキテクチャがあるという場合は、Delegationアーキテクチャから始めることをおすすめします。この方法ならば、混乱を最小限に抑えつつ、インテリジェント GSLBサービスを使い始めることができます。

■ 社内の政策やポリシーによって、既存のAuthoritativeアーキテクチャをいっさい変更できないという場合、しばしば Delegationが唯一の選択肢となります。

■ 大量の DNS要求を処理しなければならず、DNS DoS攻撃への対応とDNSSECの導入が必要で、さらにCNAMEとサブゾーンの使用を回避したいと考えている大規模な組織の場合、要件を満たす選択肢としてAuthoritative Screeningアーキテクチャが考えられます。

■ ゾーンとレコードの数が少なく、パフォーマンス要件とGSLB要件が比較的緩やかな小規模組織の場合、Infobloxアプライアンスを使って管理を統合・合理化するAuthoritative Slaveアーキテクチャを検討することを推奨します。

まとめ

F5と Infobloxによるジョイント・ソリューションは、あらゆる組織の要件を満たすための、独自の優位性と機能を提供します。DNSの脆弱性が明らかになり、DNS攻撃のニュースに注目が集まる中、従来の DNSシステムをより高い拡張性と安定性・安全性を備えたものに改善することが求められています。DNSSECを使えば、少なくとも一部の問題を解決することはできますが、一方で導入が難しいという欠点もあります。F5と Infobloxが提供する新しい機能により、導入を阻んでいた障壁が取り除かれ、あらゆる組織が容易にインフラストラクチャを保護できるようになります。両社による複合機能は、優れた管理機能、柔軟でインテリジェントなグローバル・サーバ・ロードバランシング、高性能でスケーラブルな DNS、すべてのゾーンをカバーするDNSSEC署名からなる完全な DNSソリューションの導入を可能にします。

東京本社〒107-0052 東京都港区赤坂4-15-1 赤坂ガーデンシティ19階TEL 03-5114-3210 FAX 03-5114-3201

www.f5networks.co.jp/fc/

西日本支社〒530-0017 大阪市北区角田町 8-47 阪急グランドビル 20階TEL 06-7711-1655 FAX 06-7711-1501

© 2010 F� Networks, Inc. All rights reserved.F�、F� Networks、F�のロゴ、BIG-IP、FirePass、および iControlは、米国および他の国における F� Networks, Inc.の商標または登録商標です。本文中に記載されている製品名、および社名はそれぞれ各社の商標、または登録商標です。

これらの仕様はすべて予告なく変更される場合があります。本発行物の記載内容に誤りがあった場合、あるいは記載内容を更新する義務が生じた場合も、F�ネットワークスは一切責任を負いません。F�ネットワークスは、本発行物を予告なく変更、修正、転載または改訂する権利を有します。

TECHNICAL BRIEF

2010 年 �月 A

関連資料

DNSとDNSSECに関する詳しい情報は以下を参照してください。

DNS and BIND, 5th Edition, By Cricket Liu, Paul Albitz

Free DNS Tools at MX Toolbox

DNSSEC Deployment Initiative

DNSSEC News and Announcements

National Institute of Standards and Technology

F5 Infoblox...

Documents

Transcript of F5 Infoblox...