【bind/Linux】ゾーン転送の2つの方式 AXFR と IXFR の違いと設定 | SEの道標
DNS

【bind/Linux】ゾーン転送の2つの方式 AXFR と IXFR の違いと設定

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)で自動更新された場合のみ、差分情報だけを送るようになっているようです。

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/deployment_guide/s2-bind-featuresからの引用

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の下などに)

ixfr-from-differences yes;

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 の運用管理については以下のページも参考にしてみて下さい。

【SELinux】audit2allowのインストールと使い方 ~ポリシー追加, .teの書き方, make方法, .ppの内容確認方法~
SELinux のモジュールとは SELinux のポリシールールはいくつかの種...

コメント

タイトルとURLをコピーしました