第3章 Ansible Playbook を使用した IdM DNS ゾーンの管理
RHEL Identity Management (IdM) 管理者は、ansible-freeipa
パッケージで利用可能な dnszone
モジュールを使用して、IdM DNS ゾーンの動作を管理できます。
前提条件
- DNS サービスが IdM サーバーにインストールされている。Ansible を使用して、統合 DNS を使用する IdM サーバーをインストールする方法の詳細は、Ansible Playbook を使用した Identity Management サーバーのインストール を参照してください。
3.1. サポート対象の DNS ゾーンタイプ
RHEL Identity Management (IdM) は、プライマリー ゾーンと 正引き ゾーンの 2 種類の DNS ゾーンをサポートしています。ここでは、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 サーバー (別称: フォワーダー) は、クエリーに対して権威がある場合と、ない場合があります。
例3.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 ドメインコントローラーに転送されます。