2018/4/21 CentOS7 build1708


DNSスレーブサーバを構成する

ゾーンのスレーブサーバを構成します。

デフォルトのnamed.confに最小限の調整で構成します。
転送元となるマスターサーバの構成は「DNSマスターサーバを構成する」で出来てるものとします。


０．マスターサーバ側の事前作業

まずはマスターサーバ側で、ファイアウォールを開放する必要があります。
開放が必要なポートはTCP53番、UDP53版です。serviceでdnsを指定すれば両方開きます。
すでにポートが開いているのならこの手順は不要です。

マスターサーバ上で
#firewall-cmd --permanent --zone=public(現在のゾーン) --add-service=dns
#firewall-cmd --reload


次にマスターサーバ側で、スレーブサーバを受け入れる設定が必要です。
マスターサーバの/etc/named.confへ、各ゾーンごとに以下の設定を追加します。

//正引きゾーンの定義
zone "example.com" {
  type master;
  file "example.com.zone";
  allow-update {none;} ;
  allow-transfer { 192.168.1.11; };  //スレーブサーバのアドレス
};

//逆引きゾーンの定義
zone "1.168.192.in-addr.arpa" IN {
  type master;
  file "example.com.rev";
  allow-update {none;} ;
  allow-transfer { 192.168.1.11; };  //スレーブサーバのアドレス
};

マスターのゾーンファイルへ、2つめのNSレコードを追加する。
example.com.zone ゾーンファイル
------------------------------------------
$TTL 86400
@    IN   SOA   ns1.example.com.   root.example.com. (
    2017110401 ;Serial
    3600           ;ゾーン転送の間隔 秒
    300             ;転送失敗時のリトライ間隔　秒
    360000       ;ゾーンファイルの保持時間　秒
    86400   )    ;他サーバでキャッシュされる時間　秒

            IN   NS          ns1.example.com.     //末尾のドットに注意
            IN   NS          ns2.example.com.     //末尾のドットに注意
ns1       IN   A            192.168.1.10           //マスターDNSサーバ
ns2       IN   A            192.168.1.11           //スレーブDNSサーバ
host1     IN   A            192.168.1.99        //LAN内の適当なアドレス
------------------------------------------


example.com.rev 逆引きゾーンファイル
------------------------------------------
$TTL 86400
@    IN   SOA   ns1.example.com.   root.example.com. (
    2017110401 ;Serial
    3600           ;Refresh sec(Transfer span)
    300             ;Retry sec(in failure retry)
    360000        ;SecondaryExpire sec
    86400   )    ;Minumum TTL sec(zone expired time)

            IN   NS          ns1.example.com.       //末尾のドットに注意
            IN   NS          ns2.example.com.       //末尾のドットに注意
10         IN   PTR        ns1.example.com.       //末尾のドットに注意
11         IN   PTR        ns2.example.com.       //末尾のドットに注意
99         IN   PTR        host1.example.com.    //末尾のドットに注意
------------------------------------------


named.configを再読み込み
#rndc reconfig


変更通知について
　ここではゾーンファイルのNSレコードに、マスターサーバ・スレーブサーバのレコードを登録しています。
　NSレコードに登録されたサーバは、ゾーン変更時に自然と「変更されましたよ」という通知が配られます。
　しかしNSレコードに記載されないスレーブサーバを作った場合（例えば、内部向けにセカンダリDNSサーバを作ったとか）は、NSに含まれず変更の通知対象になりません。
　NSに登録せず変更通知を送信する場合は、notifyというパラメータが使用できます。

　マスターのnamed.confへ以下のパラメータを追加します。

options {
       //DNSサービスを提供する自IPアドレスを追加
        notify yes;
        also-notify { 192.168.1.11; };
}



以降はスレーブサーバ側の構成です。

１．ファイアウォールを開放する

現在のゾーンを確認します。
#firewall-cmd --get-active-zones
public
  interfaces: enp0s3

現在のゾーンへDNSサービスの許可を追加します。
#firewall-cmd --permanent --zone=public(現在のゾーン) --add-service=dns

もしくは

