DNS BIND rndc 制御　キャッシュの消し方


rndc
ローカル上、またはリモート上にあるBIND9を制御するツール
主に、設定の再読み込み、namedサービスの停止（起動はできない）、統計情報の表示、キャッシュのクリアなどのために使用する


■ rndcによる制御

rndcによって実行する主なコマンドは以下の通り。
そのほかのオプションを知りたい場合は、 rndc --help で確認

rndc reload	キャッシュは保持したままで、設定の再読み込み（プロセス番号は変わらない）
rndc reload　ゾーン名	キャッシュは保持したままで、指定のゾーンの設定だけ再読み込み（プロセス番号は変わらない）
rndc stop	bindの停止　(rndcでbindの起動はできない）
rndc status	BINDの統計情報（主に設定や起動の状態など）
rndc stats	BINDの統計情報（名前解決の統計情報）をファイルに出力する
rndc dumpdb	メモリ上のキャッシュをダンプファイルへ出力
rndc flush	メモリ上のキャッシュデータの全削除
rndc flushname ラベル	指定のラベルに一致するレコードをメモリ上のキャッシュから削除
	削除対象は、ラベル名（レコードの左辺）が完全一致しているものだけ
	rndc flushname google.co.jp ⇒ google.co.jpは消えるが、www.google.co.jpなどは消えない
	rndc flushname www.google.co.jp ⇒ www.google.co.jpは消えるが、google.co.jpなどは消えない



rndc reload　　　キャッシュは保持したままで、設定の再読み込み（プロセス番号は変わらない）
# ps -ef \| grep named
named 1934 1 0 13:48 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot			現在のプロセス番号は、1934

# rndc reload			rndc reload 実行
server reload successful

# ps -ef \| grep named			プロセス番号の確認 1934のまま
named 1934 1 0 13:48 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot

# tail /var/named/chroot/var/log/named/named.info			ログの確認
21-May-2011 14:06:02.090 general: received control channel command 'reload'			特に設定を変えていないのでこれだけ
21-May-2011 14:06:02.090 general: loading configuration from '/etc/named.conf'
21-May-2011 14:06:02.097 general: using default UDP/IPv4 port range: [1024, 65535]
21-May-2011 14:06:02.102 general: using default UDP/IPv6 port range: [1024, 65535]
21-May-2011 14:06:02.137 general: reloading configuration succeeded
21-May-2011 14:06:02.138 general: reloading zones succeeded


rndc reload　ゾーン名　　　キャッシュは保持したままで、指定のゾーンの設定だけ再読み込み（プロセス番号は変わらない）
# vi example.co.jp.zone			検証のため、2つのゾーンファイルのシリアル番号を変更
example.co.jp IN SOA dns1.example.co.jp. root.example.co.jp. (
2010112321 ; serial

# 24.168.192.db
24.168.192.in-addr.arpa IN SOA dns.example.co.jp. root.example.co.jp. (
2010083156 ; serial

# rndc reload 24.168.192.in-addr.arpa			24.168.192.in-addr.arpaゾーンのみreload実施
zone reload queued

# ps -ef \| grep named			プロセス番号の確認 1934のまま
named 1934 1 0 13:48 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot

# tail /var/named/chroot/var/log/named/named.info			ログの確認
21-May-2011 14:11:45.053 general: received control channel command 'reload 24.168.192.in-addr.arpa'			24.168.192.in-addr.arpaゾーンのファイルだけ読み込まれている
21-May-2011 14:11:45.059 general: zone 24.168.192.in-addr.arpa/IN: loaded serial 2010083156
21-May-2011 14:11:45.060 notify: zone 24.168.192.in-addr.arpa/IN: sending notifies (serial 2010083156)

# dig +noall +answer @localhost 24.168.192.in-addr.arpa soa			digで確認
24.168.192.in-addr.arpa. 86400 IN SOA dns1.example.co.jp. root.example.co.jp. 2010083156			シリアル番号が変わっている
10800 3600 604800 3000

# dig +noall +answer @localhost example.co.jp soa			example.co.jpのほうはシリアル番号がそのまま
example.co.jp. 86400 IN SOA dns1.example.co.jp. root.example.co.jp. 2010112320
10800 3600 86400 86400


rndc status　　BINDの統計情報を出力
# rndc status			rndc status 実行
version: 9.7.3 (Not available.)			named.confでバージョン非表示にしてもバージョンの確認ができる
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 stats　　　BINDの統計情報（問い合わせ詳細）をファイルに出力する
# vi /var/named/chroot/etc/named.conf			rndc statsで出力されるファイルは、named.confで指定できる
options {			statistics-file "出力先ファイルパス";
directory "/var/named";			指定がない場合は、directoryで指定したディレクトリに
statistics-file "/var/named/data/named_stats";			named.statsというファイル名で出力される

# rndc stats			rndc stats　実行

# ls -l /var/named/chroot/var/named/data/			確認
-rw-r--r-- 1 named named 2488 5月 21 16:03 named_stats

# rndc stats			rndc stats　実行

# ls -l /var/named/chroot/var/named/named.stats			rndc statsの結果は、ファイルに追記されるため
-rw-r--r-- 1 named named 4976 5月 21 16:07 named_stats			rndc statsのサイズが増えることに注意する


rndc dumpdb　　メモリ上のキャッシュをダンプファイルへ出力
# vi /var/named/chroot/etc/named.conf			ダンプの出力ファイルは、named.confで指定できる
options {			dump-fle "出力先ファイルパス"
directory "/var/named";			指定がない場合は、directoryで指定したディレクトリに
dump-file "/var/named/data/named_dump";			named_dump.dbというファイル名で出力される


# rndc dumpdb			rndc dumpdb　実行

# ls -l /var/named/chroot/var/named/data/			確認　　ファイルは勝手に作られる
-rw-r--r-- 1 named named 30636 5月 21 15:41 named_dump			ファイルがない場合は、ログを確認
			（多くはファイルを作成するためのアクセス権が無いことによる
			失敗のエラー)

# more /var/named/chroot/var/named/data/named_dump			中身はテキストファイルなのでmoreなどで確認ができる
（内容は省略）


rndc flush　　メモリ上のキャッシュデータの全削除
# dig @localhost www.yahoo.co.jp a +norec			自分自身に問い合わせてキャッシュを持っているか確認
			(再帰問い合わせはしないこと）
; <<>> DiG 9.7.3 <<>> @localhost www.yahoo.co.jp a +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51758
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.co.jp. IN A

;; ANSWER SECTION:
www.yahoo.co.jp. 844 IN CNAME www.ya.gl.yahoo.co.jp.			www.yahoo.co.jpのTTLは最大900だが、
www.ya.gl.yahoo.co.jp. 4 IN A 203.216.243.240			キャッシュデータなので844になっている

;; AUTHORITY SECTION:
gl.yahoo.co.jp. 844 IN NS gns02.net.djm.yahoo.co.jp.
gl.yahoo.co.jp. 844 IN NS gns02.net.bbt.yahoo.co.jp.

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 21 14:47:35 2011
;; MSG SIZE rcvd: 129

# rndc flush			rndc flush 実施(全てのキャッシュデータ削除)

# dig @localhost www.yahoo.co.jp a +norec			確認　（再帰問い合わせはしない）
			キャッシュが消えたので回答がなくなった
; <<>> DiG 9.7.3 <<>> @localhost www.yahoo.co.jp a +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10867
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.co.jp. IN A

;; AUTHORITY SECTION:
. 518400 IN NS j.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS d.root-servers.net.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 21 14:50:46 2011
;; MSG SIZE rcvd: 244

# dig @localhost www.yahoo.co.jp a			再帰問い合わせOKで再度問い合わせ
			新しくデータをキャッシュした
; <<>> DiG 9.7.3 <<>> @localhost www.yahoo.co.jp a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35316
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.co.jp. IN A

;; ANSWER SECTION:
www.yahoo.co.jp. 900 IN CNAME www.ya.gl.yahoo.co.jp.
www.ya.gl.yahoo.co.jp. 60 IN A 203.216.251.233

;; AUTHORITY SECTION:
gl.yahoo.co.jp. 900 IN NS gns02.net.djm.yahoo.co.jp.
gl.yahoo.co.jp. 900 IN NS gns02.net.bbt.yahoo.co.jp.

;; Query time: 382 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 21 14:50:58 2011
;; MSG SIZE rcvd: 129


rndc flushname ゾーン名	指定のラベルのレコードだけをメモリ上のキャッシュから削除
	削除されるキャッシュは、ラベル名（レコードの左辺側）が完全一致しているものだけ
	例) rndc flushname google.co.jp 　　　　 ⇒ google.co.jpは消えるが、www.google.co.jpは消えない
	例) rndc flushname www.google.co.jp　　 ⇒ google.co.jpは消えないが、www.google.co.jpは消える

# rndc flush		検証のため、一度キャッシュデータを全て削除

# dig @localhost yahoo.co.jp a		yahoo.co.jpとwww.yahoo.co.jpについて問い合わせてキャッシュさせる
# dig @localhost www.yahoo.co.jp a

# rndc dumpdb		キャッシュをダンプ

# more named_dump.db		キャッシュの確認
; authauthority		yahooに関係しているものだけを抜粋した
yahoo.co.jp. 889 NS ns04.ops.ogk.yahoo.co.jp.
889 NS dnsg01.yahoo.co.jp.
; authanswer
289 A 124.83.187.140
289 A 203.216.243.240
; glue
gns02.net.bbt.yahoo.co.jp. 892 A 202.93.64.133
; glue
gns02.net.djm.yahoo.co.jp. 892 A 124.83.159.37
; glue
dnsg01.yahoo.co.jp. 86389 A 211.14.12.10
; glue
gl.yahoo.co.jp. 892 NS gns02.net.bbt.yahoo.co.jp.
892 NS gns02.net.djm.yahoo.co.jp.
; authanswer
www.ya.gl.yahoo.co.jp. 52 A 124.83.147.212
; glue
ns04.ops.ogk.yahoo.co.jp. 86389 A 124.83.218.185
; authanswer
www.yahoo.co.jp. 892 CNAME www.ya.gl.yahoo.co.jp.


# rndc flushname yahoo.co.jp		yahoo.co.jpに関するキャッシュをクリア

# rndc dumpdb		キャッシュのダンプ

# more named_dump.db		キャッシュの確認
; glue		上記と比較してわかるとおり、左辺がyahoo.co.jpのレコードだけが消えている
gns02.net.bbt.yahoo.co.jp. 881 A 202.93.64.133
; glue
gns02.net.djm.yahoo.co.jp. 881 A 124.83.159.37
; glue
dnsg01.yahoo.co.jp. 86377 A 211.14.12.10
; glue
gl.yahoo.co.jp. 881 NS gns02.net.bbt.yahoo.co.jp.
881 NS gns02.net.djm.yahoo.co.jp.
; authanswer
www.ya.gl.yahoo.co.jp. 42 A 124.83.203.233
; glue
ns04.ops.ogk.yahoo.co.jp. 86377 A 124.83.218.185
; authanswer
www.yahoo.co.jp. 881 CNAME www.ya.gl.yahoo.co.jp.

# dig @localhost yahoo.co.jp a +norec		確認　（再帰問い合わせはしない）
		yahoo.co.jpについてはキャッシュが消えたので回答なし
; <<>> DiG 9.7.3-P3 <<>> @localhost yahoo.co.jp a +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18571
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0

;; QUESTION SECTION:
;yahoo.co.jp. IN A

;; AUTHORITY SECTION:
jp. 172661 IN NS c.dns.jp.
jp. 172661 IN NS b.dns.jp.
jp. 172661 IN NS d.dns.jp.
jp. 172661 IN NS a.dns.jp.
jp. 172661 IN NS e.dns.jp.
jp. 172661 IN NS f.dns.jp.
jp. 172661 IN NS g.dns.jp.

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 30 03:02:49 2011
;; MSG SIZE rcvd: 145

# dig @localhost www.yahoo.co.jp a		確認　（再帰問い合わせはしない）
		www.yahoo.co.jpやya.gl.yahoo.co.jpはキャッシュされたまま
; <<>> DiG 9.7.3-P3 <<>> @localhost www.yahoo.co.jp a		よって、ドメインを削除したらそのドメインに関係するレコードが全て消えるわけではない
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33925
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.co.jp. IN A

;; ANSWER SECTION:
www.yahoo.co.jp. 877 IN CNAME www.ya.gl.yahoo.co.jp.
www.ya.gl.yahoo.co.jp. 37 IN A 203.216.243.240

;; AUTHORITY SECTION:
gl.yahoo.co.jp. 877 IN NS gns02.net.djm.yahoo.co.jp.
gl.yahoo.co.jp. 877 IN NS gns02.net.bbt.yahoo.co.jp.

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 30 03:04:33 2011
;; MSG SIZE rcvd: 129


# rndc flushname www.ya.gl.yahoo.co.jp		つづいて www.ya.gl.yahoo.co.jpのキャッシュを削除

# rndc dumpdb		キャッシュのダンプ

# more named_dump.db		キャッシュの確認
; glue		左辺が、www.ya.gl.yahoo.co.jpのレコードだけ消えている
gns02.net.bbt.yahoo.co.jp. 836 A 202.93.64.133
; glue
gns02.net.djm.yahoo.co.jp. 836 A 124.83.159.37
; glue
dnsg01.yahoo.co.jp. 86332 A 211.14.12.10
; glue
gl.yahoo.co.jp. 836 NS gns02.net.bbt.yahoo.co.jp.
836 NS gns02.net.djm.yahoo.co.jp.
; glue
ns04.ops.ogk.yahoo.co.jp. 86332 A 124.83.218.185
; authanswer
www.yahoo.co.jp. 836 CNAME www.ya.gl.yahoo.co.jp.

# dig @localhost www.yahoo.co.jp a +norec		確認　（再帰問い合わせはしない）
		「www.ya.gl.yahoo.co.jp. IN A 　　 203.216.243.240」は消えたが、
; <<>> DiG 9.7.3-P3 <<>> @localhost www.yahoo.co.jp a +norec		「www.yahoo.co.jp. 　ＩＮ CNAME www.ya.gl.yahoo.co.jp.」は消えていない
; (1 server found)		よって、削除される対象は、レコードの左辺部分（ラベル名）が一致したものだけ
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63387
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.co.jp. IN A

;; ANSWER SECTION:
www.yahoo.co.jp. 768 IN CNAME www.ya.gl.yahoo.co.jp.

;; AUTHORITY SECTION:
gl.yahoo.co.jp. 768 IN NS gns02.net.djm.yahoo.co.jp.
gl.yahoo.co.jp. 768 IN NS gns02.net.bbt.yahoo.co.jp.

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 30 03:17:09 2011
;; MSG SIZE rcvd: 113



■ 誤った（古い）データのキャッシュを削除する手順

その前に・・

1．キャッシュの確認のためにキャッシュのダンプをするかどうか
キャッシュのダンプには多少の負荷がかかるので、古いサーバは気をつけたほうが良いかもしれない

２．権威サーバ（コンテンツサーバ）が誤った情報を持っている場合は、キャッシュをクリアしても意味がない
この場合、キャッシュサーバの管理者ではなく、権威サーバの管理者に正しいゾーン情報に書き換えてもらってからキャッシュをクリアすること
あるISPではきちんと表示される（名前解決できている）のに、別のISPでは古いままというのは良くある事例で、
原因のひとつとして、ゾーン転送がきちんとされていないために古い情報を保持したままのセカンダリDNSサーバに対して、運悪くそのセカンダリDNSへ
問い合わせたために起こる現象であり、ISP（のキャッシュサーバ)の責任ではない

３．クリアするデータはそれで正しいのか？
たとえば、キャッシュDNSが、古い情報を保持している権威サーバから古い（誤った）Ａレコードを取得した場合、キャッシュサーバ上のAレコードのキャッシュだけを
クリアしても、正しいＡレコードを取得できるとは限らない
なぜなら、古い情報を保持している権威サーバを示すＮＳレコード（とそのＡレコード）も保持しているため、再度その権威サーバに問い合わせを行う可能性があるから
である
この場合は、その権威サーバに対するNSレコードも一緒に削除しなければならない


削除手順

NSレコードは正しいが、Ａレコードが古い（誤っている）場合

[ キャッシュされているデータ ]		[ 正しいデータ ]
①　　example.co.jp. NS IN dns1.example.co.jp.		example.co.jp. NS IN dns1.example.co.jp.
②　　www.example.co.jp. A IN 192.168.0.100		www.example.co.jp. A IN 192.168.24.250
③　　dns1.example.co.jp. A IN 192.168.0.1		dns1.example.co.jp. A IN 192.168.0.1

# dig @localhost www.example.co.jp a +norec		キャッシュサーバ自身に問い合わせて、キャッシュされているか確認
		（＋norecをつけて再帰問い合わせはしないようにする）
		場合によってはネガティブキャッシュされている可能性もある

# rndc dumpdb		ダンプしても大丈夫ならば、キャッシュデータをダンプさせてきちんと確認を取る
# more /var/named/chroot/var/named/data/named_dump		確認


# rndc flushname www.example.co.jp		www.example.co.jpのキャッシュを削除
		この場合、①と③のレコードは削除されない

# dig @localhost www.example.co.jp a +norec		キャッシュがクリアされたことを確認
		（＋norecをつけて再帰問い合わせはしないようにする）

# dig @localhost www.example.co.jp a		+norecをはずして、回答が帰ってくることを確認
		このとき、example.co.jpを管理しているDNSの情報はキャッシュとして残っているので、
		直接dns1.example.co.jp(192.168.0.1)へ、www.example.co.jpのAレコードを問い合わせに行く


セカンダリDNSが古い（誤った）Ａレコードを保持している場合　（ゾーン転送が失敗している場合に起こる問題）
dns1.example.co.jpをプライマリDNS、dns2.example.co.jpをセカンダリとする

[ キャッシュされているデータ ]		[ 正しいデータ ]
①　　example.co.jp. NS IN dns1.example.co.jp.		example.co.jp. NS IN dns1.example.co.jp.
②　　example.co.jp. NS IN dns2.example.co.jp.		example.co.jp. NS IN dns2.example.co.jp.
③　　www.example.co.jp. A IN 192.168.0.100		www.example.co.jp. A IN 192.168.24.250
④　　dns1.example.co.jp. A IN 192.168.0.1		dns1.example.co.jp. A IN 192.168.0.1

# dig @localhost www.example.co.jp a +norec		キャッシュサーバ自身に問い合わせて、キャッシュされているか確認
		（＋norecをつけて再帰問い合わせはしないようにする）
		場合によってはネガティブキャッシュされている可能性もある

# rndc dumpdb		ダンプしても大丈夫ならば、キャッシュデータをダンプさせてきちんと確認を取る
# more /var/named/chroot/var/named/data/named_dump		確認


# rndc flushname www.example.co.jp		www.example.co.jpのキャッシュを削除
		この場合、①と②と④のレコードは削除されない


# dig @localhost www.example.co.jp a +norec		キャッシュがクリアされたことを確認
		（＋norecをつけて再帰問い合わせはしないようにする）

# dig @localhost www.example.co.jp a		+norecをはずして、正しい回答が帰ってくることを確認
		このとき、example.co.jpを管理しているDNSの情報はキャッシュとして残っているので、
		dns1.example.co.jpかdns2.example.co.jpのどちらかへwww.example.co.jpのＡレコードを問い合わせる
		正しい情報を持っているdns1.example.co.jpから情報を取得できればよいが、またdns2.examp.le.co.jp
		に問い合わせて古い情報を取得する可能性もある
		また、正しい情報をキャッシュしたとしても、キャッシュの有効期限が切れればまた上記の繰り返し
		となるので、根本的な解決はセカンダリDNSへ正しい情報を転送することである


NSレコードとＡレコードが古い場合

[ キャッシュされているデータ ]		[ 正しいデータ ]
①　　example.co.jp. NS IN dns1.example.co.jp.		example.co.jp. NS IN ns001.example.com.
②　　www.example.co.jp. A IN 192.168.0.100		www.example.co.jp. A IN 192.168.54.60
③　　dns1.example.co.jp. A IN 192.168.0.1		ns001.example.com. A IN 192.168.24.150

# dig @localhost example.co.jp ns +norec		キャッシュサーバ自身に問い合わせて、キャッシュされているか確認
# dig @localhost www.example.co.jp a +norec		（＋norecをつけて再帰問い合わせはしないようにする）
		場合によってはネガティブキャッシュされている可能性もある

# rndc dumpdb		ダンプしても大丈夫ならば、キャッシュデータをダンプさせてきちんと確認を取る
# more /var/named/chroot/var/named/data/named_dump


# rndc flushname example.co.jp		最初に①example.co.jpをクリア
		この場合、②と③のレコードはクリアされない
		②だけクリアすると、またdns1.example.co.jpに問い合わせて古いＡレコードをキャッシュしてしまう

# rndc flushname www.example.co.jp		次に②www.example.co.jpをクリアする

# dig @localhost example.co.jp ns +norec		キャッシュがクリアされたことを確認
# dig @localhost www.example.co.jp a +norec		（＋norecをつけて再帰問い合わせはしないようにする）


# dig @localhost www.example.co.jp a		+norecをはずして、回答が帰ってくることを確認
		このとき、example.co.jpを管理するネームサーバ(ns001.example.com）を上位DNSから検索して調べ、
		そのネームサーバへwww.example.co.jpを問い合わせる