小森 博司氏 コンパック コンピュータ カスタマーサービス推進本部
第二カスタマーサポート本部 第二ナレッジセンター
|
|
図1 IPアドレスの動的登録がネックになった A社は，IPアドレスの逆引き機能を維持したまま，Active DirectoryでDNSサーバーへの動的更新をかけたかった。しかし，Active Directory導入以前のネットワークは，サブドメインのDNSサーバーにクラスCアドレスの逆引き情報を管理させていたため逆引き情報の動的更新ができず，Active Directoryの導入が難しかった。これは，逆引き情報の更新が，「a.0.168.192.in-addr- arpa.」ゾーンではなく，「0.168.192.in-addr-arpa.」ゾーンに対して実行されてしまうのが原因だ。 |
逆引き情報は最上位で動的更新
A社のようなクラスレスIPアドレスを使ったサブネット化は，IPv4アドレスの枯渇問題などから，一般的な手法である。よく似た例としては，OCNやODNなどのインターネット接続サービスもある。一つのクラスCアドレス空間を，企業は複数部署ごとにサブネット化し，プロバイダは複数企業ごとにサブネット化しているわけである。A社のネットワークは，クラスCのアドレスを，64個のIPアドレスを持つ4個のサブネットに分けている。4個のサブネットは，それぞれ「192.168. 0.0/26」，「192.168.0.64/26」，「192. 168.0.128/26」，「192.168.0.192/26」である（図1[拡大表示]）。
「192.168.0.2」を逆引きする際は，まずDNSサーバー「D」に問い合わせる。DNSサーバーDは，最初の3オクテットで示される「192.168.0/24」のDNSサーバー，すなわち「0.168. 192.in-addr.arpa.」ゾーンを管理するDNSサーバー「E」に問い合わせる。すると，「2.0.168.192. in-addr. arpa.」が「2.a.0.168.192.in- addr.arpa.」の別名であることと，「a.0.168.192.in- addr.arpa.」のDNSサーバー「F」のアドレスを知る。DNSサーバーDはDNSサーバーFに対して，「2.a.0.168. 192.in-addr.arpa.」のFQDNを問い合わせて結果を得る。
|
|
図2 逆引きゾーンの管理を一元化して対処した A社は，逆引き情報の動的更新機能が必要だったため，それまでサブドメインごとに権限委任していた逆引きゾーンの管理を，全クライアントのオクテット境界となる0.168.192.in-addr-arpa.ゾーンのDNSサーバーに一元化した。これにより，Active Directory使用時の逆引き情報の動的更新を可能にした。正引き情報に関しては以前と同じサブドメインごとのDNSサーバーでも問題なく動的に更新できるが，最終的には混乱を避けるため逆引き同様に一元化。A社では現在，DHCPの採用を検討中だ。 |
そこでA社は，サブネットごとのDNSサーバーではなく，ドメイン階層最上位のDNSサーバーで動的更新を許可し，社内の全ホストの逆引きゾーンを持たせることにして解決した（図2[拡大表示]）。逆引き情報の管理をサブドメインのDNSサーバーに任せていた従来のネットワークの構成を変更したのである。サブネットごとの正引きゾーンは，図2のように今まで通りでも構わなかったが，最終的には混乱を避けるために逆引き同様に最上位のDNSサーバーに管理権限を持たせた。
DNSの設定変えホスト名を強引に登録
逆引き情報の動的更新が可能になったが，まだ問題は残っていた。WindowsNTドメインで使っていたホスト名をDNSサーバー「BIND」へ動的に登録する際にエラーが出て登録できなかったのだ。原因は，Active Directoryのドメイン・コントローラが，本来のDNSではホスト名として使えない文字「_」（アンダー・スコア）を動的に登録しようとしていたことである。
しかし，Active Directoryを動作させるためにはどうしても，ホスト名「gc._msdcs」のドメイン名にIPアドレスをマッピングするAレコードをDNSに登録する必要があった。gc._ msdcsのIPアドレスを引けないと，グローバル・カタログ・サーバーを見つけられないからである。
そこでA社では，BIND 8の設定ファイル「named.conf」を変更し，各ゾーンのデータベース設定において，名前のチェック・レベル「check- names」を「warn」や「ignore」に落として回避した。これにより，gc._msdcsのAレコードが登録されるようになった。
