Since 12/1/2007
Home > Linux > CentOS5 > DNSサーバーの構築[BIND] > 内部向けキャッシュサーバー

CentOS5 DNSサーバーの構築[BIND] 内部向けキャッシュサーバー - itochif.com

内部からの問い合わせに対して、外部のDNSに反復問い合わせを行うキャッシュサーバーを構築します。
BINDのインストールが完了している前提で書きます。

富士通

設定ファイルの編集

BINDのインストールで作成した設定ファイルの中身を記述します。

# vi /var/named/chroot/etc/named.conf
------------------------------ 次の行からnamed.confの中身
//アクセスを許可するIPアドレスやネットワークを記述する
acl my-network {
	192.168.10.0/24;	//反復問い合わせを許可するネットワーク
};

options {
	recursion		yes;			// 再帰クエリを行う
	version			"unknown";		// バージョン情報を返さない
	directory		"/var/named";		// ディレクトリの設定
	//反復問い合わせを許可するネットワークやIPアドレス
	allow-query {
		localhost;	//自分自身からの問い合わせ
		my-network;	//上のでつけた問い合わせを許可するネットワークを記載したacl名
	};
};

//ルートサーバへのヒント情報
zone "." {
	type			hint;
	file			"named.root";		// ルートサーバーの情報を記載したファイル
};

------------------------------ named.conf終了
図1.bindの設定ファイルの例

ルートサーバーの情報を記載したファイルの取得

次は、このDNSサーバーがまだキャッシュしていないドメインの情報を反復問い合わせするための、一番最初の問い合わせを行うルートサーバーの情報を記載したファイルを取得します。chroot環境(ルートが/var/named/chrootになる)で、named.conf内でdirectoryの指定を/var/namedとしてあり、ルートヒントのファイル指定をnamed.rootとしたため、取得したファイルを/var/named/chroot/var/named/named.rootとして保存します。

# modprobe ip_conntrack_ftp #PASV モードのftpでファイルを取得するため、ip_conntrack_ftpモジュールをロード
# wget ftp://ftp.internic.net/domain/named.root
--00:00:00--  ftp://ftp.internic.net/domain/named.root
           => `named.root'
ftp.internic.net をDNSに問いあわせています... 208.77.188.26
ftp.internic.net|208.77.188.26|:21 に接続しています... 接続しました。
anonymous としてログインしています... ログインしました!
==> SYST ... 完了しました。    ==> PWD ... 完了しました。
==> TYPE I ... 完了しました。  ==> CWD /domain ... 完了しました。
==> SIZE named.root ... 2878
==> PASV ... 完了しました。    ==> RETR named.root ... 完了しました。
長さ: 2878 (2.8K)

100%[=======================================>] 2,878       --.-K/s   in 0s

00:00:00 (43.1 MB/s) - `named.root' を保存しました [2878]

# modprobe -r ip_conntrack_ftp #ip_conntrack_ftpモジュールの役目は終わったためアンロード
# mv named.root /var/named/chroot/var/named/named.root
# chown -R named.named /var/named/chroot/var/named/
# /sbin/service named start
named を起動中:                                            [失敗]
図2.最新のnamed.rootの取得とBINDの起動(失敗)

富士通

BINDの起動が失敗した原因を探る

上でBINDの起動を試みたときに失敗しているのがわかります。
=========================================================
named を起動中: [失敗]
=========================================================
起動が失敗した原因を探ります。
まずはログを確認します。

# tail /var/log/messages
Mar 13 16:00:00 www named[3561]: starting BIND 9.3.3rc2 -u named -t /var/named/chroot
Mar 13 16:00:00 www named[3561]: found 1 CPU, using 1 worker thread
Mar 13 16:00:00 www named[3561]: loading configuration from '/etc/named.conf'
Mar 13 16:00:00 www named[3561]: listening on IPv4 interface lo, 127.0.0.1#53
Mar 13 16:00:00 www named[3561]: listening on IPv4 interface eth0, 192.168.10.2#53
Mar 13 16:00:00 www named[3561]: could not configure root hints from 'named.root': permission denied
Mar 13 16:00:00 www named[3561]: loading configuration: permission denied
Mar 13 16:00:00 www named[3561]: exiting (due to fatal error)
図3.BINDの起動失敗時のログ(抜粋)

赤字の部分により、アクセス権の不足による起動失敗という事がわかるので、ファイルのパーミッションを確認します。

# ls -la /var/named/chroot/var/named/named.root
-rw-r--r-- 1 named named 2878  3月 13 00:43 /var/named/chroot/var/named/named.root
図4.named.rootのパーミッション

BIND起動ユーザーのnamedの権限は読み取りと書き込みが許可されているため、パーミッションに問題はない事がわかりました。他に権限不足のエラーがでる原因となる、強制アクセス制御の機能(SELinux)のログを調べます。
※とりあえずSELinuxをpermissiveモードにして動くかどうかを試しましょうというアドバイスをよく見かけますが、私は推奨しません。運用に入っているシステムのセキュリティ機能を一時的にでも無効にするのは危険だと考えています。また、SELinuxが原因かどうかはSELinuxのログで拒否されているかどうかで判断はつきます。(検証環境があればpermissiveモードで一連の流れで拒否されたログを取得した方が早くて良いと思います)

# grep denied /var/log/audit/audit.log
type=AVC msg=audit(1205340000.000:10): avc:  denied  { read } for  pid=3562 comm="named" name="named.root" dev=dm-0 ino=12222525 scontext=user_u:system_r:named_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file

