【Linux】BIND IXFR configuration – read this if it is not effect –

AXFR and IXFR
bind9 default settings
How to set when you want to use IXFR even when changing manual
It may be his business if you can not change permissions.
IT/インフラエンジニアの地位とスキル向上のために

AXFR and IXFR

AXFR and IXFR is both the method of Zone Transfer. AXFR is the method synchronizing all of record in the zone, and IXFR records the previous zone transfer information in the journal file, referring to the journal file during zone transfer and transferring the incremental information.
AXFR / IXFR can be specified when testing the zone transfer with the dig command.

# dig +norec @dns1.example.com example.com axfr
# dig +norec @dns1.example.com example.com ixfr=2018092220

bind9 default settings

As mentioned above, there are AXFR (Full Zone Transfer) and IXFR (Differential Zone Transfer) for zone transfer, and basically IXFR (difference zone transfer) is set up by default in bind9, because default values of provide-ixfr and request-ixfr are "yes".

However, actually looking at the packet with tcpdump etc. shows that the type in the packet is IXFR even if there is no difference (serial change only), but in fact it is Since all information is transferred, it was the same operation as AXFR.

As a result of examination, it seems that only the difference information is sent only when it is automatically updated by Dynamic DNS (Dynamic DNS) by default setting.

In "/var/log/messages" are displayed as follows at the beginning, but this seems to mean "It is requested with type = IXFR from Slave Server, but it will send all the information just like 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

How to set when you want to use IXFR even when changing manual

If you want to use IXFR manually, put the following setting in "zone" clause of Master side.(below "type master")

ixfr-from-differences yes;

o not put it on the Slave side. This is because Slave requests all information to create a difference file. And for some reason default access is denied.

 named[17871]:example.zone.jnl: create: permission denied

To solve this, change / var / named 's permission from 750 to 770.

[root@dns1 var]# ll -d /var/named
drwxr-x---. 6 root named 185 Sep 22 20:12 /var/named
[root@dns1 var]# chmod 770 /var/named
[root@dns1 var]# ll -d /var/named
drwxrwx---. 6 root named 185 Sep 22 20:12 /var/named

Then IXFR can be used safely.

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

You can also see that a. Jnl file (journal file) is generated next to the zone file.

[root@dns1 named]# ls
chroot dynamic example.zone.jnl named.empty named.loopback
data example.zone named.ca named.localhost slaves

It may be his business if you can not change permissions.

If this is not good as well, it is probably SELinux's work, so let's deal with it as follows.

# yum -y install policycoreutils-python
# setenforce 0
- Reproduce the event -
# ausearch -m avc | audit2allow -M bind-patch
# semodule -i bind-patch.pp
# setenforce 1

When reproducing the phenomenon, please set it to Permissive with setenforce 0 and then do it. By doing this you can create the required authorization rules at once.

For the operation management of SELinux please also refer to the following page.