プログラマ 福重 伸太朗 〜基本へ帰ろう〜 このページをアンテナに追加 RSSフィード

2009-07-23

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コンテンツサーバを立てる場合、以下のものが必要です。

※ただし、実験・説明はプライベートアドレスで行います。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つをインストールします。

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/hoge.com.db
$TTL 86400 

hoge.com. IN SOA ns1.hoge.com. root.hoge.com. (
  2009072101 ;Serial
  7200       ;Refresh
  3600       ;Retry
  604800     ;Expire
  3600       ;Minimum TTL
)
    IN NS ns1.hoge.com.
    IN MX 10 ns1
ns1 IN A  10.20.138.23

上記の設定は、DNSサーバ自身のドメイン(ns.hoge-fuga-baz.com)設定を行っています。



ゾーンデータベースの作成(逆引き)

マスターサーバの設定です。

/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)の利用
  • scp、rsync、destなどのリモートファイルコピーツールの利用

今回は、「ゾーン転送(DNS AXFR:DNS Zone Transfer)」を利用してみましょう。


ゾーン転送(DNS AXFR:DNS Zone Transfer)の利用

実用 BIND 9で作るDNSサーバ(5):スレーブ・サーバのゾーン転送とセキュリティ (1/3) - @IT

ゾーン転送は最もオーソドックスな手法です。スレーブはマスターのゾーンデータが更新されていることを確認すると、ゾーンデータのダウンロードと再構築を行って、更新されたゾーンデータを有効にします。その際、マスター・サーバ更新の有無はゾーンデータのSOAレコード中のSerialで判定します。 Serialの値が大きくなっていれば更新されたと見なし、ゾーン転送(AXFR)を開始します。

f:id:japanrock_pg:20090723232545p:image



スレーブサーバの 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の使用)

実用 BIND 9で作るDNSサーバ(5):スレーブ・サーバのゾーン転送とセキュリティ (2/3) - @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コンテンツサーバセキュリティ

ゾーン転送のセキュリティ対策

実用 BIND 9で作るDNSサーバ(5):スレーブ・サーバのゾーン転送とセキュリティ (1/3) - @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のみの制限だけでなく、公開鍵認証のようなことをします。

詳しくは、下記をご覧ください。

実用 BIND 9で作るDNSサーバ(5):スレーブ・サーバのゾーン転送とセキュリティ (3/3) - @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]

no title

上記に書いてある通り、

directory "/var/named/chroot/etc";

のように書いていませんか?

bind-chrootで動かしているようなので、もしそのような指定だと

/var/named/chroot/var/named/chroot/etc/

に行こうとします。

ディレクトリの指定をchrootの下から記載してみてください。

つまり、

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.



注意

FirewallやiptablesDNSのポート(TCPUDPの53番)を塞がないようにしましょう。

TCPの53番はゾーン転送で利用されます。



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



参考書籍

はじめてのCentOS5 Linuxサーバ構築編 (TECHNICAL MASTER)