AXFR と IXFR
AXFR と IXFR は共にゾーン転送の方式で、AXFRは全てのゾーン情報を同期する方式、IXFRは前回のゾーン転送情報をジャーナルファイルに記録しておき、ゾーン転送時にはジャーナルファイルを参照して差分情報のみを転送する方式です。
dig コマンドでゾーン転送のテストを行う際は、AXFR / IXFR の指定が可能です。
# dig +norec @dns1.example.com example.com axfr # dig +norec @dns1.example.com example.com ixfr=2018092220
bind のデフォルト設定
前述の通り、ゾーン転送には AXFR(フルゾーン転送)と IXFR(差分ゾーン転送)がありますが、bind のデフォルト設定では provide-ixfr および request-ixfr が yes となっているため、基本的にIXFR(差分ゾーン転送)が使われます。
ですが実際にtcpdump等でパケットを覗いてみると、差分無し(シリアル変更のみ)の場合であっても、パケット内の type は IXFR であることを示していますが、実際にはそのゾーン内の全ての情報が転送されるため、AXFRと同等の動作になっていました。
調べてみたところ、デフォルト設定ではDynamic DNS(動的DNS)で自動更新された場合のみ、差分情報だけを送るようになっているようです。
IXFR は、動的な更新を使用してマスターゾーンレコードに変更を加える時にのみ使用可能なことに注意して下さい。ゾーンファイルを手動の編集で変更する場合は、Automatic Zone Transfer 自動ゾーン転送 (AXFR) が使用されます。
/var/log/messages には開始時は以下のように表示されますが、これは『Slaveからはtype=IXFR で要求だけど、AXFRと同じように全ての情報を送るよ』という意味のようです。
Sep 22 14:20:45 dns1 named[1387]: client 192.168.100.202#59927 (example.com): transfer of 'example.com/IN': AXFR-style IXFR started Sep 22 14:20:45 dns1 named[1387]: client 192.168.100.202#59927 (example.com): transfer of 'example.com/IN': AXFR-style IXFR ended
手動変更時にも IXFR を使いたい場合の設定方法
手動でも IXFR を使いたいときは、Master側の "zone" clauseに以下の設定を入れます。(type masterの下などに)
Slave側に入れてはいけません。Slave側で差分ファイルを作るために全情報を要求してしまうからです。そしてなぜかデフォルトだとアクセス権拒否されます。
named[17871]:example.zone.jnl: create: permission denied
これを解消するには /var/named のパーミッションを750から770に変更します。
[root@dns1 var]# ll -d /var/named drwxr-x---. 6 root named 185 9月 22 20:12 /var/named [root@dns1 var]# chmod 770 /var/named [root@dns1 var]# ll -d /var/named drwxrwx---. 6 root named 185 9月 22 20:12 /var/named
すると無事に IXFR が使えるようになります。
Sep 22 20:10:31 dns1 named[17871]: client 192.168.100.202#42343 (example.com): transfer of 'example.com/IN': IXFR started Sep 22 20:10:31 dns1 named[17871]: client 192.168.100.202#42343 (example.com): transfer of 'example.com/IN': IXFR ended
ゾーンファイルの横に.jnlファイル(ジャーナルファイル)が生成されることも確認できます。
[root@dns1 named]# ls
chroot dynamic example.zone.jnl named.empty named.loopback
data example.zone named.ca named.localhost slaves
パーミッション変更でもダメな場合は奴の仕業かも?
これでもダメな場合は多分 SELinux の仕業ですので以下のように対処しましょう。
# yum -y install policycoreutils-python # setenforce 0 ~事象を再現~ # ausearch -m avc | audit2allow -M bind-patch # semodule -i bind-patch.pp # setenforce 1
事象を再現する際は setenforce 0 で Permissive にしてから実施して下さい。こうすることで、いっぺんに必要な許可ルールを作成できます。
SELinux の運用管理については以下のページも参考にしてみて下さい。
コメント