bind_zone転送
前回の続き
今回はMasterのZoneファイルをいじって、Slaveに反映されるまでを確認。
Master - test.com.zone
# cat test.com.zone
$ORIGIN .
$TTL 600
test.com IN SOA ns.test.com root.localhost (
2016071101 ; serial
100 ; refresh
14400 ; retry
3600 ; expire
60 ; minimum
)NS ns.test.com
$ORIGIN test.com.
www1 CNAME www
www2 CNAME www.google.co.jp.
www A 192.168.1.212
ns A 192.168.1.212
フルサービスリゾルバ（DNS3）でのdigの結果
# dig @localhost www.test.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> @localhost www.test.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24617
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1;; QUESTION SECTION:
;www.test.com. IN A;; ANSWER SECTION:
www.test.com. 600 IN A 192.168.1.212;; AUTHORITY SECTION:
test.com. 600 IN NS ns.test.com.;; ADDITIONAL SECTION:
ns.test.com. 600 IN A 192.168.1.212;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 11 20:55:57 2016
;; MSG SIZE rcvd: 79
この状態からDNS1のZONEファイルのwwwのAレコード,Serialを修正
変更後
# cat test.com.zone
$ORIGIN .
$TTL 600
test.com IN SOA ns.test.com root.localhost (
2016071103 ; serial
100 ; refresh
14400 ; retry
3600 ; expire
60 ; minimum
)NS ns.test.com
$ORIGIN test.com.
www1 CNAME www
www2 CNAME www.google.co.jp.
www A 192.168.1.213
ns A 192.168.1.212
Refreshが100であることから、最長100秒で、Slave側にZONE転送されると予想
Master側
# date ; rndc reload
2016年 7月 11日 月曜日 20:58:55 JST
server reload successful#
# date ; dig @localhost test.com axfr
2016年 7月 11日 月曜日 20:59:17 JST
;; Connection to ::1#53(::1) for test.com failed: connection refused.; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> @localhost test.com axfr
; (2 servers found)
;; global options: +cmd
test.com. 600 IN SOA ns.test.com. root.localhost. 2016071103 100 14400 3600 60
test.com. 600 IN NS ns.test.com.
ns.test.com. 600 IN A 192.168.1.212
www.test.com. 600 IN A 192.168.1.213
www1.test.com. 600 IN CNAME www.test.com.
www2.test.com. 600 IN CNAME www.google.co.jp.
test.com. 600 IN SOA ns.test.com. root.localhost. 2016071103 100 14400 3600 60
Slave側
# dig @localhost www.test.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32263
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available;; QUESTION SECTION:
;www.test.com. IN A;; ANSWER SECTION:
www.test.com. 600 IN A 192.168.1.213;; AUTHORITY SECTION:
test.com. 600 IN NS ns.test.com.;; ADDITIONAL SECTION:
ns.test.com. 600 IN A 192.168.1.212;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 11 21:02:47 2016
;; MSG SIZE rcvd: 79
100秒前後でコマンドを打てなかったものの、Master側の再読み込み後100秒経過後にSlave側も反映
ただし・・・フルサービスリゾルバで確認すると・・・
DNS3
# date ; dig @localhost www.test.com
2016年 7月 11日 月曜日 21:03:10 JST; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> @localhost www.test.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44473
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1;; QUESTION SECTION:
;www.test.com. IN A;; ANSWER SECTION:
www.test.com. 166 IN A 192.168.1.212;; AUTHORITY SECTION:
test.com. 166 IN NS ns.test.com.;; ADDITIONAL SECTION:
ns.test.com. 166 IN A 192.168.1.212;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 11 21:03:11 2016
;; MSG SIZE rcvd: 79
アドレスは変更前のまま。
これは、ZONEファイルの＄TTLの600秒が有効なため、残り166秒経過しないとだめだと思われる。
実際に166秒以上経過後に再度Dig
# date ; dig @localhost www.test.com
2016年 7月 11日 月曜日 21:07:50 JST; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> @localhost www.test.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6077
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1;; QUESTION SECTION:
;www.test.com. IN A;; ANSWER SECTION:
www.test.com. 600 IN A 192.168.1.213;; AUTHORITY SECTION:
test.com. 600 IN NS ns.test.com.;; ADDITIONAL SECTION:
ns.test.com. 600 IN A 192.168.1.212;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 11 21:07:51 2016
;; MSG SIZE rcvd: 79
166秒以上経過したため、キャッシュがなくなり再度600秒からスタートしたと思われる。 ただし、Aレコードは想定通りの結果。
Zone転送のAレコード変更の確認はとりあえず終わり。
ネガティブキャッシュ or CNAMEは別の機会
