BINDを利用した、DNSコンテンツサーバのインストール、設定方法、セキュリティ、注意点について
自分でDNSコンテンツサーバを立て、そちらで運用してみます。
今回実験で利用するサーバ
通常は、DNSコンテンツサーバは、マスターサーバ(プライマリ)とスレーブサーバ(セカンダリ)の2台構築して冗長化します。マスターサーバ、スレーブサーバ両方の構築を行います。
OS | CentOS 5.1 |
IP | 10.20.138.23 |
用途 | DNSサーバ(プライマリ) |
# cat /etc/redhat-release CentOS release 5 (Final)
OS | CentOS 5.1 |
IP | 10.20.138.24 |
用途 | DNSサーバ(セカンダリ) |
# cat /etc/redhat-release CentOS release 5 (Final)
※実験なので、ローカルIPで行います。
事前準備
DNSコンテンツサーバを立てる場合、以下のものが必要です。
- グローバルIPを持ったサーバ
※ただし、実験・説明はプライベートアドレスで行います。DNSの仕組みとしてはプライベートもグローバルも違いはないため、実際にグローバルアドレスを取得した場合にはそのアドレスに置き換えて考えて頂ければけっこうです。
IPアドレスの確認とネームサーバ名(ドメイン)の決定
以下のようなドメインと配布IPアドレスの関係のDNS設定を行います。
ドメイン | 配布IPアドレス |
hoge.com | 10.20.138.0/255.255.255.0 |
また、ネームサーバ名(ドメイン)は以下のようにします。
DNSコンテンツサーバ | ネームサーバ名(ドメイン) |
マスターサーバ | ns1.hoge.com |
スレーブサーバ | ns2.hoge.com |
DNSマスターサーバのインストール
DNSサーバは、BINDを利用します。
まず、すでにインストールされているかどうか、確認します。
# rpm -qa | grep bind* binutils-2.17.50.0.6-5.el5 bind-utils-9.3.3-10.el5 ypbind-1.19-8.el5 bind-libs-9.3.3-10.el5
bint と bind-chrootはインストールされていないようです。
それでは、インストールしてみます。
以下の2つをインストールします。
- bind
- bind-chroot
yum -y install bind bind-chroot
インストールの確認
# rpm -qa | grep bind bind-libs-9.3.4-10.P1.el5_3.1 bind-utils-9.3.4-10.P1.el5_3.1 bind-chroot-9.3.4-10.P1.el5_3.1 ypbind-1.19-8.el5 bind-9.3.4-10.P1.el5_3.1
インストールされました。
BINDのディレクトリ構造
今回は、bind-chroot を一緒にインストールしていますので、以下のようになります。
ファイル・ディレクトリ | 説明 |
/etc/rc.d/init.d/named | namedを制御するためのスクリプト |
/var/named/chroot/etc/named.conf | BINDのメインの設定ファイル。namedは起動時にこのファイルを読み込み、動作や自分が管理するゾーンを決定します |
/etc/named.rfc1912.zones | ループバックアドレスの正引きや逆引きに関する設定ファイル。 ※今回は設置しません。 |
/etc/named.root.hints | インターネットに13台のみ存在しているルートDNS(一番上位のDNS)に関する設定ファイル ※今回は設置しません。 |
/use/sbin/named | BINDの中心となるプログラム。このプログラムが起動後デーモンとして常駐し、クライアントからの名前解決の問い合わせ処理をします |
/var/named/chroot/var/named/...... | ゾーンデータベースファイル(ゾーンの数だけ存在) |
/var/log/messages | BINDの起動ログが記録されているファイル。うまく起動しない場合やトラブルが生じている場合はここに記録されているログを参照します |
ちなみに、bind-chroot をインストールしないと以下のようになります。
ファイル・ディレクトリ | 説明 |
/etc/rc.d/init.d/named | namedを制御するためのスクリプト |
/etc/named.conf | BINDのメインの設定ファイル。namedは起動時にこのファイルを読み込み、動作や自分が管理するゾーンを決定します |
/etc/named.rfc1912.zones | ループバックアドレスの正引きや逆引きに関する設定ファイル。 ※今回は設置しません。 |
/etc/named.root.hints | インターネットに13台のみ存在しているルートDNS(一番上位のDNS)に関する設定ファイル ※今回は設置しません。 |
/use/sbin/named | BINDの中心となるプログラム。このプログラムが起動後デーモンとして常駐し、クライアントからの名前解決の問い合わせ処理をします |
/var/named/...... | ゾーンデータベースファイル(ゾーンの数だけ存在) |
/var/log/messages | BINDの起動ログが記録されているファイル。うまく起動しない場合やトラブルが生じている場合はここに記録されているログを参照します |
ゾーンの決定
BINDは、ホスト名とIPアドレスの対照表を、ゾーンという単位で管理します。マスターサーバとしての設定を行うためには、まずゾーン名を決める必要があります。
ゾーンには正引きゾーンと逆引きゾーンがあります。
■正引きゾーン
今回実験で利用するドメインが、 hoge.com ですので、hoge.com が正引きゾーンになります。
■逆引きゾーン
今回は、配布IPアドレスが
10.20.138.0/255.255.255.0 なので、逆引きゾーンは、 138.20.10.in-addr.arpa になります。
/var/named/chroot/etc/named.conf にゾーン追加
最初は、マスターサーバの設定です。
ゾーンを設定ファイルに追加しますが、ゾーンの内容と問い合わせ元の内容によりどの view に設定を追加するべきなのかを検討する必要があります。グローバルアドレスを持ったコンピュータをインターネットに公開するためなら external に設定をします。今回は、DNS自身から、設定した内容の確認を行うために localhost_resolver と internal に同じ設定を記述します。以下のように localhost_resolver viewステートメントの中に zoneステートメントを記述します。
localhost_resolver viewステートメントに設定します。
internal viewステートメントにも同様に設定します。
マスターサーバの named.conf
options { directory "/var/named"; allow-transfer{ none }; }; view "localhost_resolver" { zone "hoge.com" { type master; file "hoge.com.db"; allow-transfer { none; }; }; zone "138.20.10.in-addr.arpa" { type master; file "138.20.10.in-addr.arpa.db"; allow-transfer { none; }; }; }; view "internal" { zone "hoge.com" { type master; file "hoge.com.db"; allow-transfer { none; }; }; zone "138.20.10.in-addr.arpa" { type master; file "138.20.10.in-addr.arpa.db"; allow-transfer { none; }; }; };
allow-transfer ステートメントはゾーン転送を許可するアドレスを指定します。もしスレーブが存在しない場合にはIPアドレスの代わりに none としています。この行を省略した場合には、任意のサーバへのゾーン転送が許可され、セキュリティ上好ましくありません。
ゾーンデータベースの作成(正引き)
マスターサーバの設定です。
ゾーンデータベースの作成(逆引き)
マスターサーバの設定です。
/var/named/chroot/var/named/138.20.10.in-addr.arpa.db
$TTL 86400 138.20.10.in-addr.arpa. IN SOA ns1.hoge.com. root.hoge.com. ( 2009072201 ;Serial 7200 ;Refresh 3600 ;Retry 604800 ;Expire 3600 ;Minimum TTL ) IN NS ns1.hoge.com. 23 IN PTR ns1.hoge.com.
PTRレコードは、IPアドレスからホスト名へ変換するためのレコードです。この設定により、10.20.138.23 というIPアドレスが ns1.hoge.com というホスト名へ変換できるようになります。
ただ、実際には、10.20.138.23 というIPアドレスを直接変換するのではなく、23.138.20.10.in-addr.arpa という逆引き用の名前に置き換えて、 ns1.hoge.com というホスト名へ変換しています。ゾーン名を省略せずにPTRレコードを記述すると、以下のようになります。
23.138.20.10.in-addr.arpa. IN PTR ns1.hoge.com.
namedの起動
BINDで名前解決を実際に行うのは、named というデーモンになります。デーモンとは、常に実行状態で待機し、要求があればそれに応じて何らかの処理をするプログラムです。BINDではnamedがメモリ上に常駐し、名前解決の問い合わせに対して処理を行っています。namedの起動は以下のように行います。
マスターサーバの named を起動してみましょう。
# /etc/init.d/named start Starting named: [ OK ]
問い合わせを行う DNSサーバの変更
vi /etc/resolv.conf
/etc/revolv.conf にいかを記述します。
nameserver 10.20.138.23
これで、自サーバ上で動作しているDNSサーバを使っての名前解決が可能となります。
DNSサーバのテスト
nslookup コマンドでテストを行います。nslookupコマンドはDNSにさまざまな問い合わせを行い、その結果を出力するためのプログラムです。nslookupを使うと、namedの動作検証を行ったり、ゾーンデータベースの内容を確認できます。
正引きをテスト
# nslookup ns1.hoge.com Server: 10.20.138.23 Address: 10.20.138.23#53 Name: ns1.hoge.com Address: 10.20.138.23
逆引きをテスト
# nslookup 10.20.138.23 Server: 10.20.138.23 Address: 10.20.138.23#53 23.138.20.10.in-addr.arpa name = ns1.hoge.com.
スレーブ・サーバの構築
スレーブ・サーバの基本的なこと
マスターサーバは構築できましたので、今度はスレーブ・サーバの構築とゾーン転送をおこないましょう。
こちらを参考に行います。
基本的には、ゾーンデータをコピーすればいいので、その方法はなんでもかまいません。
次のような手法がよくつかわれます。
ゾーン転送(DNS AXFR:DNS Zone Transfer)の利用
スレーブ・サーバのゾーン転送とセキュリティ (1/3):実用 BIND 9で作るDNSサーバ(5) - @IT
ゾーン転送は最もオーソドックスな手法です。スレーブはマスターのゾーンデータが更新されていることを確認すると、ゾーンデータのダウンロードと再構築を行って、更新されたゾーンデータを有効にします。その際、マスター・サーバ更新の有無はゾーンデータのSOAレコード中のSerialで判定します。 Serialの値が大きくなっていれば更新されたと見なし、ゾーン転送(AXFR)を開始します。
スレーブサーバの named.conf
options { directory "/var/named"; }; view "localhost_resolver" { zone "hoge.com" { type slave; file "hoge.com.db"; masters { 10.20.138.23; }; }; zone "138.20.10.in-addr.arpa" { type slave; file "138.20.10.in-addr.arpa.db"; masters { 10.20.138.23; }; }; }; view "internal" { zone "hoge.com" { type slave; file "hoge.com.db"; masters { 10.20.138.23; }; }; zone "138.20.10.in-addr.arpa" { type slave; file "138.20.10.in-addr.arpa.db"; masters { 10.20.138.23; }; }; };
また、マスターサーバの named.conf の
allow-transfer { none; };
の部分は、
allow-transfer { 10.20.138.24; };
となります。
※10.20.138.23がマスターサーバ、10.20.138.24 がスレーブサーバです。
※スレーブサーバにDNSサーバをインストールするときは、マスターサーバと同じですが、一点注意があります。/var/named/chroot/var/named/ ディレクトリの権限です。スレーブサーバで以下を実行して、named に権限を与えてください。
chown named:named /var/named/chroot/var/named/
それでは、マスターサーバとスレーブサーバの設定を行ってnamedサーバを再起動してみましょう。
設定し終わりましたら、ちゃんとマスターサーバからスレーブサーバにゾーン転送許可があるかどうか確認しましょう。
スレーブサーバで以下のコマンドを実行します。
dig @10.20.138.24 hoge.com axfr
実行結果です。
[root@ns2 chroot]# dig @10.20.138.23 hoge.com axfr ; <<>> DiG 9.3.4-P1 <<>> @10.20.138.23 hoge.com axfr ; (1 server found) ;; global options: printcmd hoge.com. 86400 IN SOA ns1.hoge.com. root.hoge.com. 2009072201 7200 3600 604800 3600 hoge.com. 86400 IN NS ns1.hoge.com. hoge.com. 86400 IN MX 10 ns1.hoge.com. ns1.hoge.com. 86400 IN A 10.20.138.23 hoge.com. 86400 IN SOA ns1.hoge.com. root.hoge.com. 2009072201 7200 3600 604800 3600 ;; Query time: 18 msec ;; SERVER: 10.20.138.23#53(10.20.138.23) ;; WHEN: Thu Jul 23 21:23:55 2009 ;; XFR size: 5 records (messages 1)
しっかりとゾーン転送できるようです。
しかし、まだ、スレーブサーバの方にゾーンは転送されていません。
# ls -la /var/named/chroot/var/named/ total 16 drwxr-x--- 4 root named 4096 Jul 23 21:14 . drwxr-x--- 6 root named 4096 Jul 23 21:14 .. drwxrwx--- 2 named named 4096 Aug 26 2004 data drwxrwx--- 2 named named 4096 Jul 27 2004 slaves
ゾーンサーバをスレーブサーバに転送させましょう。
ゾーン転送の強制実行(DNS NOTIFYの使用)
スレーブ・サーバのゾーン転送とセキュリティ (2/3):実用 BIND 9で作るDNSサーバ(5) - @IT
詳しくは上記をご覧ください。
マスターサーバで以下の操作を行います。
/usr/sbin/rndc-confgen -r /dev/urandom > /etc/rndc.conf vi /var/named/chroot/etc/named.conf /etc/init.d/named restart /usr/sbin/rndc reload
※-r /dev/urandom を指定しないと、フリーズしたんじゃないかと思うくらい生成速度が遅くなる場合があります・・・。
- named.conf に追記した内容
key "rndckey" { algorithm hmac-md5; secret "GVfRLBJw/FnS+AwRfD2Ulg=="; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndckey"; }; };
- さらにマスターサーバ側で notify についての設定を追加
options { (省略) notify yes; also-notify { 10.20.138.24;}; };
マスターサーバ側で /usr/sbin/rndc reload を行うと、スレーブサーバにゾーンファイルがコピーされているはずです。
もし、コピーされない場合は、スレーブサーバの /var/log/messgaes を見てください。
書き込み権限がない可能性があるので、以下のコマンドをスレーブサーバ側で実行して、named が書き込めるように権限を与えてあげてください。
chown named:named /var/named/chroot/var/named/
DNSコンテンツサーバのセキュリティ
ゾーン転送のセキュリティ対策
スレーブ・サーバのゾーン転送とセキュリティ (1/3):実用 BIND 9で作るDNSサーバ(5) - @IT
上気に記述してあります。
使わせないのが基本
ゾーン転送に関するセキュリティ対策は、何よりもマスター・サーバ側で、あらかじめ指定されたスレーブ・サーバ以外からはゾーン転送を受け付けないようにするのが第一です。
named.conf 例
options { allow-transfer{ スレーブ・サーバ1のIP; スレーブ・サーバ2のIP; }; (1) }; zone "example.jp" { type master; file "example.zone"; allow-transfer{ none; (2) }; }; (3)
(1)追加したい分だけ「;」で区切って追加。
(2)無指定
(3)optionsステートメントで指定されたものより、ゾーンセンテンスで指定されたものの方が優先されるため、この場合example.jpに対してはどこからもゾーン転送が行えない
マスターサーバ側で allow-transfer の値をnone の状態にして、スレーブサーバ側から マスターサーバにアクセスしてみましょう。
# dig @10.20.138.23 hoge.com axfr ; <<>> DiG 9.3.4-P1 <<>> @10.20.138.23 hoge.com axfr ; (1 server found) ;; global options: printcmd ; Transfer failed.
Transfer failed. です。ゾーン転送できませんでした。
今度は、マスターサーバ側で allow-transfer の値を 10.20.138.24 の状態にして、スレーブサーバ側から マスターサーバにアクセスしてみましょう。
# dig @10.20.138.23 hoge.com axfr ; <<>> DiG 9.3.4-P1 <<>> @10.20.138.23 hoge.com axfr ; (1 server found) ;; global options: printcmd hoge.com. 86400 IN SOA ns1.hoge.com. root.hoge.com. 2009072204 7200 3600 604800 3600 hoge.com. 86400 IN NS ns1.hoge.com. hoge.com. 86400 IN MX 10 ns1.hoge.com. ns1.hoge.com. 86400 IN A 10.20.138.23 hoge.com. 86400 IN SOA ns1.hoge.com. root.hoge.com. 2009072204 7200 3600 604800 3600 ;; Query time: 28 msec ;; SERVER: 10.20.138.23#53(10.20.138.23) ;; WHEN: Thu Jul 23 22:18:05 2009 ;; XFR size: 5 records (messages 1)
allow-transferステートメントについて
allow-transferステートメントはゾーン転送を許可するアドレスを指定します。もし、スレーブサーバが存在しない場合にはIPアドレスの代わりに none と指定します。この行を省略した場合には、任意のサーバへのゾーン転送が許可され、セキュリティ上好ましくありません。
namedをchroot環境で動作させる
サーバデーモンのセキュリティを高めるために、chroot環境を利用することがあります。
chroot環境とは、あるディレクトリを特定のプロセスにとっては "/(ルート)"ディレクトリに見えるようにした環境のことです。
ここでは named デーモンにとって、/var/named/chroot ディレクトリが "/(ルート)"に見えるように設定します。
そうすると、万が一 named がクラックされたとしても、/var/named/chroot ディレクトリより上の階層のデータにはアクセスできなくなりますので、被害がサーバ全体に及ぶことを防ぐことができます。
インストール方法は以下です。
yum -y install bind-chroot
TSIGの利用
IPのみの制限だけでなく、公開鍵認証のようなことをします。
詳しくは、下記をご覧ください。
スレーブ・サーバのゾーン転送とセキュリティ (3/3):実用 BIND 9で作るDNSサーバ(5) - @IT
マスター・サーバのアクセス制限は上記の要領で完了しますが、スレーブ・サーバはIPアドレスでのみマスターを識別しているため、マスター・サーバのIPを偽装した「なりすましサーバ」が出現した場合はまったくの無防備になります。
そこで、TSIG(Transaction Signature)を用います。TSIGはサーバとクライアントで共通の秘密鍵を保有し、DNSメッセージ全体に署名を行うことでメッセージの完全性の保証やリクエスト認証を可能にします(注)。
まず、マスターサーバ側で以下を実行して、秘密鍵と公開鍵を生成します。
cd /var/named /usr/sbin/dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 512 -n HOST hoge.com
以下のようなファイルが生成されます。
- Khoge.com.+157+46875.key
- Khoge.com.+157+46875.private
それぞれの中身は以下の通りです。
# cat /var/named/Khoge.com.+157+46875.key hoge.com. IN KEY 512 3 157 qbbGi7MLQCrx4XBHuV12xtt8ciYT4EkAx204xrv+JPFWyBfOPc6ZHS0M S0nlEOmjmDplqn9RWmsFPD/zWMMt8A== # cat /var/named/Khoge.com.+157+46875.private Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: qbbGi7MLQCrx4XBHuV12xtt8ciYT4EkAx204xrv+JPFWyBfOPc6ZHS0MS0nlEOmjmDplqn9RWmsFPD/zWMMt8A==
また、マスターサーバ側の named.conf は以下のようになります。
options { directory "/var/named"; allow-transfer { none; }; notify yes; also-notify { 10.20.138.24;}; }; view "localhost_resolver" { zone "hoge.com" { type master; file "hoge.com.db"; allow-transfer { key hoge.com; }; }; zone "138.20.10.in-addr.arpa" { type master; file "138.20.10.in-addr.arpa.db"; allow-transfer { key hoge.com; }; }; }; view "internal" { zone "hoge.com" { type master; file "hoge.com.db"; allow-transfer { key hoge.com; }; }; zone "138.20.10.in-addr.arpa" { type master; file "138.20.10.in-addr.arpa.db"; allow-transfer { key hoge.com; }; }; }; key "hoge.com" { algorithm hmac-md5; secret "qbbGi7MLQCrx4XBHuV12xtt8ciYT4EkAx204xrv+JPFWyBfOPc6ZHS0M"; }; key "rndckey" { algorithm hmac-md5; secret "GVfRLBJw/FnS+AwRfD2Ulg=="; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndckey"; }; };
スレーブサーバ側のnamed.confは以下のようになります。
options { directory "/var/named"; }; view "localhost_resolver" { key "hoge.com" { algorithm hmac-md5; secret "qbbGi7MLQCrx4XBHuV12xtt8ciYT4EkAx204xrv+JPFWyBfOPc6ZHS0M"; }; server 10.20.138.23 { keys "hoge.com"; }; zone "hoge.com" { type slave; file "hoge.com.db"; masters { 10.20.138.23; }; }; zone "138.20.10.in-addr.arpa" { type slave; file "138.20.10.in-addr.arpa.db"; masters { 10.20.138.23; }; }; }; view "internal" { key "hoge.com" { algorithm hmac-md5; secret "qbbGi7MLQCrx4XBHuV12xtt8ciYT4EkAx204xrv+JPFWyBfOPc6ZHS0M"; }; server 10.20.138.23 { keys "hoge.com"; }; zone "hoge.com" { type slave; file "hoge.com.db"; masters { 10.20.138.23; }; }; zone "138.20.10.in-addr.arpa" { type slave; file "138.20.10.in-addr.arpa.db"; masters { 10.20.138.23; }; }; };
named.conf の修正が終わったら、named を再起動(マスター、スレーブ共に)します。
この時点で、スレーブ側から dig @10.20.138.23 hoge.com axfr とやってもデータは取得できません。
これでは、TSIG を使用していないからです。
# dig @10.20.138.23 hoge.com axfr ; <<>> DiG 9.3.4-P1 <<>> @10.20.138.23 hoge.com axfr ; (1 server found) ;; global options: printcmd ; Transfer failed.
では、ゾーン転送は可能かどうか確認してみましょう。
また、マスター側にあるゾーンファイルの Serial の数をあげて、マスター側で
/usr/sbin/rndc reload
をやってみましょう。スレーブ側のゾーンファイルは更新されるでしょうか。
スレーブ側の /var/log/messages を見てみると
Jul 23 22:51:15 ns2 named[853]: client 10.20.138.23#32778: view localhost_resolver: received notify for zone 'hoge.com' Jul 23 22:51:15 ns2 named[853]: zone hoge.com/IN/localhost_resolver: Transfer started. Jul 23 22:51:15 ns2 named[853]: transfer of 'hoge.com/IN' from 10.20.138.23#53: connected using 10.20.138.24#32805 Jul 23 22:51:15 ns2 named[853]: zone hoge.com/IN/localhost_resolver: transferred serial 2009072205: TSIG 'hoge.com' Jul 23 22:51:15 ns2 named[853]: transfer of 'hoge.com/IN' from 10.20.138.23#53: end of transfer Jul 23 22:51:15 ns2 named[853]: client 10.20.138.23#32778: view localhost_resolver: received notify for zone 'hoge.com' Jul 23 22:51:15 ns2 named[853]: zone hoge.com/IN/localhost_resolver: notify from 10.20.138.23#32778: zone is up to date Jul 23 22:51:15 ns2 named[853]: client 10.20.138.23#32778: view localhost_resolver: received notify for zone '138.20.10.in-addr.arpa' Jul 23 22:51:15 ns2 named[853]: client 10.20.138.23#32778: view localhost_resolver: received notify for zone '138.20.10.in-addr.arpa' Jul 23 22:51:15 ns2 named[853]: zone 138.20.10.in-addr.arpa/IN/localhost_resolver: notify from 10.20.138.23#32778: refresh in progress, refresh check queued Jul 23 22:51:15 ns2 named[853]: zone 138.20.10.in-addr.arpa/IN/localhost_resolver: Transfer started. Jul 23 22:51:15 ns2 named[853]: transfer of '138.20.10.in-addr.arpa/IN' from 10.20.138.23#53: connected using 10.20.138.24#32806 Jul 23 22:51:15 ns2 named[853]: zone 138.20.10.in-addr.arpa/IN/localhost_resolver: transferred serial 2009072305: TSIG 'hoge.com' Jul 23 22:51:15 ns2 named[853]: transfer of '138.20.10.in-addr.arpa/IN' from 10.20.138.23#53: end of transfer
上記のようになっており、ゾーンファイルの転送に TSIG を利用していることが分かります。
また、named.conf は重要な共有鍵が記入されているため、named.conf のパーミッションを変更しましょう。
chown named:named /var/named/chroot/etc/named.conf chmod 600 /var/named/chroot/etc/named.conf
エラー対処1(Pathの指定に注意)
# /etc/init.d/named restart Stopping named: . [ OK ] Starting named: Error in named configuration: /etc/named.conf:2: change directory to '/var/named/chroot/var/named' failed: file not found /etc/named.conf:2: parsing failed [FAILED]
http://oshiete1.watch.impress.co.jp/qa3909982.html
上記に書いてある通り、
directory "/var/named/chroot/etc";
のように書いていませんか?
bind-chrootで動かしているようなので、もしそのような指定だと
/var/named/chroot/var/named/chroot/etc/
に行こうとします。
つまり、
誤
options { directory "/var/named/chroot/var/named"; };
正
options { directory "/var/named"; };
という、記述の間違えがある可能性がありますので、確認してください。
エラー対処2(DNS NOTITYでシンクロできない)
根本の原因は Slaveの設定ファイルで directory "/var/named" と指定されていることです。下記のように権限を更新しても、Slave側のnamedをrestartすると、権限がまた戻ってしまいます。そのため、directory "/var/named/slaves" のように専用ディレクトリを設けると良いです。(saiさん++)
マスターサーバ側で
/usr/sbin/rndc reload
を実行して、シンクロスタートしたものの、スレーブのファイルが更新されてない。
スレーブの /var/log/messages を見てみると以下のようなログがある。
Jul 23 21:59:44 ns2 named[499]: client 10.20.138.23#32770: view localhost_resolver: received notify for zone 'hoge.com' Jul 23 21:59:44 ns2 named[499]: zone hoge.com/IN/localhost_resolver: Transfer started. Jul 23 21:59:44 ns2 named[499]: transfer of 'hoge.com/IN' from 10.20.138.23#53: connected using 10.20.138.24#32789 Jul 23 21:59:44 ns2 named[499]: dumping master file: tmp-wcW6ESYQJK: open: permission denied Jul 23 21:59:44 ns2 named[499]: transfer of 'hoge.com/IN' from 10.20.138.23#53: failed while receiving responses: permission denied Jul 23 21:59:44 ns2 named[499]: transfer of 'hoge.com/IN' from 10.20.138.23#53: end of transfer Jul 23 21:59:45 ns2 named[499]: client 10.20.138.23#32770: view localhost_resolver: received notify for zone 'hoge.com' Jul 23 21:59:45 ns2 named[499]: zone hoge.com/IN/localhost_resolver: Transfer started. Jul 23 21:59:45 ns2 named[499]: transfer of 'hoge.com/IN' from 10.20.138.23#53: connected using 10.20.138.24#32790 Jul 23 21:59:45 ns2 named[499]: dumping master file: tmp-qXK80P7Oj4: open: permission denied Jul 23 21:59:45 ns2 named[499]: transfer of 'hoge.com/IN' from 10.20.138.23#53: failed while receiving responses: permission denied Jul 23 21:59:45 ns2 named[499]: transfer of 'hoge.com/IN' from 10.20.138.23#53: end of transfer
どうも、permission denied ということらしい。スレーブ側で以下を実行。
chown named:named /var/named/chroot/var/named/
マスター側の ゾーンファイルの Serial の数をあげて、もう一度、チャレンジ。
/etc/init.d/named restart
こんどは、スレーブサーバの /var/log/messges にはエラーは出ていない。
Jul 23 22:10:14 ns2 named[499]: client 10.20.138.23#32772: view localhost_resolver: received notify for zone '138.20.10.in-addr.arpa' Jul 23 22:10:14 ns2 named[499]: zone 138.20.10.in-addr.arpa/IN/localhost_resolver: Transfer started. Jul 23 22:10:14 ns2 named[499]: transfer of '138.20.10.in-addr.arpa/IN' from 10.20.138.23#53: connected using 10.20.138.24#32796 Jul 23 22:10:14 ns2 named[499]: zone 138.20.10.in-addr.arpa/IN/localhost_resolver: transferred serial 2009072304 Jul 23 22:10:14 ns2 named[499]: transfer of '138.20.10.in-addr.arpa/IN' from 10.20.138.23#53: end of transfer Jul 23 22:10:15 ns2 named[499]: client 10.20.138.23#32772: view localhost_resolver: received notify for zone 'hoge.com' Jul 23 22:10:15 ns2 named[499]: client 10.20.138.23#32772: view localhost_resolver: received notify for zone 'hoge.com' Jul 23 22:10:15 ns2 named[499]: zone hoge.com/IN/localhost_resolver: notify from 10.20.138.23#32772: refresh in progress, refresh check queued Jul 23 22:10:15 ns2 named[499]: client 10.20.138.23#32772: view localhost_resolver: received notify for zone '138.20.10.in-addr.arpa' Jul 23 22:10:15 ns2 named[499]: zone 138.20.10.in-addr.arpa/IN/localhost_resolver: notify from 10.20.138.23#32772: zone is up to date Jul 23 22:10:15 ns2 named[499]: zone hoge.com/IN/localhost_resolver: Transfer started. Jul 23 22:10:15 ns2 named[499]: transfer of 'hoge.com/IN' from 10.20.138.23#53: connected using 10.20.138.24#32797 Jul 23 22:10:15 ns2 named[499]: zone hoge.com/IN/localhost_resolver: transferred serial 2009072204 Jul 23 22:10:15 ns2 named[499]: transfer of 'hoge.com/IN' from 10.20.138.23#53: end of transfer
スレーブサーバ側のゾーンファイルを確認してみても、最新のものになっている。(今回の例は 〜04 のSerial が最新)
[root@ns2 chroot]# cat /var/named/chroot/var/named/hoge.com.db $ORIGIN . $TTL 86400 ; 1 day hoge.com IN SOA ns1.hoge.com. root.hoge.com. ( 2009072204 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 3600 ; minimum (1 hour) ) NS ns1.hoge.com. MX 10 ns1.hoge.com. $ORIGIN hoge.com. ns1 A 10.20.138.23
[root@ns2 chroot]# cat /var/named/chroot/var/named/138.20.10.in-addr.arpa.db $ORIGIN . $TTL 86400 ; 1 day 138.20.10.in-addr.arpa IN SOA ns1.hoge.com. root.hoge.com. ( 2009072304 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 3600 ; minimum (1 hour) ) NS ns1.hoge.com. $ORIGIN 138.20.10.in-addr.arpa. 23 PTR ns1.hoge.com.
ValueDomainからのコンテンツサーバの移動
ValueDomain.comにログインの上、以下の場所へ移動すれば、設定できます。
https://www.value-domain.com/modns.php?action=modns2&domainname=(管理しているドメイン名)
例:
https://www.value-domain.com/modns.php?action=modns2&domainname=xxxxxx.com