第33章 DNS の管理

Identity Management サーバーは統合 DNS サービスなしでインストールすることが可能なので、外部 DNS サービスを使用したり、DNS が設定された状態で使用することが可能です。詳細は、「IdM サーバーのインストール: はじめに」 および 「統合 DNS 使用の判断」 を参照してください。
DNS サービスがドメイン内で設定される場合、IdM では管理者に多大な柔軟性と DNS 設定に関する制御がもたらされます。たとえば、ホストエントリー、場所、レコードなどのドメインの DNS エントリーをネイティブの IdM ツールで管理したり、クライアントが自身の DNS レコードを動的に更新したりできるようになります。
BIND と IdM ではほとんどの設定オプションが同じ方法で機能することから、BIND バージョン 9.9 で利用可能なドキュメント資料およびチュートリアルは IdM DNS に適用できます。本章では主に、BIND と IdM の注意すべき違いについて説明します。

33.1. Identity Management における BIND

IdM は、BIND DNS サーバーのバージョン 9.9 をデータ複製に使用する LDAP データベースおよび、GSS-TSIG プロトコルを使用した DNS 更新署名用に Kerberos と統合します。[3] これにより、IdM ツールを使用した DNS 管理が可能になり、同時に回復性が高まります。これは、IdM と統合された DNS サーバーは複数のマスター操作をサポートするので、IdM 統合の DNS サーバーはすべて、単一障害点を持つことなく、クライアントからの DNS 更新を受け付けることが可能になるからです。
デフォルトの IdM DNS 設定は、公開インターネットからアクセスできない内部ネットワークに適しています。IdM DNS サーバーに公開インターネットからアクセスできる場合は、Red Hat Enterprise Linux ネットワークガイド の説明にあるように、通常のセキュリティー機能を BIND に適用することを Red Hat では推奨しています。

注記

IdM 統合の BIND を chroot 環境内で実行することはできません。
IdM 統合の BIND は、bind-dyndb-ldap プラグインを使って Directory Server と通信します。IdM は BIND 向けに /etc/named.conf ファイル内に dynamic-db 設定セクションを作成します。これは、BIND named-pkcs11 サービス用の bind-dyndb-ldap プラグインを設定するものです。
標準の BIND と IdM DNS との最も大きな違いは、IdM は DNS 情報を LDAP エントリーとして保存するという点です。ドメイン名はそれぞれ LDAP エントリーとして示され、リソースレコードはすべて LDAP エントリーの LDAP 属性として保存されます。たとえば、以下の client1.example.com. ドメイン名には 3 つの A レコードと AAAA レコードが 1 つ含まれています。
dn: idnsname=client1,idnsname=example.com.,cn=dns,dc=idm,dc=example,dc=com
objectclass: top
objectclass: idnsrecord
idnsname: client1
Arecord: 192.0.2.1
Arecord: 192.0.2.2
Arecord: 192.0.2.3
AAAArecord: 2001:DB8::ABCD

重要

DNS データや BIND 設定を編集する場合には、常に本章記載の IdM ツールを使用してください。


[3] GSS-TSIG についての詳細は、RFC 3545 を参照。