#firewall-cmd --set-default-zones=trusted
(デフォルトのゾーンを、FW無しのtrustedに）

もしくは

#firewall-cmd --zone=trusted --change-interface=enp0s3
(FWを一時的に変更、全許可へ。再起動したらDefaultに戻ります)


２．DNSのインストール

#yum install bind-chroot bind

bind本体とbind-chroot環境をインストールします。
過去のバージョンではbind-chrootだけでbindが動作したものですが。
ここではbinr-chroot 9.9.4が入りました。


３．IPv6の問い合わせを無効にする。

　環境によりますが、もしネットワーク内にIPv4クライアントしかなく、IPv4のネットワークしか使わない予定なら、DNSのIPv6問い合わせを無効にすることで、解決速度を高めることができます。

#vi /etc/sysconfig/named

（追加）
OPTIONS="-4"



４．コンフィグの調整

/etc/named.confを調整します。
コンフィグはバージョンによって動作が微妙に変わってくるのがクセものです。
これはBIND9.9.4(CentOS)ですから。
デフォルトのコンフィグに、赤色で追記します。


options {

       //DNSサービスを提供する自IPアドレスを追加
        listen-on port 53 { 127.0.0.1;　192.168.1.11; };

       //IPv6問い合わせを無効jにしたいので、コメントアウト
       //listen-on-v6 port 53 { ::1; };

        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

        //名前の問い合わせ元はインターネット全て
        allow-query { any; };


   　   //今回はスレーブサーバとして動作するので、キャッシュサーバとしては動作させない
        recursion no;

        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";
};

 logging {
        channel default_debug {
             file "data/named.run" versions 10 size 10M;  //10世代10MBまでログを保存
                severity dynamic;
 
             print-time yes; //ログに時刻を出力
              print-query yes; //名前解決を求めたクライアントアドレスを出力
         };

       category lame-servers { null; };   //名前解決エラーのログは出力しない
       //category queries { "default_debug"; };   クエリログを取得する場合はこちらを使用
 };

zone "." IN {
        type hint;
        file "named.ca";
};

//正引きゾーンの定義
zone "example.com" {
  type slave;
   masters { 192.168.1.10; };  //転送元のサーバ
  file "slaves/example.com.zone";   //directoryで指定したパスを基準にしたファイル名
  allow-update {none;} ;
  allow-transfer { none; };  //再転送は禁止する。さもないとゾーン情報を丸ごと読まれます
};

//逆引きゾーンの定義 (必要であれば)
zone "1.168.192.in-addr.arpa" IN {
  type slave;
   masters { 192.168.1.10; };  //転送元のサーバ
  file "slaves/example.com.rev";
  allow-update {none;} ;
  allow-transfer { none; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

};


５．コンフィグの確認、サービスの起動、エラー確認

named.confの文法チェック。なにも表示されなければ正しい
#named-checkconf

namedがまだ起動していない場合、起動
#systemctl start named

namedが起動済みの場合、コンフィグとゾーン情報を再読み込み
#rndc reload

起動しない場合、エラーログの確認
#tail -n 30 /var/log/message


６．転送の確認

設定情報が正しければ、/var/named/slavesディレクトリの下にファイルが存在しています。

クライアントからスレーブサーバに対してnslookupコマンドを実行し、名前解決されることを確認します。

nslookup
>server 192.168.1.11
>host1.example.com
サーバー: [192.168.1.11]
Address: [192.168.1.11]

名前:  host1.example.com
Address:  192.168.1.99

>set type=ptr
>192.168.1.99
サーバー: [192.168.1.11]
Address: [192.168.1.11]

99.1.168.192.in-addr.arpa   name=host1.example.com
1.168.192.in-addr.arpa  （略）


トラブルシューティング

一発で成功すればいいのですが、そうでないことも考えられます。
上手く初回転送が行われない場合、切り分けを行います。

スレーブ側のログの確認
#tail -n 30 /var/log/message
転送が成功しているのか失敗しているのかを確認します。


マスター側のログの確認
#tail /var/named/data/named.run
マスター側で転送を拒否しているのか。（allow-transferの確認）
通信が来ているのか、あるいはまったく到達してないのか。（ファイアウォールの確認）


スレーブ側からコマンドで、転送をシミュレーション
#dig @192.168.1.10 example.com axfr
コマンドを実行してゾーンの一覧が表示されれば、マスター側の受付設定は正常です。
コマンドが拒否されれば、マスター側の受付が正常でないと考えられます。


Windows端末から転送をシミュレーション
 Windows端末からも転送が試験できます。
1.マスターサーバnamed.confのallow-transferへ、Windows端末のアドレスを追加します。
2.Windowsのnslookupを実行します。
 >server 192.168.1.10
 >ls -d example.com
3.結果が表示されればマスターサーバの転送機能は動作しています。


/var/named/slaves のアクセス権がnamedでない
転送が成功しているのにファイルが保存されない場合は、スレーブ側に問題があります。
デフォルト時点なら問題ありませんが、いろいろいじくっているうちに、slaveディレクトリを再作成したなどの場合にハマることがあります。
#chown named:named /var/named/slaves




notifyの必要性

スレーブサーバは定期的にマスターサーバへ、ゾーンが更新されていないかを確認します。
すぐに更新したい場合は、スレーブ側で
#rndc retransfer example.com
と実行することで更新できます。

サーバが多いなどした場合は手間なので、notifyという機能を使用します。
これはマスター側でゾーンが更新されると、すぐにスレーブへ通知して、スレーブから取りにこさせます。
これがnotifyという設定ですが、必要ない場合もあります。

NSレコードに全てのスレーブサーバが記述されている場合

マスター側のnotifyは、デフォルトでyesです。記述されていなければ動作しています。
ゾーンの中にnsレコードとしてslaveサーバのアドレスが指定されている場合、通知先のnotify-alsoも不要です。

example.com..zoneファイルの中身
（略）
            IN   NS          ns1.example.com.
            IN   NS          ns2.example.com.     ←これが全て定義してあればnotify-alsoの指定はいらない
(略）


NSレコードに含まれないサーバへ通知を行う場合

ゾーンファイルの中に全てのスレーブサーバのNSレコードが含まれていない場合（例えば社内用に外部公開されていないスレーブサーバがある等）、notifyを記述します。
ゾーンごとに指定することも、optionで全体に指定することもできます。

マスター側のnamed.conf
(略)
//正引きゾーンの定義
zone "example.com" {
  type master;
  file "example.com.zone";
  allow-update {none;} ;
  allow-transfer { 192.168.1.11: };
   notify yes;                         //デフォルトでyes
  also-notify { 192.168.1.11; };  //通知する先のサーバアドレス
};

試験
スレーブ側でログの監視
#tail -f /var/log/message

マスター側でnamed.confの読み込み
#rndc reconfig

マスター側のゾーンの変更、シリアルの更新、ゾーンの更新
#vi /var/named/example.com/zone
   2017110402 :serial

マスター側でゾーンのリロード
#rndc reload example.com

スレーブ側のログで通知がなされたかを確認します。




prev.gif