DNSサーバの設定方法（on Fedora、CentOS）

●BINDの設定（chroot対応）

　Bind 9.9.1-P1からスレーブのゾーンファイルがテキスト形式からraw形式に変更されています。

　chrootに対応した設定方法を記載します。

# yum -y install bind bind-utils bind-chroot
# /usr/libexec/setup-named-chroot.sh /var/named/chroot on　←　chroot環境対応でない場合に実施
# systemctl stop named　←　chroot環境対応でない場合に実施
# systemctl disable named　←　chroot環境対応でない場合に実施
# systemctl start named-chroot
# systemctl enable named-chroot

　named-chrootが正常に起動できない場合は、bind、bind-utils、bind-chrootを削除し、その後/var/named/chroot以下のファイルを全て削除したほうが良いでしょう。
　chroot環境移行後は、/var/named/chroot以下に設定ファイルが保存されます。named.confは/var/named/chroot/etc/named.conf、ゾーンの設定ファイルは/var/named/chroot/var/named/以下となります。各設定ファイルは元の場所にも残りますがchroot 環境移行後に設定を変更する際はchroot以下のファイルを変更してください。

# ls -l /var/named/chroot/etc
合計 24
-rw-r--r-- 1 root root   333  8月 18 13:40 localtime
drwxr-x--- 2 root named    6  7月 29 10:05 named
-rw-r----- 1 root named 1582 10月 30  2013 named.conf
-rw-r--r-- 1 root named 2389  7月 29 10:05 named.iscdlv.key
-rw-r----- 1 root named  931  6月 21  2007 named.rfc1912.zones
-rw-r--r-- 1 root named  487  7月 19  2010 named.root.key
drwxr-x--- 3 root named   24  8月 18 13:40 pki
-rw-r----- 1 root named   77  8月 18 10:42 rndc.key
# ls -l /var/named/chroot/var/named
合計 16
drwxr-x--- 7 root  named   56  8月 18 13:40 chroot
drwxrwx--- 2 named named   22  8月 18 13:47 data
drwxrwx--- 2 named named   58  8月 18 13:48 dynamic
-rw-r----- 1 root  named 2076  1月 28  2013 named.ca
-rw-r----- 1 root  named  152 12月 15  2009 named.empty
-rw-r----- 1 root  named  152  6月 21  2007 named.localhost
-rw-r----- 1 root  named  168 12月 15  2009 named.loopback
drwxrwx--- 2 named named    6  7月 29 10:05 slaves

●BINDの設定（non-chroot）

　DNSサーバで使用するファイルを設定するため /var/named/chroot/etc/named.conf を編集します。

# vi /var/named/chroot/etc/named.conf
options {
	#listen-on port 53 { 127.0.0.1; };　←　コメントアウトする
	#listen-on-v6 port 53 { ::1; };　←　コメントアウトする
	directory 	"/var/named";
        　↑　下のzoneセンテンス中に出てくる設定ファイルの位置や
              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     { localhost; localnets; };
                            変更−−−−↑
                    （サーバ及び、サーバと同じネットワーク内のホストからの問合せのみ許可）
	recursion yes;
	version "UNKNOWN";　←　BINDのバージョンを隠す
	forwarders{
		192.168.0.254;　←　ルーター経由接続環境の場合はルーターのIPアドレスを指定
	};
	dnssec-enable yes;
	dnssec-validation yes;
	dnssec-lookaside auto;
	/* Path to ISC DLV key */
	bindkeys-file "/etc/named.iscdlv.key";
//	managed-keys-directory "/var/named/dynamic";
       managed-keys-directory "/var/na/ed/dynamic";
};
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};
zone "." IN {
	type hint;
	file "named.ca";
};
include "/etc/named.rfc1912.zones";
追加(ここから)
include "/etc/named.bigbang.mydns.jp.zone";
追加(ここまで)

●ルートゾーン最新化

　ルートゾーンは世界に13台しかないトップレベルドメインを管理するDNSサーバのIPアドレスを管理しているファイルで、めったに更新されることはないが、念のため最新化しておく。

# dig @a.root-servers.net . ns > /var/named/chroot/var/named/named.ca

●内部向けゾーンファイルの作成

# vi /var/named/chroot/etc/named.bigbang.mydns.jp.zones
zone "bigbang.mydns.jp" {
        type master;
        file "bigbang.mydns.jp.zone";
};
zone "0.168.192.in-addr.arpa" {
        type master;
        file "0.168.192.in-addr.arpa";
};

●内部向け正引きゾーンデータベース作成

注意
　ホスト名に使用できる文字は英数字とー（ダッシュ）のみです。

# vi /var/named/chroot/var/named/bigbang.mydns.jp.zone
$TTL	86400
@	IN	SOA	bigbang.mydns.jp.	root.bigbang.mydns.jp.(
				2008010101 ; Serial
				28800      ; Refresh
				14400      ; Retry
				3600000    ; Expire
				86400 )    ; Minimum
	IN	NS		ns1.bigbang.mydns.jp.
	IN	MX	10	mail1.bigbang.mydns.jp.
@	IN	A		192.168.0.2
　↑　サーバのプライベートIPアドレスを指定（bigbang.mydns.jp用）
*	IN	A		192.168.0.2
　↑　サーバのプライベートIPアドレスを指定（*.bigbang.mydns.jp用）
ns1	IN	A		192.168.0.2
mail1	IN	A		192.168.0.2　←　CNAMEで定義しない

　1行目に記述されている「$TTL」に注目します。TTLは、外部のDNSがあなたのドメイン情報を参照してキャッシュする際に、どれくらいの期間情報を保持するかを指定するものです。しかし、2行目から始まるSOAレコードと呼ばれるブロックにもTTLの記述があります。一見無駄な設定のように思えるかもしれませんが、大変重要な意味を持っています。これについては、後述の「 TTLとネガティブキャッシュ」を参照してください。
　ループバックアドレス用のゾーンのTTLは一度設定すれば、以降は変更する必要がないため長めに設定しても構いません。

●内部向け逆引きゾーンデータベース作成

# vi /var/named/chroot/var/named/0.168.192.in-addr.arpa
$TTL    86400
@	IN	SOA	bigbang.mydns.jp.	bigbang.mydns.jp.(
				2008010101 ; Serial
				28800      ; Refresh
				14400      ; Retry
				3600000    ; Expire
				86400 )    ; Minimum
	IN	NS	ns1.bigbang.mydns.jp.
2	IN	PTR	ns1.bigbang.mydns.jp.
2	IN	PTR	mail1.bigbang.mydns.jp.
　↑　サーバIPアドレス最下位部（192.168.0.2）とドメイン名を指定

●起動前のチェック

　実際にBINDを起動する前にnamed.confやゾーンファイルが文法的に間違っていないかチェックすることが可能です。named.confのチェックの際には以下のコマンドで実行します。

# named-checkconf -t /var/named/chroot -z /etc/named.conf
zone bigbang.mydns.jp/IN: loaded serial 2015081703
zone 0.168.192.in-addr.arpa/IN: loaded serial 2015081802
zone localhost.localdomain/IN: loaded serial 0
zone localhost/IN: loaded serial 0
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone 0.in-addr.arpa/IN: loaded serial 0
# named-checkzone "bigbang.mydns.jp" /var/named/bigbang.mydns.jp.zone
zone bigbang.mydns.jp/IN: loaded serial 2015081703
OK
# named-checkzone "192.168.0" /var/named/0.168.192.in-addr.arpa
zone 192.168.0/IN: loaded serial 2015081801
OK

　問題がなければOKが出力されます。

●BINDの自動起動

（CentOS 6の場合）
# chkconfig --level 2345 named on
（Fedora 21以降、CentOS 7以降の場合）
# systemctl enable named
（Fedora 21以降、CentOS 7以降の場合、chroot環境）
# systemctl enable named-chroot

　これで、サーバを再起動してもBINDは自動起動されるようになります。

●ファイアーウォールの除外設定

　ファイアーウォールを設定してい場合は53番ポートを開ける必要があります。

# vi /etc/sysconfig/iptables
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT 
-A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT 
# service iptables restart
# service iptables save

　53番ポートでも、UDPの設定し忘れが多いので注意してください。

●ゾーンデータベースの再読み込み

　正引きまたは逆引きゾーンデータベースを書き換えた場合は、必ずシリアル番号を増やし、BINDを再起動する必要があります。

（CentOS 6の場合）
# service named reload （または restart）
（Fedora 21以降、CentOS 7以降の場合）
# systemctl reload named
（Fedora 21以降、CentOS 7以降の場合、chroot環境）
# systemctl stop named　←　chroot環境対応でない場合に実施
# systemctl disable named　←　chroot環境対応でない場合に実施
# systemctl reload named-chroot

　問題なく稼働しているかどうかは、/var/log/messagesを確認してください。

●ルートゾーン自動更新

　1ヶ月に一度、ルートゾーンが最新かチェックし、更新されていればルートゾーンの最新化及び、BINDの再起動を自動的に行うようにする。
　※ルートゾーンが更新されていた場合のみ、新旧ルートゾーン情報及び、新旧ルートゾーンの差分情報をroot宛にメールする

# vi named.root_update　←　ルートゾーン最新化スクリプト作成
#!/bin/bash
new=`mktemp`
errors=`mktemp`
dig . ns @198.41.0.4 +bufsize=1024 > $new 2> $errors
if [ $? -eq 0 ]; then
    sort_new=`mktemp`
    sort_old=`mktemp`
    diff_out=`mktemp`
    sort $new > $sort_new
    sort /var/named/chroot/var/named/named.ca > $sort_old
    diff --ignore-matching-lines=^\; $sort_new $sort_old > $diff_out
    if [ $? -ne 0 ]; then
        (
         echo '-------------------- old named.root --------------------'
         cat /var/named/chroot/var/named/named.ca
         echo
         echo '-------------------- new named.root --------------------'
         cat $new
         echo '---------------------- difference ----------------------'
         cat $diff_out
        ) | mail -s 'named.root updated' root
        cp -f $new /var/named/chroot/var/named/named.ca
        chown named. /var/named/chroot/var/named/named.ca
        chmod 644 /var/named/chroot/var/named/named.ca
        which systemctl > /dev/null 2>&1
        if [ $? -eq 0 ]; then
            systemctl restart named-chroot > /dev/null
        else
            /etc/rc.d/init.d/named restart > /dev/null
        fi
    fi
    rm -f $sort_new $sort_old $diff_out
else
    cat $errors | mail -s 'named.root update check error' root
fi
rm -f $new $errors
# chmod 700 named.root_update
　↑　ルートゾーン最新化スクリプトへ実行権限付加
# mv named.root_update /etc/cron.monthly/
　↑　ルートゾーン最新化スクリプトを毎月自動実行されるディレクトリへ移動

●クエリーの制限

　BIND8、BIND9ともに、設定によって追加することが出きるセキュリティ設定がいくつかあります。セキュリティ設定のうち主なものをこれから解説します。
　"allow-query"、"allow-transfer"、"allow-update"、"allow-recursion"が参照するIPアドレスはアドレスリスト（address list）と呼ばれている。アドレスリストを指定する方法と意味を以下に示します。

パターン	意味
any	すべてのホスト
none	なし
localhost	自ホスト
localnet	自ホストが所属しているネットワーク
a.b.c.d[/m]	IPアドレスとネットマスクによる指定

　これらの書式の先頭に感嘆符"!"をつけると、パターンの反転となります。つまり"!any"は"none"と同じことになります。
　BINDでは、アドレスリストに加えて、アクセスコントロールリスト（Access Control List;ACLs）を利用することも出来ます。アクセスコントロールリストを利用して、頻繁に利用するIPアドレスやネットワークに対して名前を付けることによって、IPアドレスやネットワークに関する設定をより簡単にすることが出来ます。
　また、IPアドレスやネットワークに関する書き違えや、変更時に一括して変更できることによる設定の間違いを減らすことが出来ます。アクセスコントロールリストの書式を以下に示します。

