|
|
||
|
|
セカンダリサーバを構築する(CentOS5)BIND、つまりDNSです。その役割に今更説明は必要ないでしょう。DNSには基本的に三種類のタイプがあります。 ・プライマリDNSサーバ ・セカンダリDNSサーバ ・キャッシュオンリーサーバ これらはゾーン単位でなら同居させることが可能です。 ※ゾーン、つまりそのサーバが管理しているドメインの一つ一つの範囲のことです。 ファイルパスで言えば、個々のエントリをファイルとするなら、ゾーンはフォルダに相当するのでしょうか。 言うまでもありませんがプライマリサーバがすでにあることが条件です。 それは自分で構築した自社サーバかもしれませんし、ISPからゾーン転送を受けているサーバかもしれません。 しかし最近はプライマリサーバ側でゾーン転送可能なサーバが制限されていることも事実です。 プライマリサーバの構築については、別項「プライマリサーバを構築する」までは終了しているものとします。 ・CentOSのDNSクライアントの設定 ・プライマリサーバ側のファイアウォールの開放 ・ゾーン転送試験 ・BINDのインストール ・named.confの編集 ・ディレクトリの書き込み権を確認する ・ゾーン転送を確認する ・セカンダリサーバのファイアウォールの開放 ・試験 ・ゾーン転送の制限 CentOSのDNSクライアントの指定OSのDNSクライアントの設定と。DNSサーバの動作は関係ありません。ですがとりあえず、混乱が無いように指定の仕方を紹介しておきます。 GUI上の設定  コマンドラインからの設定 /etc/resolv.confを編集（各環境のDNS、もしくはDNSである自分自身） nameserver 192.168.1.254 search localdomain  プライマリサーバ側のファイアウォールの開放デフォルトではプライマリサーバのゾーン転送は制限されておらず、万人に許可されています。しかしファイアウォールで遮断されています。 ファイアウォールが有効なら、おそらくTCPの53番は閉じられているでしょう。 プライマリサーバで 問い合わせに使用するUDPの53に加え、ゾーン転送に使用するTCPの53を開放します。 GUIかコマンドラインか、いずれかで開放します。 GUIからの開放  コマンドラインからの開放 /etc/sysconfig/iptablesへ、udp 53とtcpの53を追加します。  ファイルを編集後、iptablesを再起動します。 #service iptables restart ゾーン転送試験LAN内の端末から、nslookupでゾーン情報の取得を試みて、プライマリサーバからゾーン転送が可能か試験します。#nslookup >server 192.168.1.99 >ls -d example.com [[192.168.1.99]] example.com. SOA bind-sv.example.com root.example.com. (2011070901 3600 300 360000 86400) example.com. NS bind-sv.example.com bind-sv A 192.168.1.99 host1 A 192.168.1.100 example.com. SOA bind-sv.example.com root.example.com. (2011070901 3600 300 360000 86400) 無事、回答が帰ってくれば成功です。 タイムアウトする場合は、ファイアウォールで53番が開放されていない、すでにゾーン転送の制限がかかっていることが考えられます。 BINDのインストールここではBINDはchrootしたものを使用します。最近のCentOSやFedoreなどは、セキュリティ上の考えからインターネット公開に適したchroot版BINDを推奨しているようです。普通のBINDを使用した場合でも、ファイルパスをわずかに読み替えるだけなので、参考になると思います。 ※chroot BINDが使用するファイルの構成を/（ルート）から考えて、/var/named/chroot配下に再配置した仕組み。 例 /etc/named.conf → /var/named/chroot/etc/named.conf BINDにとってchrootディレクトリ以上へは辿れなくなることで、侵入者がBINDから侵入してもシステムへアクセスできなくなります。 一旦chrootをすると、OS上からそれを解除する方法はありません。 インストール自体は相変わらずです。yumから、chrootタイプのbindをインストールします。 #yum install bind-chroot この時点でインストールされたバージョンは「bind-9.3.6-16.P1.el5」でした。 実運用、とくに公開する場合BINDの最新バージョンを使用するほうが良いです。 なおセキュリティを重視するインターネットサーバ、攻撃が予想されやすい大規模環境、非常にスキルの高いエンジニアなどはソースコンパイルにこだわったりします。 細かな調整を加えることが可能なこと、伝統、単に思想の問題など理由はさまざまです。 named.confの編集インストールが完了すれば、named.confファイルを作成します。Fedoreなら5以降、CentOSなら3以降、named.confはデフォルトでは添付されなくなり、自分で記述する必要があります。 named.confにはどんなゾーンを、どんな性質（プライマリ、セカンダリ、キャッシュオンリー）で、どんなファイル名で運用するかということが記述されています。他にもBINDの動作について不用と言えるほど細かい動作を指定できます。 ここではセカンダリサーバとして動作するため、必要最低限の記述のみ行っています。 chrootを採用しているので、named.confのパスは以下になります。 セカンダリサーバ側 /var/named/chroot/etc/named.conf options { directory "/var/named"; // forwarders { DNS-Addr;}; // forward only; }; //正引きゾーンの定義 zone "example.com" { type slave; masters { 192.168.1.99; }; file "slaves/example.com.zone"; }; //逆引きゾーンの定義 zone "1.168.192.in-addr.arpa" IN { type slave; masters { 192.168.1.99; }; file "slaves/example.com.rev"; }; //インターネットルートヒント //zone "." { // type hint; // file "named.ca"; // allow-update { none; }; //}; ディレクトリの書き込み権を確認するデフォルトで用意されているslavesディレクトリにはnamedアカウントに対して書き込み権が与えられています。しかしディレクトリを作りなおしたなどの理由で、slavesディレクトリにnamedによる書き込み権が無い場合、ゾーン転送に失敗します。アクセス権を確認しましょう。 もしslavesディレクトリの所有者がrootなどになっている場合は、所有権をnamedに与えます。 #chown named /var/named/chroot/var/named/slave/ #chgrp named /var/named/chroot/var/named/slave/ ゾーン転送を確認するサービスの起動時にゾーン転送が発生します。次回のゾーン転送は、SOAレコードに記述されたReflesh秒後になります。#service named restart #chkconfig named on /var/named/chroot/var/named/slaves/ディレクトリ配下にファイルができているか確認します。 失敗する場合は １．named.confの保存ディレクトリパスの指定、保存ファイルパスの指定を確認します。 ２．プライマリサーバ側でTCP53が許可されているか確認します。 ３．プライマリサーバ側でallow-transferが設定されていないか確認する。 セカンダリサーバのファイアウォールの解放最後に、LAN内の端末からアクセスを受け付けられウように、ファイアウォールを開放します。試験の前に、ファイアウォールを開放します。ファイアウォールが有効なら、おそらくUDPの53番は閉じられているでしょう。 自身はともかく、LAN内の端末からはアクセスできません。 GUIかコマンドラインか、いずれかで開放します。 GUIからの開放  コマンドラインからの開放 /etc/sysconfig/iptablesへ、udp 53の行を追加します。  ファイルを編集後、iptablesを再起動します。 #service iptables restart 試験LAN内の端末からnslookupでセカンダリサーバへ接続し、名前解決の試験をしてみます。#nslookup >server 192.168.1.100 >host1.example.com Server: [192.168.1.100] Address: 192.168.1.100 Name; host1.example.com Address: 192.168.1.100 >set type=ptr >192.168.1.100 Server: [192.168.1.99] Address: 192.168.1.99 100.1.168.192.in-addr.arpa name = host1.example.com 1.168.192.in-addr.arpa nameserver = bind-sv.example.com bind-sv.example.com internet address = 192.168.1.99 無事、セカンダリから回答が帰ってくれば成功です。 タイムアウトする場合は、ファイアウォールで53番が開放されていない、named,confやゾーンファイルの記述が間違っていることが考えられます。 細かい調整を加える場合は、別項の「BINDを調整する」を参照してください。 ゾーン転送の制限かつてはゾーン情報のぶっこぬきなどと呼ばれ、誰でもゾーン転送が可能でした。ですがサーバのリスト一覧を読まれるのはセキュリティ上好ましくないということで、現在はゾーン転送を制限するのが常識です。プライマリサーバとセカンダリサーバのnamed.confに、以下太字のエントリを追加します。 プライマリサーバ側 /var/named/chroot/etc/named.conf options { directory "/var/named"; // forwarders { DNS-Addr;}; // forward only; }; //正引きゾーンの定義 zone "example.com" { type master; file "example.com.zone"; allow-transfer { secondary-DNSAddr; }; allow-update {none;} ; }; //逆引きゾーンの定義 zone "1.168.192.in-addr.arpa" IN { type master; file "example.com.rev"; allow-transfer { secondary-DNSAddr; }; allow-update {none;} ; }; 同様に、セカンダリサーバ側のコンフィグにもゾーン転送を禁止する設定を加えます。 （ファイアウォールでTCP53が閉じていれば、ゾーン転送は行われません。が、念のため） セカンダリサーバ側 /var/named/chroot/etc/named.conf options { directory "/var/named"; // forwarders { DNS-Addr;}; // forward only; }; //正引きゾーンの定義 zone "example.com" { type master; file "example.com.zone"; allow-transfer { none; }; allow-update {none;} ; }; //逆引きゾーンの定義 zone "1.168.192.in-addr.arpa" IN { type master; file "example.com.rev"; allow-transfer { none; }; allow-update {none;} ; }; 再度LAN内のクライアントからnslookupのゾーン転送試験を行い、ゾーン転送が拒否されるかを確認します。 #nslookup >server 192.168.1.99 >ls -d example.com [bind-sv.example.com] *** Can't list domain example.com: Query refused |
|
 |