第28章 Ansible Playbook を使用した IdM DNS ゾーンの管理
Identity Management (IdM) 管理者は、ansible-freeipa パッケージに含まれる dnszone モジュールを使用して IdM DNS ゾーンの動作を管理できます。
前提条件
- DNS サービスが IdM サーバーにインストールされている。Red Hat Ansible Engine を使用して、統合 DNS のある IdM サーバーをインストールする方法は、Ansible Playbook を使用した Identity Management サーバーのインストール を参照してください。
28.1. サポート対象の DNS ゾーンタイプ
Identity Management (IdM) は、2 種類の DNS ゾーン (primary および forward) をサポートします。ここでは、DNS 転送のシナリオ例を含め、2 種類のゾーンについて説明します。
本ガイドでは、ゾーンタイプには BIND の用語を使用し、Microsoft Windows DNS で使用する用語とは異なります。BIND のプライマリーゾーンは、Microsoft Windows DNS の 正引きルックアップゾーン と 逆引きルックアップゾーン と同じ目的で使用されます。BIND の正引きゾーンは、Microsoft Windows DNS の 条件付きフォワーダー と同じ目的で使用されます。
- プライマリー DNS ゾーン
プライマリー DNS ゾーンには、権威 DNS データが含まれ、DNS を動的に更新できます。この動作は、標準 BIND 設定の
type master設定と同じです。プライマリーゾーンは、ipa dnszone-*コマンドを使用して管理できます。標準 DNS ルールに準拠するには、プライマリーゾーンすべてに
start of authority(SOA) とnameserver(NS) レコードを含める必要があります。IdM では、DNS ゾーンの作成時にこれらのレコードが自動的に生成されますが、NS レコードを親ゾーンに手動でコピーして適切な委譲を作成する必要があります。標準の BIND の動作に合わせて、権威サーバーではない名前のクエリーは、他の DNS サーバーに転送されます。DNS サーバー (別称: フォワーダー) は、クエリーに対して権威がある場合と、ない場合があります。
例28.1 DNS 転送のシナリオ例
IdM サーバーには
test.example.プライマリーゾーンが含まれています。このゾーンには、sub.test.example.名前の NS 委譲レコードが含まれます。さらに、test.example.ゾーンは、sub.text.exampleサブゾーンのフォワーダー IP アドレス192.0.2.254で設定されます。クライアントが
nonexistent.test.example.の名前をクエリーすると、NXDomainの応答を受け取りますが、IdM サーバーはこの名前に対して権威があるため、転送は発生しません。反対に、
host1.sub.test.example.の名前をクエリーすると、IdM サーバーはこの名前に対して権威がないので、設定済みのフォワーダー (192.0.2.254) に転送されます。- 正引き DNS ゾーン
IdM の観点からは、正引き DNS ゾーンには権威データは含まれません。実際、正引きのゾーンには、通常以下情報 2 つのみが含まれます。
- ドメイン名
- ドメインに関連付けられた DNS サーバーの IP アドレス
定義済みのドメインに所属する名前のクエリーはすべて、指定の IP アドレスに転送されます。この動作は、標準 BIND 設定の type forward 設定と同じです。正引きゾーンは、ipa dnsforwardzone-* コマンドを使用して管理できます。
正引き DNS ゾーンは、IdM-Active Directory (AD) 信頼のコンテキストで特に便利です。IdM DNS サーバーが idm.example.com ゾーンに対して、AD DNS サーバーが ad.example.com ゾーンに対して権威がある場合には、ad.example.com が idm.example.com プライマリーゾーンの DNS 正引きゾーンになります。つまり、IP アドレスが somehost.ad.example.com の IdM クライアントからクエリーが送信されると、ad.example.com IdM DNS 正引きゾーンに指定の AD ドメインコントローラーに転送されます。