図5.auditdのログからSELinuxで拒否されたもの表示

named.rootへのアクセス拒否のログがあるので、SELinuxが起動失敗の原因の一要因である事がわかりました。

GIGABYTE製 ハイエンドデスクトップ 468x60

SELinuxの設定を変更する

まず、上のログの意味を確認します。ログの中の重要な要素は以下になります。

  • 拒否された動作は読み取り(denied { read })
  • 拒否されたプロセスはnamed(comm="named")
  • named.rootファイルへのアクセスが拒否された(name="named.root"/tclass=file)
  • namedはnamed_tドメインで動作していた(scontext=user_u:system_r:named_t:s0)
  • named.rootはuser_home_tタイプだった(user_home_t)

上記をまとめると、「named.rootファイルがuser_home_tタイプなのでnamed_tドメインではファイルの読み込み許可がありません。」となります。named.rootはBINDの設定ファイルの一部なので[named_conf_t]タイプを付与します。

# ls -Z /var/named/chroot/var/named/ #セキュリティコンテキストの表示
drwxrwx---  named named system_u:object_r:named_cache_t  data
-rw-r--r--  named named user_u:object_r:user_home_t      named.root
drwxrwx---  named named system_u:object_r:named_cache_t  slaves
# semanage fcontext -a -t named_conf_t "/var/named/chroot/var/named/named.root" #ファイルコンテキストに設定を追加する
# restorecon -R /var/named/ #設定を反映させる
# ls -Z /var/named/chroot/var/named/ #セキュリティコンテキストの再表示
drwxrwx---  named named system_u:object_r:named_cache_t  data
-rw-r--r--  named named system_u:object_r:named_conf_t   named.root
drwxrwx---  named named system_u:object_r:named_cache_t  slaves
図6.SELinuxがEnforceモード(targeted)でも起動するように設定

再度、BINDの起動を試みます。

# /sbin/service named start
named を起動中:                                            [  OK  ]
図7.BINDの起動

マウスコンピューター/G-Tune

ファイアウォールの設定

BINDのインストールで行ったiptablesの設定ではDNSキャッシュサーバーとして行う、外部への反復問い合わせが破棄されてしまいます。 これは、ファイアウォールの設定で名前解決用に記述した設定は、一般クライアントとして特定のDNSサーバーにのみ問い合わせるように設定していたからです。 キャッシュサーバーは様々なコンテンツサーバーへの問い合わせを行うため、ファイアウォールの設定に記載している内容を修正します。

# ----- 名前解決
/sbin/iptables -A OUTPUT	-p udp -o $IF1 -d $DNS1 -s $IP1 --dport 53 -m state --state NEW -j ACCEPT
/sbin/iptables -A OUTPUT	-p tcp -o $IF1 -d $DNS1 -s $IP1 --dport 53 -m state --state NEW -j ACCEPT
これらの行を以下のように変更
# ----- 名前解決
/sbin/iptables -A OUTPUT	-p udp -o $IF1 -s $IP1 --dport 53 -m state --state NEW -j ACCEPT
/sbin/iptables -A OUTPUT	-p tcp -o $IF1 -s $IP1 --dport 53 -m state --state NEW -j ACCEPT
図8.「ファイアウォールの設定」の修正

上記のコマンドを修正した後、以下のコマンドでパケットフィルタテーブルを更新します。

# /usr/local/sbin/iptables.sh
ファイアウォールのルールを /etc/sysconfig/iptables に保存中[  OK  ]
ファイアウォールルールを適用中:                            [  OK  ]
チェインポリシーを ACCEPT に設定中filter                   [  OK  ]
iptables モジュールを取り外し中                            [  OK  ]
iptables ファイアウォールルールを適用中:                   [  OK  ]
iptables モジュールを読み込み中ip_conntrack_netbios_ns     [  OK  ]
図9. パケットフィルタテーブルの更新

インテルCentrino Duo搭載ThinkPad T60 [468x60]

名前解決できるかどうかを確認する

DNSキャッシュサーバーとして機能しているかどうかを確認します。
以下はLinuxクライアントからの問い合わせの例です。

# dig @192.168.10.2 google.com

; <<>> DiG 9.3.3rc2 <<>> @192.168.10.2 google.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9318
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       64.233.167.99
google.com.             300     IN      A       64.233.187.99
google.com.             300     IN      A       72.14.207.99

;; AUTHORITY SECTION:
google.com.             345600  IN      NS      ns1.google.com.
google.com.             345600  IN      NS      ns2.google.com.
google.com.             345600  IN      NS      ns3.google.com.
google.com.             345600  IN      NS      ns4.google.com.

;; Query time: 433 msec
;; SERVER: 192.168.10.2#53(192.168.10.2)
;; WHEN: Thu Mar 13 16:00:00 2008
;; MSG SIZE  rcvd: 148

図10.DNSサーバーがキャッシュサーバーとして機能していることを確認

再起動してもBINDが起動するように設定する

上で起動したDNSサーバーは一時的に起動されたもので、システムが再起動されると再びサービスが停止してしまいます。システムを再起動しても自動的にサービスが起動しするように、chkconfigコマンドを使用して設定します。

# /sbin/chkconfig named on
# /sbin/chkconfig --list named
named           0:off   1:off   2:on    3:on    4:on    5:on    6:off
図11. BINDのランレベルを変更

これで、内部向けのキャッシュサーバーの構築が完了しました。
後はクライアントのDNSサーバーをこのサーバーに設定すれば良いだけになります。

掲載日 3/13/2008