acl <acl name> { a.b.c.d/m1; [e.f.g.h/m2]; ....};

　指定したIPアドレスやネットワークを、という名前に設定することが出来ます。IPアドレスやネットワークは続けて記述することが出来、複数のIPアドレスやネットワークを一つので指定することが出来ます。アクセスコントロールリストを利用して、クエリーを受け付けるホストを制限した例を以下に示します。

★　クエリー制限の例
# vi /etc/named.conf
acl private-net { 192.168.0.0/24; };
options {
中略
        allow-query { private-net; };
中略
};

　アクセスコントロールとアドレスリストのパターンを、混在して利用することも可能です。
　ゾーン転送を行うことによって、DNSサーバに保存されているゾーンデータベースの内容をすべて入手することが出来ます。ゾーン転送は本来セカンダリサーバに対して行われる処理であるが、手順に従えばどのホストからも行うことが可能です。しかしイントラネット環境などゾーンデータベースの内容が外部から参照できることは、セキュリティ上の弱点となる可能性がある。このような事態を防ぐために、ゾーン転送を行うことが出来ますホストを制限することが可能です。ゾーン転送の制限に関する設定は、/etc/named.confファイルで行う。以下にゾーン転送の制限を行う例を示します。

# vi /etc/named.conf
options {
中略
        allow-transfer {
                192.168.0.2;
        };
中略
};

　以上のように記述することによって、ゾーン転送を行うホストを192.168.0.2 のみに制限することが出来ます。ゾーン転送に関する制限が設定されない場合、すべてのホストからのゾーン要求を受け付けることになるため、出来るだけ設定することが望ましい。
　また、"allow-transfer"をoptionsステートメント内に記述することによって、すべてのゾーンに関してゾーン転送を制限することが出来ます。また、"allow-transfer"をzoneステートメント内に記述する場合、デフォルトとして利用されるoptions ステートメントに記述された内容に上書きする形で、そのゾーンに関してのゾーン転送の制限が行われます。
　通常の状態では、DNSサーバはすべてのホストからのDNS参照に対して応答します。通常の状態でもネットワーク資源の浪費となる可能性もありますが、場合によってはDNSサーバに対するDoS（Denital of Service）攻撃を受ける危険性があります。
　さらに、DNSキャッシュポイズニング攻撃の標的にされる可能性もあります。クエリーを受け付けるホストを限定したい場合、以下のような書式を利用します。

# vi /etc/named.conf
options {
中略
        allow-recursion {
                192.168.0.0/24;
        };
中略
};

　allow-recursionは、再帰（DNSサーバは各レベルを検索し、サーバからサーバへ移動して得られた情報を全てキャシュする）を完全に無効にするのではなく、LAN側だけに制限します。再帰を全面的に禁止したい場合は、セキュリティ的にもnamed.confのoptionsに、

recursion no;

と書く方がベストです。
　ただし、そうするとlocalhostを含む全てのLAN内のクライアントからの再帰を行わなくなるので注意が必要です。

# vi /etc/named.conf
options {
中略
        allow-query {
                192.168.0.0/24;
        };
中略
};

　クエリーを受け付けるホストを192.168.0.0/24で表されるIPアドレスを持ったホストに限定することが出来ます。このような設定をすることによって、クエリーを受け付けるホストを組織内のホストだけに限定するなどの設定を行うことが出来ます。
　また、"allow-query"をoptionsステートメント内に記述することによって、すべてのゾーンに関してクエリーを受け付けるホストを制限することが出来ます。allow-recursionとの違いは、ネームサーバが各ゾーンに対して権限を持つサーバではない場合は、見知らぬホストからのクエリーにはいっさい応答しません。
　つまり、allow-queryの方が厳しい制限となります。また、"allow-query"をzoneステートメント内に記述する場合、デフォルトとして利用されるoptionsステートメントに記述された内容に上書きする形で、そのゾーンに関してのクエリーを受け付けるホストの制限が行われます。
　逆に頻繁にDoS攻撃を仕掛けてくるホストなど、クエリーを無視するホストが明らかな場合には、"blackhole"サブステートメントを利用することが出来ます。"blackhole"サブステートメントでは、"allow-query"サブステートメントとは逆に、クエリーを無視するホストやネットワークを設定することが出来ます。"blackhole"の利用は以下のような記述で行います。

# vi /etc/named.conf
options {
中略
        blackhole {
            　172.16.0.0/24;
中略
        };
};

　以上のように記述することによって、IPアドレス172.16.0.0/24を持ったホストすべてからのクエリーを無視する設定となります。なお、"blackhole"はzoneステートメント内に記述することは出来ず、設定された"blackhole"はすべてのゾーンに対して適用されます。
　前に説明したように、ゾーンデータベースに登録するリソースレコードの１つにHINFO(Host Infomation）があります。ここには通常、ホストのオペレーティングシステム(OS)やハードウェアについて記述することになりますが、場合によっては悪意のあるユーザに対してホストの弱点を教えることになってしまいます。
　HINFOに関する情報は通常のDNS参照によって入手することが出来るため、前述のゾーン転送の制限では制限できません。このため、状況によってはゾーンデータベースにはHINFOに関する情報を記述しない方がよいことになります。ゾーンデータベースに記述された情報を補強するためのデータをゾーンデータベースに追加する場合には、コメント文などで追加した方が安全となります。
　同様の理由から、WKS（Well-Known Service）に関しても、上記の処理が必要になる場合があります。

●BINDのバージョンを隠す方法

BINDのバージョンを調べる方法

　BINDのバージョンを調べるには、バージョンを調べたいBINDが稼働しているサーバにログインしnamedコマンドを実行するか、BINDが稼働しているサーバにログインできない場合はdigコマンドを使うことで、BINDのバージョンを調べることができます。
　BINDが稼働しているサーバにログインできるのであれば、namedコマンドを-vオプションを付けて実行するとバージョンが表示されます。

$ named -v
BIND 9.3.4-P1

　BINDが稼働しているサーバにログインできなくても、digコマンドに次のようなオプションを付けて実行するとBINDのバージョンが表示できます。

$ dig @ネームサーバのアドレス chaos txt version.bind

　コマンドの例と、表示される内容の例

$ dig @192.168.1.1 chaos txt version.bind
; <<>> DiG 9.3.4-P1 <<>> @192.168.1.1 chaos txt version.bind
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52347
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind.                  CH      TXT
;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.3.2"
;; AUTHORITY SECTION:
version.bind.           0       CH      NS      version.bind.
;; Query time: 1 msec

　ANSWER SECTION:の部分にバージョンが表示される。この例だとバージョンは9.3.2になります。

BINDのバージョンを隠す方法

　BINDのバージョンを隠すには、named.confのoption{};に次の行を追加しnamedを再起動します。

options {
	version "表示させたい文字列";
};

　例えば、次のようにします。（version ""; のように何も書かない設定でもよし。）

options {
	version "Unknown";
};

　実際にdigコマンドを使ってどのように表示されるか確認すると、ANSWER SECTION:に"Unknown"を表示されるのが確認できます。（version ""; とした場合は、""と表示されます。）

$ dig @192.168.1.1 chaos txt version.bind
; <<>> DiG 9.3.4-P1 <<>> @192.168.1.1 chaos txt version.bind
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12725
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind.                  CH      TXT
;; ANSWER SECTION:
version.bind.           0       CH      TXT     "Unknown"
;; AUTHORITY SECTION:
version.bind.           0       CH      NS      version.bind.
;; Query time: 1 msec

●BINDのログ

　BIND には、named.confにloggingステートメントを記述しておくことでネームサーバのログ出力をより広範に制御することができるようになります。channelで出力先を選択し、categoryで出力フォーマットとseverity（重要度）を指示します。named.confにはデフォルトではloggingステートメントが記述されていませんが、デフォルトでもloggingの機能は設定されており、categoryとchannel共にデフォルト値が存在します。
　まず、named.confに何も設定しなかった時のデフォルトのログ設定を以下に記します。unmatchedは、どのviewにもマッチしなかったメッセージのことで、デフォルトでは、null（ログを出力しない）が指定されています。

logging
   category "unmatched" { "null"; };
   category "default" { "default_syslog"; "default_debug"; };
};

　以下は、標準で用意されているデフォルトのchannel設定です。channel指定には、file、syslog、stderr、nullのいずれかの指定が必要です。fileは指定したファイルにログを出力し、syslogはsyslogに、stderrは標準エラー出力にそれぞれ出力します。

//syslogデーモンに出力する
channel "default_syslog" {
   syslog daemon;
   severity info;
};
//named.runへ出力する
channel "default_debug" {
   file "named.run";
   severity dynamic;
};
//標準エラーに出力する
channel "default_stderr" {
   stderr;
   severity info;
};
//ログを出力しない
channel "null" {
   null;
};

●カテゴリ

カテゴリ名	説明
default	チャンネルが割り当てられていない全てのカテゴリ。
general	以下のカテゴリに分類されない、その他全てのメッセージ
database	namedの内部データベースに関するメッセージ。
security	要求の承認と拒否に関するメッセージ。
config	設定ファイルの処理に関するメッセージ。
resolver	名前解決に関するメッセージ。再帰的に問い合わせへの応答も含む。
xfer-in	他サーバーから自ホストへのゾーン転送に関するメッセージ。
xfer-out	自ホストから他サーバーへのゾーン転送に関するメッセージ。
notify	非同期びゾーン更新通知に関するメッセージ。
client	クライアントからの要求に関するメッセージ。
unmatched	どのview にもマッチしなかったメッセージ。
network	ネットワークに関するメッセージ。
upadate	動的更新に関するメッセージ。
queries	問い合わせのログ。
dnssec	DNSSECとTSIGの処理に関するメッセージ。
lame-servers	名前解決を試みようとして発見した、間違った設定のサーバーに関するメッセージ。

●チャンネル設定の書式

file <ファイル名> [ versions <バージョン番号> ] [ size <サイズ指定> ] ;
　syslog <機能分類>;
　stderr;
　null;
　　[ severity <重要度>;]
　　[ print-category <真偽値>;]
　　[ print-severity <真偽値>;]
　　[ print-time <真偽値>;]
<機能分類> = kern、user、mail、daemon、auth、syslog、lpr、news、uucp、cron、
　　　　　　　　　　authpriv、ftp、local0～local7
<重要度> = critical、error、warning、notice、info、debug、dynamic
<真偽値> = yes | no
<サイズ指定> = <数値> [ K | M | G }

　ログを格納するディレクトリを作成します。BIND が出力するログを標準の/var/log/messagesではなく、専用のディレクトリを作成し、その中に格納していくこととします。

# mkdir /var/named/log
# chown named.named /var/named/log

　以下では、BINDに関するログを全て同一ファイルに記録するような設定をしてみます。まず、channelでチャネル名を任意に定義します。ここでは、"default-log"という名前をつけ、そのファイルを、/var/named/log/default.logに出力するように指定しています。"version"は、指定した数字の数だけログを保存するという意味で、namedを再起動したり、リロードしたりすることによってログファイルを自動的にローテーションします。ここでは、5 と指定しているのでログ数5つの中でローテーションされます。ログのサイズを指定した場合、ログサイズが最大サイズに達した時点でログの出力を停止します。注意したいのは、指定したサイズに達してもログのローテーションを行わないということです。
　次にcategoryの設定を行います。ロギングは、channelを定義したからといってログ機能が動作するわけではなく、categoryが指定されてはじめてログ出力を行うようになります。以下の例では、"category default "（上記表参照）の出力を、channelの default-logで定義したとおりにログを出力する、という設定になっています。

ログを一括して出力する例

logging {
        channel "default-log" {
                file "/var/named/log/default.log" versions 5 size 10M;
                severity debug;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
		
        category default { "default-log"; };
};

　最後に、printについて解説します。print-timeは、時刻を、severityは重要度を出力し、categoryはログカテゴリの表示・非表示を切り替えます。

Jun 12 05:29:32.291 general: debug 1: zone_timer: zone version.bind/CH: enter

ロギングの応用例

logging {
        channel "default-log" {
                file "/var/named/log/default.log" versions 3 size 5M;
                severity debug;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
		
        channel "xfer-in-log" {
                file "/var/named/log/xfer-in.log" versions 3 size 5M;
                severity debug;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
		
        channel "xfer-out-log" {
                file "/var/named/log/xfer-out.log" versions 3 size 5M;
                severity debug;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
		
        channel "queries-log" {
                file "/var/named/log/queries.log" versions 3 size 5M;
                severity info;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
		
        category default { 
               "default-log";
               "default_syslog";
               "default_debug";
               "default_stderr";
        };
        category xfer-in { 
               "xfer-in-log";
        };
        category xfer-out { 
               "xfer-out-log";
        };
        category queries { "queries-log"; };
        category lame-servers { null; };
};

　channelやcategoryは複数指定できるため、上記のような設定にして、ログを役割ごとに分散させることもできます。まず、category default では、同じデフォルトでも、ログレベル（severity)の異なるログを出力しています。ひとつめとして、ログレベルがdebugのdefault-allを指定し、channel "default-log"で定義したログ出力方法に従います。default_syslogとdefault_debug、default_stderrでは、BINDの標準出力場所へ出力します。default_syslogならば、/var/log/messagesに出力されます。けれども、default-allよりは詳細なログを出力しません。
　次に、category xfer-inとcategory xfer-outです。category xfer-inでは、他サーバーから自ホストへのゾーン転送を行った際のログを出力し、その出力場所として、channel "xfer-in-log"で指定した場所に従います。同様に、自ホストから他サーバーへのゾーン転送に関するメッセージは、channel "xfer-out-log"に従ってログが出力されます。つまり、xfer-in.logと xfer-out.logのふたつのログが作成されることになります。
　category queriesは、問い合わせに関するログを出力します。これを指定することで、攻撃元を容易に特定することもできるようになります。ただし、全クエリーを出力するため、指定する場合はサーバーのリソース消費にも気を配りましょう。
　category lame-serversは誤った設定がなされたサーバーに関する逆引きエラーを出力しないように、nullを指定しています。

●セキュアなnamed.conf設定例

　BIND9のnamed.confの設定例を以下に示します。

acl localnet {　←　aclでアクセスコントロールリストを作る
    192.168.0.0/24;
    127.0.0.1;
};
logging {　←　loggingでlogにはかれるlame serverの煩わしい文字列をはじく
    category lame-servers { null; };
};
options {
    directory "/var/named";
    auth-nxdomain yes;
    allow-recursion {
        192.168.0.0/24;
        };
    allow-query {　←　クエリーの利用するホストを定義
        localnet;
    };
    allow-transfer {　←　ゾーン転送の制限を定義
        localnet;
        ***.***.***.***;
    };
    version "Unknown";
    lame-ttl 1800;　←　lame-server logの保存期間
};
zone "." {
    type hint;
    file "named.ca";
};
zone "0.0.127.in-addr.arpa"{
    type master;
    file "named.local";
};
zone "example.com"{
    type master;
    file "example.com.zone";
    allow-query { any; };　←　クエリーによる名前解決を許可
};
zone "***.***.***.in-addr.arpa"{
    type master;
    file "named.rev";
    allow-query { any; };　←　クエリーによる名前解決を許可
};

　これは、named.confの外向き設定例です。

●家庭内DDNSの設定

　参考URL：はじめての自宅サーバ構築 - Fedora/CentOS - DHCPサーバとDNSサーバの連携
　参考URL：CentOS7でdhcpとbindを連携させ家庭内DDNS

　DHCPサーバの設定ファイルの編集

　DHCPサーバは構築済みとします。
　DHCPサーバの設定ファイルを編集します（編集した部分のみ記載）。下記のように変更

ddns-update-style none;
　↓
ddns-update-style interim;

下記11行を追加。
# Dynamic DNSのための追加設定(DNSサーバの設定ファイル「ZONE名」と合わせること。)
# 正引きゾーン
zone bigbang.mydns.jp {
    # DNSサーバのアドレスを設定
    primary 192.168.0.1;
}
# 逆引きゾーン
zone 0.168.192.in-addr.arpa {
    # DNSサーバのアドレスを設定
    primary 192.168.0.1;
}

　BINDの設定ファイルの編集

　DNSサーバは構築済みとします。
　BINDの設定ファイルを編集します（編集した部分のみ記載）。

zone "bigbang.mydns.jp" {
	type master;
	file "bigbang.mydns.jp.zone";
};	
　↓
zone "bigbang.mydns.jp" {
	type master;
	file "bigbang.mydns.jp.zone";
	# Dynamic DNS機能を付加(更新するサーバのIPアドレスを指定)
	allow-update { localhost; localnets; };
};	

zone "0.168.192.in-addr.arpa" {
	type master;
	file "0.168.192.in-addr.arpa";
};

zone "0.168.192.in-addr.arpa" {
	type master;
	file "0.168.192.in-addr.arpa";
	# Dynamic DNS機能を付加(更新するサーバのIPアドレスを指定)
	allow-update { localhost; localnets; };
};

　DNSサーバのDirectoryのアクセス権変更

　DNSサーバが起動するプロセスは「named」ユーザで起動します。
　しかし、DNSサーバ(bind)をインストールしたデフォルトのZONEファイル配置ディレクトリ「/var/named」のアクセス権は750 、所有者・グループはroot:namedとなっているためnamedではファイル更新ができません。
　プロセスがZONE情報を更新できるように、アクセス権を変更します。

# chmod -R g+w /var/named/

chrootを使用している場合は、以下のパスとファイルが「named」で書き込み出来るようにアクセス権を変更してください。
　　/var/named
　　/var/named/chroot
　　/var/named/chroot/var
　　/var/named/chroot/var/named
　　/var/named/chroot/var/named/ゾーンファイル
　　ゾーンファイル：正引き・逆引きファイル

　DHCP・DNSサーバの再起動

　DHCPサーバとDNSサーバを再起動します。

# systemctl restart dhpcd
# systemctl restart named-chroot

　DNSサーバ更新テスト

　nsupdateを使用してDNSサーバーを更新をテストするにはbind-utilsをインストールし、nsupdateコマンドを実行します。実行すると対話型コンソールになりますので下記のように入力します。何もエラーが出なければ問題ありません。

>server 127.0.0.1
>update add test.bigbang.mydns.jp. 3600 A 192.168.0.22
>send
>server 127.0.0.1
>update delete test.bigbang.mydns.jp.
>send

　BIND9でDynamic DNSを実行させると動的に更新されたレコードはジャーナル (*.jnl) に記録されます。そのため、ゾーンファイルを確認しても現在のゾーン情報を確認できません。
　したがって、rndcでdumpして現在のDNSレコードを確認する必要があります。

# rndc dumpdb -zones
# cat /var/named/data/cache_dump.db | grep test.bigbang.mydns.jp.

　DHCPとDNSの動作確認

　LinuxをDHCPクライアントとして設定し、DHCPサーバから付与されたIPアドレスがDNSサーバに登録されるか確認します。

# less /var/log/messages
Dec 13 13:30:17 server1 dhcpd: DHCPREQUEST for 192.168.0.31 from 00:**:**:**:**:** via eth1
Dec 13 13:30:17 server1 dhcpd: DHCPACK on 192.168.0.31 to 00:**:**:**:**:** (fedora30-3) via eth1
Dec 13 13:30:17 server1 named[29278]: zone bigbang.dyndns.org/IN: sending notifies (serial 201912130010)
Dec 13 13:30:17 server1 dhcpd: Added new forward map from test.bigbang.mydns.jp to 192.168.0.31
Dec 13 13:30:17 server1 named[29278]: zone 0.0.1.in-addr.arpa/IN: sending notifies (serial 201912130010)
Dec 13 13:30:17 server1 dhcpd: Added reverse map from 31.0.168.192.in-addr.arpa. to test.bigbang.mydns.jp

# rndc dumpdb -zones
# cat /var/named/data/cache_dump.db | grep test.bigbang.mydns.jp.
31.0.0.1.in-addr.arpa.			3600 IN PTR	test.bigbang.mydns.jp.
test.bigbang.mydns.jp.			3600 IN A	192.168.0.31

　正引き、逆引きゾーンともに登録されています。
　ジャーナルファイルも更新されていることが分かります。

# ls -l /var/named/
-rw-r--r--  1 named named 1316 12月 13 13:30 0.168.192.in-addr.arpa.jnl
-rw-r--r--  1 named named 1739 12月 13 13:30 bigbang.mydns.jp.zone.jnl

●digコマンド

　digの書式

　基本的に、dig以降の引数の順番は関係ありません。詳細は、dig -hやman digで確認できます。

[ 書式 ]
　dig [ digオプション ] [ @問い合わせ先ネームサーバ ] 検索ドメイン [ レコードタイプ ]　[ 問い合わせオプション ]

[ 問い合わせオプション ]
　-4    IPv4で問い合わせます（IPv6で問い合わせしない）。
　-6    Pv6で問い合わせます。ただし、IPv6で接続できない場合はIPv4で問い合わせます。
　-p    ポート番号　デフォルトの53ではなく指定したポートへ問い合わせます。

[ ＠問い合わせ先ネームサーバ ]
　問い合わせを行うネームサーバ名を指定します。IPアドレスでも可能。
　省略した場合は、/etc/resolv.confでnameserver行で指定するネームサーバに問い合わせます。
　複数のnameserver行がある場合は、最初のnameserver行を使います。

[ 検索ドメイン名 ]
　問い合わせるドメイン名、またはホスト名を指定します。
　IPv4の逆引きの場合はin-addra.arpaドメイン、IPv6の逆引きの場合はip6.arpaドメインを使用します。ただし、-x IPアドレスとすることもできます。

[ レコード ]
　問い合わせるレコードの種類
　soa、ns、mx、a、ptr、cname、txt、any、axfrなど省略時はaレコードとなります。ただし、-x IPアドレスを検索する場合のデフォルトはptrとなります。

[ digオプション ]

オプション	説明
+norec	問い合わせ先ネームサーバに対して、再帰問い合わせはしないように指示
+vc	最初からTCPで問い合わせる
+tcp	+vcと同様
+ignore	TC=1ビットが返ってきてもTCPで再度問い合わせずに終わる(つまり、TCPフォールバックしない）
+bufsize=数値	EDNS0を有効にし、こちら側の最大受信UDPサイズを指定する
+dnssec	EDNS0を有効とするとともに、DNSSECで問い合わせる
+multiline	出力結果を整えてくれる　(+dnssecと一緒につけると良いかも）
+trace	ルートDNSから問い合わせて、結果を順番に出力
+short	回答のあったレコードのうち、右辺部分だけを表示
<+nottlid/td>	レコードのTTLの部分を表示しない
+noall	何も表示しない
+answer	+noallがあるとき、ANSWER SECTIONを表示 (+aｌl +answerは意味がない） +anや+ansの省略形も可
+authority	+noallがあるとき、AUTHORITY SECTIONを表示（同上）　+authや+auの省略形も可
+additional	+noallがあるとき、ADDITIONAL SECTIONを表示（同上）　+addの省略形も可

　digオプションの順番について

　digオプションは、その順番や位置によって表示内容が異なってくるので注意します。digの後にdigオプションをつけたほうがよけいな（と個人的に思う）3行が出力されないので良いと思います。

# dig +noall @127.0.0.1 www.yahoo.co.jp	+noallを最初につけた場合 noallが評価されて何も表示しない
# dig @127.0.0.1 www.yahoo.co.jp +noall ; <<>> DiG 9.7.3-P3 <<>> @127.0.0.1 www.yahoo.co.jp +noall ; (1 server found) ;; global options: +cmd	+noallを最後につけた場合、左記の3行だけ表示され、そのほかはnoallが評価されて何も表示しない
# dig +noall +answer @127.0.0.1 www.yahoo.co.jp www.yahoo.co.jp. 875 IN CNAME www.ya.gl.yahoo.co.jp. www.ya.gl.yahoo.co.jp. 35 IN A 124.83.187.140	+noall +answerにした場合、noallの後でanswerが適用されるので、回答節だけ表示される →　いったん全部非表示、でもanswerだけ表示
# dig +answer +noall @127.0.0.1 www.yahoo.co.jp	+answer +noallにした場合、answerの後でnoallが適用されるので、何も表示されない →　answer表示、でも全部非表示
# dig @127.0.0.1 www.yahoo.co.jp +noall +answer ; <<>> DiG 9.7.3-P3 <<>> @127.0.0.1 www.yahoo.co.jp +noall +answer ; (1 server found) ;; global options: +cmd www.yahoo.co.jp. 864 IN CNAME www.ya.gl.yahoo.co.jp. www.ya.gl.yahoo.co.jp. 24 IN A 124.83.187.140	+noall +answerを最後につけた場合、左記の3行のあと、その他はnoallの後でanswerが適用される

●レコードの確認

SOAレコードの確認

　digでは、DNSサーバを「@」に続けて指定します。ここではローカルホストへの問い合わせになるよう、「127.0.0.1」または「localhost」を指定します。/etc/resolv.confでネームサーバを自分自身にしている場合（注）は省略可能です。

注：DNSサーバに自分自身を指定する場合は、/etc/resolv.confに次のような記述が必要です。
domain example.jp
nameserver 127.0.0.1

　さらに、調べたいドメインとレコードを指定します。引数の順序に決まりはありません。

$ /usr/local/bin/dig @127.0.0.1 example.jp soa
; <<>> DiG 9.2.1 <<>> @127.0.0.1 example.jp soa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11327
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;example.jp.                    IN      SOA
;; ANSWER SECTION:
example.jp.             86400   IN      SOA     dns.example.jp. 
root.example.jp. 2002122001 3600 900 604800 86400
;; AUTHORITY SECTION:
example.jp.             86400   IN      NS      dns.example.jp.
;; ADDITIONAL SECTION:
dns.example.jp.         86400   IN      A       192.168.10.1
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 22 20:16:30 2002
;; MSG SIZE  rcvd: 103

NSレコードの確認

　同様に、NSレコードを確認してみます。レコードオプションに「ns」を指定してdigを実行します。

$ /usr/local/bin/dig @127.0.0.1 example.jp ns
;; QUESTION SECTION:
;example.jp.                    IN      NS
;; ANSWER SECTION:
example.jp.             86400   IN      NS      dns.example.jp.
;; ADDITIONAL SECTION:
dns.example.jp.         86400   IN      A       192.168.10.1

正引き情報の確認

　digの引数に、調べたいドメインではなくホスト名をフルドメイン付き（FQDN）で指定します。Aレコードを調べる場合は、「a」を指定します。ちなみに、Aレコードの場合は指定を省略できます。

$ /usr/local/bin/dig @127.0.0.1 dns.example.jp a
;; QUESTION SECTION:
;dns.example.jp.                        IN      A
;; ANSWER SECTION:
dns.example.jp.         86400   IN      A       192.168.10.1
;; AUTHORITY SECTION:
example.jp.             86400   IN      NS      dns.example.jp.

逆引き情報の確認

　digでは通常、引数にドメイン名が来ることを期待します（つまりドメイン名指定がデフォルト）。IPアドレスを指定する場合は、「-x」オプションを使います。
　Aレコードを調べる場合は、レコードオプションに「a」を指定し、これは省略可能だと説明しました。しかし、ここでは意図的に省略します。レコードオプション「a」を指定したときとそうでないときの挙動の違いを一度自分で確認してみましょう。どうしてそのような違いが生じるのかは、次回で説明します。

$ dig @127.0.0.1 -x 192.168.10.1
;; QUESTION SECTION:
;1.10.168.192.in-addr.arpa.     IN      PTR
;; ANSWER SECTION:
1.10.168.192.in-addr.arpa. 86400 IN     PTR     dns.example.jp.
;; AUTHORITY SECTION:
10.168.192.in-addr.arpa. 86400  IN      NS      dns.example.jp.
;; ADDITIONAL SECTION:
dns.example.jp.         86400   IN      A       192.168.10.1

キャッシュサーバの動作確認

　最後にキャッシュサーバの動作を確認します。外部のドメインを指定して、DNSが引けているかを確認します。

$ dig @127.0.0.1 www.hoge.co.jp
;; QUESTION SECTION:
;www.hoge.co.jp.           IN      A
;; ANSWER SECTION:
www.hoge.co.jp.    85877   IN      CNAME    www.hoge.co.jp.
www.hoge.co.jp. 85877 IN   A       192.168.0.100
;; AUTHORITY SECTION:
hoge.co.jp.        85877   IN      NS      ns1.kokosu.ne.jp.
hoge.co.jp.        85877   IN      NS      dns1.kokosu.ne.jp.
hoge.co.jp.        85877   IN      NS      dns2.kokosu.ne.jp.

●逆引きの問い合わせについて

-x オプションを使用すると楽

　IPv4アドレス

例） 124.83.179.227( = f10.top.vip.ogk.yahoo.co.jp )のPTRレコードを問い合わせる

[ 使用例 ]
-xオプションを使用しない場合

# dig 227.179.83.124.in-addr.arpa ptr
;; QUESTION SECTION:
;227.179.83.124.in-addr.arpa. IN PTR
：
;; ANSWER SECTION:
227.179.83.124.in-addr.arpa. 675 IN PTR f10.top.vip.ogk.yahoo.co.jp.

in-addr.arpaドメインでかつPTRを指定して問い合わせる
PTRを省くとAレコードを問い合わせる

-xオプションを使用する場合

# dig -x 124.83.179.227
;; QUESTION SECTION:
;227.179.83.124.in-addr.arpa. IN PTR
：
;; ANSWER SECTION:
227.179.83.124.in-addr.arpa. 900 IN PTR f10.top.vip.ogk.yahoo.co.jp.

そのままアドレスをつけて問い合わせる
デフォルトでPTRを問い合わせる

　IPv6アドレス

例） 2001:dc2:1000:2006::cafe( = www.nic.ad.jp )のPTRレコードを問い合わせる

[ 使用例 ]
-xオプションを使用しない場合

# dig @ns5.nic.ad.jp e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa ptr
;; QUESTION SECTION:
;e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa. IN PTR
：
;; ANSWER SECTION:
e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa. 86400 IN PTR www.nic.ad.jp.

ip6.arpaドメインでかつPTRを指定して問い合わせる
アドレスは完全形式で指定

-xオプションを使用する場合

# dig @ns5.nic.ad.jp -x 2001:dc2:1000:2006::cafe
;; QUESTION SECTION:
;e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa. IN PTR
：
;; ANSWER SECTION:
e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa. 86400 IN PTR www.nic.ad.jp.

デフォルトでPTRを問い合わせる
アドレスは省略形式でも良い

●TCPによる問い合わせ

　通常、DNSの問い合わせはUDP53番宛に対して行われ、TC=1のビットが返ってきた場合は改めてTCP53番宛に問い合わせるようになっています（TCPフォールバック）。
　しかし、digの+vcオプションを使用すると、いきなりTCP53番で問い合わせることができます。
　問い合わせ先DNSサーバ（またはその手前にあるFWなど）がTCP53番を許可しているかどうかを調べるのによく利用します。TCP53番は、DNS問い合わせ以外にもゾーン転送でも利用しているので、ゾーン転送不可の原因を調べるのに役立ちます。

[ 使用例 ]

# dig @192.36.144.107 se. any ;; Truncated, retrying in TCP mode. ： ;; MSG SIZE rcvd: 2716	通常はUDPで問い合わせ、応答サイズが512バイトを超えるとTCPに切り替わる「;; Truncated, retrying in TCP mode.」は、TCPに切り替わったことを意味する
# dig @192.36.144.107 se. any +vc ： ;; MSG SIZE rcvd: 2716	+vcを付加すると、最初からTCPで問い合わせるサイズとEDNS0に関するコメントがないことから、UDPではなくTCPだとわかる +vcなしで応答があり、+vc付きでtime outになる場合は、サーバ側でTCP53番の着信を許可していない可能性有り
# dig @192.168.24.60 example.co.jp axfr ： ;; XFR size: 518 records (messages 1, bytes 8384)	axfr(ゾーン転送)オプションでもTCP接続となる
# dig @192.168.24.60 example.co.jp axfr ： ;; connection timed out; no servers could be reached	192.168.24.60のほうで、named.confではゾーン転送を許可しているが、iptablesで外部からのTCP53を許可していない場合しばらくたってからtime outになる

●EDNS0による問い合わせ

　EDNS0とは、応答サイズが512バイトを超えてもUDPで回答できるようにした拡張機能のことです。EDNS0での最大UDPサイズは4096バイトで、これを超える場合はTCPフォールバックによりTCPで再問い合わせが行われます。digの+bufsizeオプション、または+dnssecオプションを使うと、EDNS0を有効にすることができます。

[ 使用例 ]

# dig @192.36.144.107 se. any +bufsize=4096 ： ; EDNS: version: 0, flags:; udp: 4096 ： ;; MSG SIZE rcvd: 2727	+bufsize=数値は、相手のサーバにこちら側の受信可能サイズを通知する。相手サーバは、自分自身の最大送信サイズと比較して小さいほうを採用し、応答結果がそのサイズ内に収まる場合はUDPで返す。それを超える場合はTC=1をつけた上でUDPで返し、TCPフォールバックされる。
# dig @192.36.144.107 se. any +bufsize=2000 ;; Truncated, retrying in TCP mode. ： ; EDNS: version: 0, flags:; udp: 4096 ： ;; MSG SIZE rcvd: 2727	応答サイズが2727バイトに対して、こちら側の受信サイズを2000バイトとして実行した場合、受信サイズを超過してるので、TCPフォールバックが起こる
# dig @192.36.144.107 se. any +dnssec ： ; EDNS: version: 0, flags: do; udp: 4096 ： ;; MSG SIZE rcvd: 4023	+dnssecをつけてもEDNS0が有効になる。+dnssecだけの場合は、+bufsize=4096がデフォルト

●DNSSECによる問い合わせ

DNSSECで問い合わせる場合は、+dnssecオプションを付加します。+dnssecオプションを付加すると、自動的にEDNS0も有効になります（最大サイズ4096バイトに設定）。+bufsizeも併用してEDNS0の最大受信サイズを指定することもできます。

[ 使用例 ]

# dig @localhost se. any +dnssec ： ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 26, AUTHORITY: 11, ADDITIONAL: 20 ： ; EDNS: version: 0, flags: do; udp: 4096 ： ;; MSG SIZE rcvd: 4094	+dnssecを付加するとEDNS0も有効になる。DNSSECによる検証に成功した場合は、adフラグが立つ。ローカルDNSに設定されているトラストアンカーはルートサーバで、ルートサーバから辿ってDNSSEC認証ができたことを示す。
# dig @192.36.144.107 se. any +dnssec ： ;; flags: qr aa rd; QUERY: 1, ANSWER: 23, AUTHORITY: 0, ADDITIONAL: 23 ： ; EDNS: version: 0, flags: do; udp: 4096 ： ;; MSG SIZE rcvd: 4023	ローカルDNSが設定しているトラストアンカーはルートサーバのみなので、直接seを管理するDNSサーバに問い合わせてもDNSSEC検証ができないのでadフラグは立たない。
# dig @localhost se. any +dnssec +bufsize=2000 ;; Truncated, retrying in TCP mode. ： ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 26, AUTHORITY: 11, ADDITIONAL: 17 ： ; EDNS: version: 0, flags: do; udp: 4096 ： ;; MSG SIZE rcvd: 4448	+bufsizeで2000バイトに制限した場合DNSSEC問い合わせでも、指定したEDNS0の受信サイズを超えればTCPフォールバックされる。

●BINDのバージョンの確認

　digを使ってBINDのバージョンの確認ができます。

# dig @192.168.24.60 chaos version.bind txt ： ;; QUESTION SECTION: ;version.bind. CH TXT ： ;; ANSWER SECTION: version.bind. 0 CH TXT "9.7.3-P3"	バージョンの問い合わせ<。named.confでversionの設定がされていない場合は、BINDのバージョンを返す
# dig @192.168.24.60 chaos version.bind txt ： ;; QUESTION SECTION: ;version.bind. CH TXT ： ;; ANSWER SECTION: version.bind. 0 CH TXT "Not available."	options { version "Not available."; };のように、named.confで設定されている場合は、digではバージョンの確認ができない。
# rndc status version: 9.7.3-P3 (Not available.) CPUs found: 1 worker threads: 1 number of zones: 20 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON recursive clients: 0/2900/3000 tcp clients: 0/100 server is up and running	rndcコマンドであれば、named.confでバージョンを隠してもきちんと表示される

●ルートDNSのトラストアンカーを取得する

　DNSSEC対応の設定に必要なトラストアンカー（KSK公開鍵）を取得します。

# dig +noall +answer @a.root-servers.net . dnskey > /tmp/trust-key.txt
# more /tmp/trust-key.txt
. 172800 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
. 172800 IN DNSKEY 256 3 8 AwEAAcy4Eo1P5B3ut9Vm9ZP92JnCFSALJqdhO5fOq1UsseYaiMFqgDH6 Y40iqDw6JmpkmhiJLW6HGj//JLQXAJ+k4EcQ9tlDJqumEe7OJMU6KpcK s6qI4lugy8j/v6DxDlZdAPASbKmoGx1oceRKzr/UdwyB1G5aIEtwK7/D QFrn3zRj

ルートDNSからDNSKEYレコードを取得。トラストアンカーはKSK公開鍵のほうなので、DNSKY 257のほうを使う。

●権威DNSサーバのDNSSEC対応

　参照
　第4回権威DNSサーバのDNSSEC対応

キャッシュサーバのDNSSEC対応
KSKの作成
ZSKの作成
ゾーンの署名
権威サーバのDNSSEC対応
DSの上位サーバへの登録依頼

　なお、KSK(Key Signing Key)はZSKに署名するための鍵、ZSK(Zone Signing Key)はゾーンのレコードに署名するための鍵です。
　また、DS(Delegation Signer)はKSK公開鍵から求められる情報です。
　実運用時には定期的にKSK、ZSKを更新し再署名、DSの再登録が必要となります。KSK、ZSKそれぞれについて事前公開法/二重署名法のどちらかを選択して行うなど複雑な作業になります。
　また、注意深く行わないと最悪すべてのレコードの署名が不正となってしまいます。

　では、KSK及びZSKを作成します。

# mkdir /var/named/keys
# chown named:named /var/named/keys
# chmod 770 /var/named/keys

$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 2048 -r /dev/urandom -f KSK -P 20121220000000 -A 20121220000000 -I 20171231000000 bigbang.mydns.jp
Generating key pair.................................................+++ ..........+++
Kbigbnag.dyndns.org.+008+44500

ZSKの作成は下記のとおり
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20121220000000 -A 20121220000000 -I 20171231000000 bigbang.mydns.jp
Generating key pair........++++++ .........................++++++
Kbigbang.mydns.jp.+008+46530

　「key-signing key」と記載があるのががKSK鍵、「key-signing key」と記載があるのがZSK鍵になります。

　管理しているゾーンに対して署名します。/var/named/keys以下に鍵が複数ある場合は、その数だけ署名されることになります。

# mkdir /var/named/zone
# chown named:named /var/named/zone
# chmod 770 /var/named/zone

# dnssec-signzone -a -S -x -K /var/named/keys -z -d /var/named/zone -3 1234567890 -e +5y -r /dev/urandom -N unixtime -o bigbang.mydns.jp /var/named/chroot/var/named/（署名したいファイル名）
Fetching KSK/ZSK 49804/RSASHA256 from key repository.
dnssec-signzone: warning: Serial number not advanced, zone may not transfer
Verifying the zone using the following algorithms: RSASHA256.
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 present, 0 revoked
/var/named/chroot/var/named/（署名したいファイル名）.signed

# chgrp named /var/named/chroot/var/named/（署名したいファイル名）.signed

　署名されたゾーンファイルを利用するように「named.conf」を変更します。

マスタDNSサーバのゾーンファイルの変更
zone "bigbang.mydns.jp" {
        type master;
        file "bigbang.mydns.jp.zone";
};
　↓　変更
zone "bigbang.mydns.jp" {
        type master;
        file "bigbang.mydns.jp.zone.signed";　←　変更
};

　設定完了後、namedを再起動します。この時、下記コマンドを実行しておかないとnamedサービスが起動しませんので注意してください。

# chgrp named /var/named/chroot/var/named/bigbang.mydns.jp.zone.signed

　セカンダリDNSサーバがある場合は、そちらの「named.conf」も変更します。

セカンダリDNSサーバのゾーンファイルの変更
zone "bigbang.mydns.jp" {
        type slave;
        file "slaves/bigbang.mydns.jp";
        masters { 192.168.0.100; } ;
        };
　↓　変更
zone "bigbang.mydns.jp" {
        type slave;
        file "slaves/bigbang.mydns.jp.signed";　←　変更
        masters { 192.168.0.100; } ;
        };

　設定完了後、namedを再起動します。

　DNSSECが有効になっているか、digコマンドにより確認します。

# dig bigbang.mydns.jp -t NS +dnssec

; <<>> DiG 9.8.4-RedHat-9.8.4-2.fc16 <<>> bigbang.mydns.jp -t NS +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53345
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bigbang.mydns.jp. IN NS

;; ANSWER SECTION:
bigbang.mydns.jp. 86400 IN NS tree.bigbang.mydns.jp.
bigbang.mydns.jp. 86400 IN NS rock.bigbang.mydns.jp.
bigbang.mydns.jp. 86400 IN RRSIG NS 8 3 86400 20171219073318 20121220073318 49804
bigbang.mydns.jp. GekzDUZWIJRQrYmLjESN3MG9KbgE9g/ANswTO3nXlaPS9XR9ZGFHE4wz
WUT4ZZCd1k8IYW67sDvTm2fQBpG7Vb1Ips7F249IBH2B2TTGITSxao4S iPeEdME2p
　（以下、省略）

　権威DNSサーバの準備完了後、上位ゾーンと連携させ必要がありますこれは契約しているレジストラ（や指定事業者）に依頼することが多いと思われます。
　DSレコードは、dnssec-signzoneコマンド実行後に、/var/named/zoneの下に「dsset-bigbang.mydns.jp.」というファイルとして出力されています。

bigbang.mydns.jp.	IN DS 49804 8 1
          DD5EAE8C5FE6B637D7644935A4A1D4F3704B9D95
bigbang.mydns.jp.	IN DS 49804 8 2
          95040CC79A7BB35F3750192F3BFCBBC6DDE1C245724517FD639857C3 9E5E0145

　1行目は、ダイジェストアルゴリズムとしてSHA-1を使って生成されたDSレコードを、同様に2行目はSHA-256を使って生成されたDSレコードを表しています。信頼の連鎖を構築するためにレジストラ経由でこれらのレコードを登録することになります。
　なお、DSレコードは、dnssec-dsfromkeyコマンドを使ってKSK公開鍵ファイルからも生成できます。

# dnssec-dsfromkey /var/named/keys/Kbigbang.mydns.jp.+008+49804.key
bigbang.mydns.jp.	IN DS 49804 8 1
          DD5EAE8C5FE6B637D7644935A4A1D4F3704B9D95
bigbang.mydns.jp.	IN DS 49804 8 2
          95040CC79A7BB35F3750192F3BFCBBC6DDE1C245724517FD639857C3 9E5E0145

　レジストラに登録を依頼し、最終的に上位ゾーンにDSレコードが登録されると、上位ゾーンからの信頼の連鎖が構築され、そのゾーンが信頼されたものとなります。
　詳細な設定は下記を参照してください。
Authoritative Service

●権威DNSサーバの運用

　前項の作業で権威DNSサーバの構築が完了し、DNSSECに対応した状態となりました。
　しかし、権威DNSサーバではそれ以降も、DNSSECに関連して定期的なメンテナンスが必要となってきます。基本的には下記3つの作業が定常的に発生することになります。

【1】再署名

　署名の有効期間を定期的に再設定するために、再署名を実施します。
　また、レコード追加などゾーンの内容に変更があった場合も、再署名を行う必要がある。再署名については、署名を行う場合と同様にdnssec-signzoneコマンドを用いればよいです。

# dnssec-signzone -a -S -x -K /var/named/keys -z -d /var/named/zone -3 1234567890 -e +5y -r /dev/urandom -N unixtime -o bigbang.mydns.jp /var/named/chroot/var/named/bigbang.mydns.jp.zone

【2】ZSKの作成・更新

　ZSKやKSKは定期的に作成および更新する必要があります。鍵の作成手順については、初回の鍵生成とほぼ同様ですが、2回目以降の鍵の作成については事前公開の日付、署名に使い始める日付を、鍵の更新サイクルに合わせた形にする必要があります。
　例えば、事前公開法によってZSKを運用し、初回のZSK生成から3週間後の時点で新しいZSKを事前公開するとしよう。その場合は下記のようなコマンドで新しいZSKを作成できる。

最初に作成
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20111201000000 -A 20111201000000 -I 20111231235959 bigbang.mydns.jp

更新時
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20111222000000 -A 20120101000000 -I 20120131235959 bigbang.mydns.jp

　作成したZSKは3週間後の2011年12月22日00時00分00秒から事前公開され、2012年1月1日00時00分00秒から署名に使われることを表しています。
　これらは再署名の時点で反映されるため、2011年12月20日00時00分00秒以降と2012年1月1日00時00分00秒以降に、再署名およびゾーン情報の再読み込みを行うとよいでしょう。

【3】KSKの作成・更新

　ZSKと同様に、KSKも定期的に作成・更新する必要があります。こちらも作成作業自体は、基本的にはZSKの2回目の作成と同様です。
　ただし、KSKは対応するDSレコードを上位ゾーンに登録しているため、KSKの更新とともにDSレコードの更新申請が必要となります。二重署名法を使ってKSKを運用する場合、DSレコードの再申請は、二重署名がされている期間中にする必要があります。

$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 2048 -r /dev/urandom -f KSK -P 20131201000000 -A 20131201000000 -I 201412310000 bigbang.mydns.jp

　キーロールオーバー中には複数のZSKやKSKが存在するため、鍵を取り違えることのないよう、鍵タグを用いてきちんと区別するなどの注意が必要です。

●ゾーンサーバ

　自身が所有するドメイン名をインターネットに広報するために必要なサーバです。「広報」という言葉を用いると、外部に対して能動的に働き掛けるように考えてしまいますが、実際には自ドメイン名に対する問い合わせ要求にこたえるもので、動作としては受動的です。「DNSの仕組みと運用（1）」をお読みいただければ、ルートサーバからドメインツリーをたどって手元のゾーンサーバに問い合わせが到達するか理解できると思います。
　手元でサーバを立ち上げるにしろ、どこかに委譲するにせよ、ドメイン名を取得してそのドメインを自組織内外のインターネットで引けるようにするにはゾーンサーバが必要です。
　また、ドメイン名解決を行う際に用いられるゾーンデータの出所によって、ゾーンサーバはさらに2つに大別されます。

マスター・ゾーンサーバ（またはマスターサーバ）
オリジナルとなるゾーンデータを所有するサーバです。オリジナルドメインを運用する際には必ず1つ用意します。ゾーンデータは、通常ローカルファイルを基にします。
スレーブ・ゾーンサーバ（またはスレーブサーバ）
ゾーンデータをマスターサーバから複製して使用します。マスターサーバが停止しているときなどは、ローカルのゾーンファイルを読み込むことも可能ですが、通常はゾーン転送（zone transfer）と呼ばれる手法でゾーンデータを最新なものに保ちます。

　データをマスターサーバから複製していることからバックアップとしての働きを期待されがちですが、ドメイン問い合わせに対してバックアップサーバとするかどうかは運用方法により変えられます。また、スレーブ・ゾーンサーバは、何台でも指定することが可能です。

●キャッシュサーバ

　キャッシュサーバはクライアントから来る名前解決要求にこたえるもので、目的のドメインをリゾルブできるまで、外部のDNSをドメインツリーをたどって再帰検索します。
　BIND 9の場合はゾーンサーバの機能も内包しているため、「自身のゾーンデータに該当しなかった場合」という条件が付きます。可能であれば、ゾーンサーバ用のBINDとキャッシュサーバ用のBINDは区別して運用することをお勧めします。
　ゾーンサーバが外部からの問い合わせに対する受動的処理だったのに対し、キャッシュサーバは外部のDNSを参照する能動的なものになります。キャッシュサーバは一度問い合わせた情報をサーバ内のキャッシュに保存し、次に同じ問い合わせが来たときに高速に返答することができます。
　また、BIND 9では単に問い合わせに成功した情報だけでなく、名前解決できなかったという情報をキャッシュする「否定キャッシュ」（ネガティブキャッシュ）も備えています。これらの問い合わせキャッシュがどれくらいの期間有効なのかも運用には大事な要素になってきますが、そちらについては「TTL」というキーワードとともに紹介します。

named.confの編集

　キャッシュサーバに特化した設定項目を見ていきます。

# vi /etc/named.conf
acl bigbang-net {　①
        192.168.0.0/27;
        127.0.0.1;
};
options {
        directory "/var/named";
        pid-file "/var/run/named/named.pid";
        recursion yes;　②
};
zone "." {
        type hint;
        file "named.ca";
};
zone "localhost" {
        type master;
        file "local.zone";
};
zone "0.0.127.in-addr.arpa" {
        type master;
        file "local.rev";
};

　①はネットワーク環境に合わせて指定するアドレスレンジを変更してください。
　　アクセス制御用センテンス。宣言名「bigbang-net」は適当に変更可能
　　プライベートネットワーク内からのみアクセスを許可
　　自分自身からの問い合わせを許可
　キャッシュサーバという用途を考えると、この指定は必須です。キャッシュサーバが外部のネットワークから使用されるのは不本意です。もしファイアウォールやNATボックス内にDNSキャッシュサーバを設置できるのであれば、外部からのアクセスは一切不要にしても構いません。キャッシュサーバ自身が外部に問い合わせることがあっても、外部からキャッシュサーバに対する何らかの接続が発生することはありません。
　②は「yes」にすることで、ドメインツリーの再帰問い合わせを有効にします。つまり、外部のさまざまなドメインに対して返答が可能になります。もしゾーンサーバの機能だけを提供するDNSであればここは「no」とし、自身で管理している（権威を持っている）ドメイン以外の応答には答えないようにすべきです。
　bigbang.mydns.jpの順引きや192.168.10.0/24の逆引きの設定は、キャッシュサーバには不要です。
　　なお、localhost（127.0.0.1）に関する指定とルートサーバに関する情報はどの場合も必要となります。

キャッシュデータの確認

　上記の場合なら、named.ca、local.zone、local.rev、named.pidを準備します。後は、namedを起動あるいは再起動するのみです。

# service named restart

　次に、digコマンドを使ってキャッシュデータを確認します。

$ dig @127.0.0.1 www.bigbang.mydns.jp
;; QUESTION SECTION:
;www.bigbang.mydns.jp.           IN      A
;; ANSWER SECTION:
www.bigbang.mydns.jp.    86400   IN      CNAME   www2.bigbang.mydns.jp.
www2.bigbang.mydns.jp.   86400   IN      A       192.168.0.100
;; AUTHORITY SECTION:
bigbang.mydns.jp.        86400   IN      NS      dns1.kokosu.ne.jp.
bigbang.mydns.jp.        86400   IN      NS      dns2.kokosu.ne.jp.
bigbang.mydns.jp.        86400   IN      NS      ns1.kokosu.ne.jp.

　数秒待ってから、同じようにdigコマンドを発行します。

$ dig @127.0.0.1 www.bigbang.mydns.jp
;; QUESTION SECTION:
;www.bigbang.mydns.jp.           IN      A
;; ANSWER SECTION:
www.bigbang.mydns.jp.    86373   IN      CNAME   www2.bigbang.mydns.jp.
www2.bigbang.mydns.jp.   86373   IN      A       192.168.0.100
;; AUTHORITY SECTION:
bigbang.mydns.jp.        86373   IN      NS      dns2.kokosu.ne.jp.
bigbang.mydns.jp.        86373   IN      NS      ns1.kokosu.ne.jp.
bigbang.mydns.jp.        86373   IN      NS      dns1.kokosu.ne.jp.

　TTLの値が減っていることが分かります。この値が0になるまで、キャッシュデータが参照されます。

キャッシュサーバに有効な設定

　キャッシュサーバには、「recursion yes」以外にも有効な設定がいくつか用意されています。先ほど Windows 2000／XPのDNSキャッシュ機能に触れた際、TTL／ネガティブキャッシュTTLともに、Windows内であらかじめ決められた値で上限を切ることができると説明しました。BIND 9で同じことができないわけがありません。BIND 9では以下のようにnamed.confファイル中のoptionsステートメントで指定します。

options {
        directory "/var/named";
        pid-file "/var/run/named/named.pid";
        recursion yes;
        max-ncache-ttl  300;　（1）
        max-cache-ttl   3600;　（2）
        lame-ttl        600;　（3）
};

注：（2）の値はdigコマンドによるTTL値の検証のために極端に小さくしています。

　（1）はネガティブキャッシュの最大TTLを指定しています。指定がない場合は10800秒（3時間）になります。通常、キャッシュのTTLの最大値は（2）のように指定します。指定がない場合のデフォルト値は604800秒（1週間）です。（3）のLame TTLについては次回以降Lameキーワードとともに説明します。
　設定を変更したらnamedを再起動し、再度digコマンドでキャッシュデータのTTL値を確認してみましょう。

# dig @127.0.0.1 www.bigbang.mydns.jp
;; QUESTION SECTION:
;www.bigbang.mydns.jp.           IN      A
;; ANSWER SECTION:
www.bigbang.mydns.jp.    3600    IN      CNAME   www2.bigbang.mydns.jp.
www2.bigbang.mydns.jp.   3600    IN      A       192.168.0.100
;; AUTHORITY SECTION:
bigbang.mydns.jp.        3600    IN      NS      ns1.kokosu.ne.jp.
bigbang.mydns.jp.        3600    IN      NS      dns1.kokosu.ne.jp.
bigbang.mydns.jp.        3600    IN      NS      dns2.kokosu.ne.jp.

●DNS関係の用語

リゾルバ
名前解決と同じ意味で使用しています。
ルートサーバ
ネームサーバの総元締。現在13拠点で稼働しており、変更される場合もあります。ルートサーバを起点としてドメインツリーが展開されます。ルートサーバ一覧の入手方法は次回で解説します。
正引き
ドメイン名からIPアドレスやネームサーバ、メールサーバのドメイン付きホスト名を検索する手順を指します（例：www.hoge.co.jp　→　192.168.0.1）。本連載では、ホスト名をフルドメイン付きで表現することをFQDN（Fully Qualified Domain Name）と表記します。
逆引き
IPアドレスからドメイン名を検索する手順を指します（例：192.168.0.1　→　www.hoge.co.jp）。

●TTLとネガティブキャッシュ

　TTLはデフォルトのキャッシュ有効期限（Time To Live：TTL）を指定するものです。SOAレコードの中にもTTLの値を見つけることができます。これを理解するには、キャッシュの機能を理解する必要があります。
　通常、キャッシュサーバはDNS問い合わせに成功したもの、すなわち「www.hoge.co.jp→172.17.100.1（または172.17.100.1→www.hoge.co.jp）」の結果をー時的に蓄えます。その一方で、「dummy.hoge.co.jp→NXDOMAIN（ドメインが存在しない）」といった、失敗した結果をキャッシュする「ネガティブキャッシュ」も併せ持っています。
　2つのキャッシュの性質を考えると、同じTTLの値を使用するのはあまり有効ではありません。そこで、RFC 2308（http://www.ietf.org/rfc/rfc2308.txt?number=2308）で新たにネガティブキャッシュが定義されました。
　これを受けて、BIND 8.2以降ではいままでのSOAレコードにあるデフォルトTTLの値をネガティブキャッシュ用のTTLとし、新たに$TTL行を設けてゾーンデータのデフォルトTTLの値を指定するようにしました。また、ゾーン全体に対してTTLを設定する以外に、レコードごとの指定もできます。これにより、変更を予定しているホストのレコードは個別にTTLを短くする、といったことが可能になります。

;通常
hoge.example.jp  IN  A 192.168.0.23
;TTLに3時間を指定した場合
hoge.example.jp  10800  IN  A 192.168.0.23

●クラスC未満での逆引き設定

　逆引きドメインツリーでは、IPアドレスの第3オクテット以下を分割することはできません。1（または0）から255までを1つのゾーンファイルに収める必要があります。しかし、これではクラスC未満でIPアドレスを割り当てられた場合は、割り当てIPをクラスC単位で管理するネットワーク事業者にいちいち修正依頼することになります。

　そこで、クラスCの逆引きを管理するネットワーク事業者側の逆引きゾーン情報にサブドメインとCNAMEを用いることで、見かけ上はクラスC未満で割り振られた各契約者側で逆引き情報を管理できます。
　まず、ネットワーク事業者側のnamed.confファイルおよびゾーンファイルから見ていきましょう。

zone "20.168.192.in-addr.arpa" {
        type master;
        file "example.rev";　←　ファイル名は何でも構わない
};
ネットワーク事業者のnamed.confに追加される記述

$TTL 86400
@            IN      SOA ns1.example.jp. root.example.jp. (
                     2002122001 ; serial
                     3600       ; refresh 1hr
                     900        ; retry 15min
                     604800     ; expire 1w
                     86400      ; min 24hr
)
         IN      NS      ns1.example.jp.
         IN      NS      ns2.example.or.jp.
;
;　一般的な逆引きの場合
101           IN      PTR   pc1.example.jp.
102           IN      PTR   pc2.example.jp.
103           IN      PTR   pc3.example.jp.
104           IN      PTR   pc4.example.jp.
105           IN      PTR   pc5.example.jp
;
;
;　顧客Aのための設定
sub-a IN    NS      ns.example-a.jp.　←　「sub-a」はそれぞれのネットワーク事業者で決められる
1     IN    CNAME   1.sub-a.20.168.192.in-addr.arpa.
2     IN    CNAME   2.sub-a.20.168.192.in-addr.arpa.
3     IN    CNAME   3.sub-a.20.168.192.in-addr.arpa.
;
;　顧客Bのための設定
sub-b  IN    NS      ns.example-b.jp.
8      IN    CNAME   8.sub-b.20.168.192.in-addr.arpa.
9      IN    CNAME   9.sub-b.20.168.192.in-addr.arpa.
ネットワーク事業者のexample.rev

　named.confは、一般的なクラスCでの逆引き定義と変わりません。「file」には、それぞれのルールに合わせて任意のファイル名を指定します。
　ここで指定されたゾーンファイルexample.revを見てみると、IPアドレスに対するホスト名の指定に用いられるPTRの行があり、各顧客に割り当てているIPレンジにはCNAMEが使われています。そのCNAMEで指定された先に、IPアドレスの第4オクテット目「.sub-a.20.168.192.in-addr.arpa.」が指定されています。通常のin-addr.arpa.の使い方ではクラスCまでしか指定できないため、独自にサブドメインを設け、見かけ上クラスC未満のアドレスをそれぞれのIP割り当て先（この場合は顧客Aや顧客B、C）のDNSに委譲しています。その際、サブドメインに対する「NS」をそれぞれ顧客のDNSに向けているわけです。

zone "sub-a.20.168.192.in-addr.arpa" {
        type master;
        file "example-a.rev";　←　ファイル名は何でも構わない
};
顧客Aのnamed.conf

$TTL 86400
@            IN      SOA ns.example-a.jp. root.example-a.jp. (
                     2002122001 ; serial
                     3600       ; refresh 1hr
                     900        ; retry 15min
                     604800     ; expire 1w
                     86400      ; min 24hr
)
            IN      NS      ns.example-a.jp.
;
;　一般的な逆引き
1           IN      PTR   sv1.example-a.jp.
2           IN      PTR   sv2.example-a.jp.
顧客Aのexample-a.rev

　named.confのゾーンの指定は、ネットワーク事業者が決めたサブドメイン（sub-a）付きのもので指定されています。逆引き用のゾーンファイル（example-a.rev）は至って一般的なものです。ここにきて、ようやく192.168.20.1のIPアドレスに対するホスト名が解決されるわけです。
　digコマンドを使って確認してみましょう。1.sub-a.20.168.192.in-addr.arpa.を経てsv1.example-a.jp.に到着することが分かります。

$ dig @127.0.0.1 -x 192.168.20.1
;; QUESTION SECTION:
;1.20.168.192.in-addr.arpa.  IN      PTR
;; ANSWER SECTION:
1.20.168.192.in-addr.arpa. 86400 IN   CNAME   1.sub-a.20.168.192.in-addr.arpa.
1.sub-a.20.168.192.in-addr.arpa. 86400 IN PTR sv1.example-a.jp.

　皆さんが固定IPアドレスをレンジで取得する際は、ネットワーク事業者（ほとんどがプロバイダですが）から割り当てられるIPを使用し、逆引きDNSの作成方法もそれぞれのネットワーク事業者に従うことになります。とはいえ、多くはここで紹介した方法が取られています。サブドメインの命名規則が独特のものになっているため、ネットワーク事業者ごとにさまざまなルールが存在しているように見えますが、事業者側でどのようにやっているかが分かれば、理解が早くなると思います。

●サブドメインの運用と委任

　大規模なサイトでは、「サブドメイン」によって実組織を模したドメイン構成をとることがあります。その際、サブドメインの管理を「委任」することが可能です。
　DNSは、「ドメインツリー」と呼ばれるトップダウンの木構造を成しています。example.jpドメインを取得した場合、example.jpゾーン情報を持つDNSサーバのアドレスやホスト名を、jpゾーンを管理する上位DNSサーバに登録する必要があります。
　ゾーン情報（例ではexample.jp）を持つDNSサーバのアドレスやホスト名を、その上位ドメイン（例ではjp）のゾーン情報を管理するDNSサーバに登録する手順こそが「委任」（delegation）です。
　上位ドメインを管理する側（以降「親」）は、その下位ドメイン（以下「子」）のゾーン情報をすべて持たず、子のゾーン情報が得られるDNSサーバのみを把握しています。つまり、「子ゾーンに関する情報は××DNSサーバに聞いてくれ」と、権限を委譲するわけです。これにより、親サーバが子ゾーンの情報であふれることなく、また子サーバはゾーン情報の変更のたびに親に変更を依頼する必要から解放されます。
　親と子は相対的な関係です。取得した自ドメインを親とし、独自に子ドメインを作成することも可能です。この場合は、「サブドメイン」といった方が一般的でしょう。会社や団体などの組織であれば、部署や部門でサブドメインを分割するのが一般的ですが、まずサブドメイン導入の是非を確認するといいでしょう。
　個人や小規模のコミュニティであれば、サブドメインの必要性はほとんどないでしょう。サブドメイン化し、ゾーン情報を分散化させなければならないほどホストを抱えているわけでもなく、各部門で管理できるドメインが必要になるという事態になる可能性もまれです。サブドメインが必要になるのは、ゾーン情報を分散化させる必要が生じるほどホスト情報がある場合や、組織的なしがらみで自由度の高いドメインを各内部組織に渡す必要がある場合です。サブドメイン化すれば、管理対象のホストはサブドメイン側で管理されるので、ホスト情報の更新頻度も軽減されます。また、親のゾーン情報も小規模になります。
　注意しなければならないのは、サーバ側の負荷は削減されても、親ドメインの管理者にはより厳格な運用が要求されるということです。親ドメインの管理者はサブドメインのゾーン情報をケアしなくてもいい分、サブドメインが正しく運用されているか、各サブドメイン管理者に対して十分に周知する必要があります。ホスト名の命名規則を作成・徹底するのもいいでしょう。

委任しないサブドメイン運用

　　サブドメインの運用に当たって、すべてのサブドメインに委任先となるDNSを立てる必要はありません。組織の規模や管理手法によっては委任を利用せず、親ドメイン内で完結させることもできます。サブドメインが管理するゾーン情報の更新頻度が比較的低い場合や、サブドメインを運用できる担当者やサーバなどの資源に恵まれない場合は、この方法が有効的です。
　例として、example.jpドメインにサブドメインとして「secretary.example.jp」を新設してみましょう。secretary.example.jpに属するホスト情報は次のとおりです。

pc1.secretary.example.jp	192.168.10.50
pc2.secretary.example.jp	192.168.10.51
mail.secretary.example.jp	192.168.10.52	secretary.example.jpドメインのメールサーバ
www.secretary.example.jp	pc1.secretary.example.jpの別名	secretary.example.jpドメインのwwwサーバ

基本的なサブドメインの設定

　最も簡単な方法は、親（example.jp）のゾーンファイルに子（secretary.example.jp）のホスト情報を持たせることです。

$TTL 86400
@            IN      SOA dns.example.jp. root.example.jp. (
                     2003052001 ; serial
                     3600       ; refresh 1hr
                     900        ; retry 15min
                     604800     ; expire 1w
                     86400      ; min 24hr
)
                 IN      NS     dns.example.jp.
dns              IN      A      192.168.10.1
pc1              IN      A      192.168.10.11
pc2              IN      A      192.168.10.12
pc3              IN      A      192.168.10.13
pc4              IN      A      192.168.10.14
pc5              IN      A      192.168.10.15
（ここから追加分）
pc1.secretary    IN      A      192.168.10.50
pc2.secretary    IN      A      192.168.10.51
mail.secretary   IN      A      192.168.10.52
secretary        IN      MX     10 mail.secretary
www.secretary    IN      CNAME  pc1.secretary
親のexample.zoneファイル

　ホスト名の最後の「.」を省略すると、ゾーンファイルの起点名が補完されます。例ではnamed.confで「example.jp」を起点名に指定（注）しているため、下記のようにFQDNで指定した場合と同じように振る舞います。特に、MXレコードの指定ではドメイン名そのものをレコードの左辺に指定しています。

pc4.example.jp.            IN    A     192.168.10.14
pc5.example.jp.            IN    A     192.168.10.15
（ここから変更分）
pc1.secretary.example.jp.  IN    A     192.168.10.50
pc2.secretary.example.jp.  IN    A     192.168.10.51
mail.secretary.example.jp. IN    A     192.168.10.52
secretary.example.jp.      IN    MX    10 mail.secretary.example.jp.
www.secretary.example.jp.  IN    CNAME pc1.secretary.example.jp.
親の/var/named/example.zoneファイル

注：/etc/named.confで、
zone "example.jp" {
        type master;
        file "example.zone";
};
と指定されています。

　設定は、親ゾーン（example.jp）のNSとして登録されている全DNSサーバ（図3のA、B）に必要です。ゾーン転送やゾーンファイルの自動更新を用いてゾーン情報の同期を行っているのでなければ、ここで紹介した設定を全サーバに施します。設定完了後、BINDを再起動して変更を有効化し、digなどで動作を確認します。

$ dig www.secretary.example.jp
（省略）
;; ANSWER SECTION:
www.secretary.example.jp.  86400  IN      CNAME   
pc1.secretary.example.jp.
pc1.secretary.example.jp.  86400  IN      A       192.168.10.50

　同様の手順で、MXやNSレコードの確認も行います。うまくいかないときは、/var/log/messagesのエラーを参考に、ゾーンファイルに問題がないか確認します。

$ORIGINを使用したサブドメインの設定

　named.confで指定したデフォルトの起点名を意図的に変更するには、$ORIGINステートメントを用います。$ORIGINステートメント以降は、ホスト名の最後の「.」を省略した際に補完されるドメイン名が、$ORIGINの右辺（secretary.example.jp.）に変更されます。ただし、MXはFQDNを指定する必要があります。
　また、$ORIGINで起点名を変更すると、再度$ORIGINで起点名を定義し直さない限り、行末まで指定した起点名が有効になります。

pc4                    IN      A      192.168.10.14
pc5                    IN      A      192.168.10.15
（ここから変更分）
$ORIGIN secretary.example.jp.
pc1                    IN      A      192.168.10.50
pc2                    IN      A      192.168.10.51
mail                   IN      A      192.168.10.52
secretary.example.jp.  IN      MX     10 mail （注）
www                    IN      CNAME  pc1
親のexample.zoneファイル

注：@表記を用いて、
@                      IN      MX     10 mail
とすることもできます。FQDNと起点名が同じ場合は「@」で代替します。

$ORIGINに$INCLUDEを併用した設定

　$INCLUDEステートメントを利用することで、サブドメイン「secretary.example.jp」の情報を別ファイルに分離し、親のゾーンファイルに挿入させることができます。サブドメインのゾーンファイルはexample.zoneと同じディレクトリ（ここでは/var/named）に保存し、記述する内容は「$ORIGINを使用したサブドメインの設定」と同じにします。サブドメイン情報を別ファイルとすることで、ゾーンファイルの編集中に親ドメインとサブドメインの整理がつかなくなるなどの煩わしさがなくなります。

pc4                    IN      A      192.168.10.14
pc5                    IN      A      192.168.10.15
（ここから変更分）
$ORIGIN secretary.example.jp.
$INCLUDE secretary.example.zone
親の/var/named/example.zoneファイル
pc1                    IN      A      192.168.10.50
pc2                    IN      A      192.168.10.51
mail                   IN      A      192.168.10.52
secretary.example.jp.  IN      MX     10 mail （注）
www                    IN      CNAME  pc1
親のsecretary.example.zoneファイル

注：@表記を用いた、
@                      IN      MX     10 mail
と同等です。

$INCLUDEで起点名を変更した設定

　$INCLUDEの2番目の引数に起点名を指定することで、記述をさらに簡潔にできます。簡素化とともに、起点名の変更がその1行（読み込むファイルに対してのみ）に限定できるため、$INCLUDEの次の行はデフォルトの起点名（例ではexample.jp）のままにすることが可能です。

pc4                    IN      A      192.168.10.14
pc5                    IN      A      192.168.10.15
（ここから変更分）
s$INCLUDE secretary.example.zone ecretary.example.jp.

注：/var/named/secretary.example.zoneは「$ORIGINに$INCLUDEを併用した設定」と同じように用意しておきます。

専用のゾーンファイルを用意する方法

　BIND 9では、サブドメイン専用のゾーンファイルを定義できます。これまでの方法は、親のSOAをそのまま引き継ぎますが、専用のゾーンファイルを用意すればサブドメイン専用のSOAを定義できます。

zone "secretary.example.jp" {
        type master;
        file "secretary.example.zone";
};
親の/etc/named.confに追加
$ttl 38400
@       IN      SOA     dns01.secretary.example.jp. root.secretary.
example.jp.  (
                        2003052001
                        10800
                        3600
                        604800
                        38400 )
        IN      NS      dns01.example.jp.
        IN      NS      dns02.example.jp.
        IN      MX      10 mail.secretary.example.jp.
pc1     IN      A       192.168.10.50
pc2     IN      A       192.168.10.51
mail    IN      A       192.168.10.52
www     IN      CNAME   pc1.secretary.example.jp.
親に/var/named/secretary.example.zoneファイルを用意

　ゾーン転送やゾーンファイルの自動更新でゾーン情報を同期している場合、サブドメイン専用にゾーンファイルを定義すると、サブドメイン分はスレーブ側に反映されません。ゾーン転送を使用している場合は、スレーブサーバ側に以下のような設定を追加します。

zone "secretary.example.jp" {
        type slave;
        masters {
                マスター・サーバのIPアドレス;
        };
        file "secretary.example.zone.bak";
};
親（スレーブ）の/etc/named.confに追加

　以上が、委任せずに親ドメイン内でサブドメインの設定を完結させる手法です。ここでは正引きのみ説明しましたが、逆引きも通常どおり行いましょう。

$TTL 86400
@            IN      SOA    dns.example.jp. root.example.jp.  (
                     2003052001      ; Serial
                     3600            ; Refresh
                     900             ; Retry
                     604800          ; Expire
                     3600 )          ; Minimum
             IN      NS    dns.example.jp.
1            IN      PTR   dns.example.jp.
11           IN      PTR   pc1.example.jp.
12           IN      PTR   pc2.example.jp.
13           IN      PTR   pc3.example.jp.
14           IN      PTR   pc4.example.jp.
15           IN      PTR   pc5.example.jp.
（追加分）
50           IN      PTR   pc1.secretary.example.jp.
51           IN      PTR   pc2.secretary.example.jp.
52           IN      PTR   mail.secretary.example.jp.

●あるサーバが倒れてから名前解決が遅くなった

　原因は、名前解決が遅くなったマシンで障害のため存在していないサーバのIPアドレスを/etc/resolev.confの最初のレコードに設定していたためだった。
　この行を削除し、別ネームサーバに変更したところ正常な状態に戻りました。

●プライマリDNS、セカンダリDNSを設定しているにもかかわらずSSH接続が遅い

　デフォルトゲートウェイが変わったためによるものだった。デフォルトゲートウェイを修正。

●named-sdbによる高負荷

　2012年12月初旬、Cactiのグラフを確認していたところ、あるPCがいつの間にか高負荷の状態になっていることが分かりました。

　topコマンドで確認してみると、「named-sdb」が該当しています。

# top
top - 13:29:24 up 9 days,  4:05,  2 users,  load average: 1.25, 1.13, 1.08
Tasks: 219 total,   1 running, 218 sleeping,   0 stopped,   0 zombie
Cpu(s): 21.7%us, 44.0%sy,  0.0%ni, 33.9%id,  0.0%wa,  0.2%hi,  0.2%si,  0.0%st
Mem:   3087884k total,  2614728k used,   473156k free,   358432k buffers
Swap:  5177340k total,        0k used,  5177340k free,  1431148k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 7741 named     20   0 63732  14m 3116 S 141.5  0.5 324:41.17 named-sdb         
    1 root      20   0  6804 3892 2068 S  0.0  0.1   0:05.08 systemd            
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.04 kthreadd           
    3 root      20   0     0    0    0 S  0.0  0.0   1:14.21 ksoftirqd/0        
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0        
    7 root      RT   0     0    0    0 S  0.0  0.0   0:00.23 watchdog/0         
    8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1        
   10 root      20   0     0    0    0 S  0.0  0.0   1:15.73 ksoftirqd/1

　ログを確認します。

Dec  5 09:38:04 neko named-sdb[7741]: managed-keys.bind.jnl:
                                         create: permission denied
Dec  5 09:38:04 neko named-sdb[7741]: managed-keys-zone ./IN:
                 sync_keyzone:dns_journal_open -> unexpected error

　インターネットで検索したところ、下記の作業をすれば良いことが分かりました。

# vi /etc/named.conf
　　　　　（途中省略）
	dnssec-enable yes;
	managed-keys-directory "/var/named/dnssec";
	dnssec-validation yes;
	dnssec-lookaside auto;
　　　　　（途中省略）

　DNSSECのキーファイルの保存フォルダを作成します。

# cd /var/named/chroot/var/named
# mkdir dnssec
# chown named:named dnssec
# chmod 700 dnssec
# service named restart

　これで高負荷が改善されました。

●It's world writable or writable by group which is not "root"が出力された場合の対処方法

　crondの動作時に正常に動作しなかった場合root宛にメールが送られてきます。いつからかnamedのログローテションが正常に動作していない内容のメールが送信されてくるようになりました。

/etc/cron.daily/logrotate:

error: skipping "/var/named/data/named.run" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/xfer.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/queries.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/update.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/lame-servers.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

　この時のログローテションの内容は下記のとおりです。

# cat /etc/logrotate.d/named
/var/named/data/named.run {
    missingok
    create 0644 named named
    postrotate
        /sbin/service named reload  2> /dev/null > /dev/null || true
    endscript
}

　エラーが表示されるかどうか確認します。

# logrotate -v /etc/logrotate.d/named
reading config file /etc/logrotate.d/named
Handling 1 logs
rotating pattern: /var/named/data/named.run  1048576 bytes (no old logs will be kept)
empty log files are rotated, old logs are removed
considering log /var/named/data/named.run
error: skipping "/var/named/data/named.run" because parent directory has insecure permissions \
(It's world writable or writable by group which is not "root") \
Set "su" directive in config file to tell logrotate which user/group should be used for rotation.\

not running postrotate script, since no logs were rotated

　これを下記のように変更しました。

# cat /etc/logrotate.d/named
/var/named/data/named.run {
    missingok
    su named named
    create 0644 named named
    postrotate
        /sbin/service named reload  2> /dev/null > /dev/null || true
    endscript
}

　確認しています。

# logrotate -v /etc/logrotate.d/named
reading config file /etc/logrotate.d/named
Handling 1 logs
rotating pattern: /var/named/data/named.run  1048576 bytes (no old logs will be kept)
empty log files are rotated, old logs are removed
switching euid to 25 and egid to 25
considering log /var/named/data/named.run
  log /var/named/data/named.run does not exist -- skipping
not running postrotate script, since no logs were rotated
switching euid to 0 and egid to 0

　エラーが表示されていないので大丈夫なようです。

●isc_stdio_open '/var/log/named/queries.log' failed: file not foundが出力される

　namedを再起動すると/var/log/messagesに下記のようなエラーが記録されていることに気が付きました。

Aug 17 13:37:03 nezumi named-sdb[18752]: isc_stdio_open '/var/log/xfer.log' failed: file not found
Aug 17 13:37:03 nezumi named-sdb[18752]: isc_stdio_open '/var/log/update.log' failed: file not found
Aug 17 13:37:03 nezumi named-sdb[18752]: isc_stdio_open '/var/log/queries.log' failed: file not found
Aug 17 13:37:03 nezumi named-sdb[18752]: isc_stdio_open '/var/log/lame-servers.log' failed: file not found

　出力先のログファイルを作成し、権限を与えました。

# cd /var/named/chroot/var/log
# touch xfer.log update.log queries.log lame-servers.log
# chgrp named xfer.log update.log queries.log lame-servers.log
# chmod g+w xfer.log update.log queries.log lame-servers.log

●slaveのzoneファイルの内容をチェックする方法

　raw形式のzoneファイルの内容をチェックする方法は下記のとおりです。

# named-checkzone -D -f raw <ZONE_NAME> <ZONE_FILE_NAME>

　例えばnamed.confに下記のように記載されている場合

zone "bigbang.mydns.jp" {
	type slave;
	file "slaves/bigbang.mydns.jp.slave";
	masters { 192.168.0.1; } ;
	};	
zone "0.168.192" {
	type slave;
	file "slaves/0.168.192.in-addr.arpa.slave";
	masters { 192.168.0.1; } ;
	};

　正引きのZONE_NAMEは「bigbang.mydns.jp」、ZONE_FILE_NAMEは「bigbang.mydns.jp.slave」
　逆引きのZONE_NAMEは「0.168.192」、ZONE_FILE_NAMEは「0.168.192.in-addr.arpa.slave」
となります。これらを確認するには下記のコマンドを実行します。

正引きの場合
# named-checkzone -D -f raw bigbang.mydns.jp /var/named/chroot/var/named/slaves/bigbang.mydns.jp.slave
逆引きの場合
# named-checkzone -D -f raw 0.168.192 /var/named/chroot/var/named/slaves/0.168.192.in-addr.arpa.slave

●セカンダリのゾーンファイルをtext形式にする方法

　named.conf内のzone{};内にmasterfile-format text;を記述すればtext形式になります。text形式にすると、起動パフォーマンスが低下するようです。多くのゾーンを管理しているDNSサーバではraw形式方がいいのかもしれません。
　下記がサンプルです。

    // We are a slave server for hoge.com
    zone “hoge.com” {
        type slave;
        masterfile-format text;
        file “hoge.com.zone”;
        // IP address of hoge.com master server
        masters { 192.168.0.1; };
    };

　全てのゾーンファイルをtext形式にしたい場合は、zone{};の中ではなく、named.confやnamed.conf.optionsに「masterfile-format text;」を記載します。

●validatingと言うログ

　参考URL：BINDのログで溢れてた。

　以前DNSSECを試用していた設定が残っていたため下記のようなログがたまに記録されていました。

Sep 6 09:16:37 neko named[2890]: validating @0x7f0da4b89190: com.cn SOA: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: GICE14DNTMDN31G43AUGVRKTKALVB8QC.com.cn NSEC3: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: MI2OUBFA49Q47917BR600DOL1QGRP79T.com.cn NSEC3: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: UQROTQK62NOIM5U43DMF7AMC8JJFRM7T.com.cn NSEC3: no valid signature found

　named.confを下記のように変更しました。

# vi /var/named/chroot/etc/named.conf
dnssec-validation no;
# systemctl reloal named-chroot

●unexpected RCODE REFUSEDというログを記録させないようにする方法

　参考URL：Bind - lame server resolving をログから消すには

　lame-servers.logに下記のようなログが記録されていました。

lame-servers: info: error (unexpected RCODE REFUSED) resolving '62.227.159.115.in-addr.arpa/PTR/IN': 123.206.229.89#53

　このようなログを記録しないよう下記の対処を施しました。

# vi /var/named/chroot/etc/named.conf
logging {
  category lame-servers { null; };
};
# systemctl named-chroot restart

　ただし、「攻撃の意思を持つアクセスを特定するためにBINDのログを監視する」という意味でログを記録している場合もありますので、せっていには注意する必要があります。

●dumping master file

　セカンダリDNSサーバ構築時に下記のような転送エラーが記録されていました。

Dec 17 16:31:42 tori named[87894]: dumping master file: slave/tmp-JQPspLEEaV: open: file not found
Dec 17 16:31:42 tori named[87894]: dumping master file: slave/tmp-zYcOgmp0rA: open: file not found
Dec 17 16:31:42 tori named[87894]: dumping master file: slave/tmp-nagHqCW2ON: open: file not found

　named.confを確認したところ、3箇所記載間違いがありました。

zone "bigbang.mydns.jp" {
        type slave;
        file "slave/bigbang.mydns.jp";
        masters { 192.168.0.1; };
};

　slaveをslavesに修正後、restartし正常に転送されるようになりました。