1.6. Configuring zone transfers among BIND DNS servers
Zone transfers ensure that all DNS servers that have a copy of the zone use up-to-date data.
Prerequisites
- On the future primary server, the zone for which you want to set up zone transfers is already configured.
- On the future secondary server, BIND is already configured, for example, as a caching name server.
-
On both servers, the
namedornamed-chrootservice is running.
Procedure
On the existing primary server:
Create a shared key, and append it to the
/etc/named.conffile:# tsig-keygen example-transfer-key | tee -a /etc/named.conf key "example-transfer-key" { algorithm hmac-sha256; secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ="; };This command displays the output of the
tsig-keygencommand and automatically appends it to/etc/named.conf.You will require the output of the command later on the secondary server as well.
Edit the zone definition in the
/etc/named.conffile:In the
allow-transferstatement, define that servers must provide the key specified in theexample-transfer-keystatement to transfer a zone:zone "example.com" { ... allow-transfer { key example-transfer-key; }; };Alternatively, use BIND access control list (ACL) nicknames in the
allow-transferstatement.By default, after a zone has been updated, BIND notifies all name servers which have a name server (
NS) record in this zone. If you do not plan to add anNSrecord for the secondary server to the zone, you can, configure that BIND notifies this server anyway. For that, add thealso-notifystatement with the IP addresses of this secondary server to the zone:zone "example.com" { ... also-notify { 192.0.2.2; 2001:db8:1::2; }; };
Verify the syntax of the
/etc/named.conffile:# named-checkconfIf the command displays no output, the syntax is correct.
Reload BIND:
# systemctl reload namedIf you run BIND in a change-root environment, use the
systemctl reload named-chrootcommand to reload the service.
On the future secondary server:
Edit the
/etc/named.conffile as follows:Add the same key definition as on the primary server:
key "example-transfer-key" { algorithm hmac-sha256; secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ="; };Add the zone definition to the
/etc/named.conffile:zone "example.com" { type slave; file "slaves/example.com.zone"; allow-query { any; }; allow-transfer { none; }; masters { 192.0.2.1 key example-transfer-key; 2001:db8:1::1 key example-transfer-key; }; };These settings state:
-
This server is a secondary server (
type slave) for theexample.comzone. -
The
/var/named/slaves/example.com.zonefile is the zone file. If you set a relative path, as in this example, this path is relative to the directory you set indirectoryin theoptionsstatement. To separate zone files for which this server is secondary from primary ones, you can store them, for example, in the/var/named/slaves/directory. - Any host can query this zone. Alternatively, specify IP ranges or ACL nicknames to limit the access.
- No host can transfer the zone from this server.
-
The IP addresses of the primary server of this zone are
192.0.2.1and2001:db8:1::2. Alternatively, you can specify ACL nicknames. This secondary server will use the key namedexample-transfer-keyto authenticate to the primary server.
-
This server is a secondary server (
Verify the syntax of the
/etc/named.conffile:# named-checkconfReload BIND:
# systemctl reload namedIf you run BIND in a change-root environment, use the
systemctl reload named-chrootcommand to reload the service.
-
Optional: Modify the zone file on the primary server and add an
NSrecord for the new secondary server.
Verification
On the secondary server:
Display the
systemdjournal entries of thenamedservice:# journalctl -u named ... Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: Transfer started. Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: connected using 192.0.2.2#45803 Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: transferred serial 2022070101 Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer status: success Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer completed: 1 messages, 29 records, 2002 bytes, 0.003 secs (667333 bytes/sec)If you run BIND in a change-root environment, use the
journalctl -u named-chrootcommand to display the journal entries.Verify that BIND created the zone file:
# ls -l /var/named/slaves/ total 4 -rw-r--r--. 1 named named 2736 Jul 6 15:08 example.com.zoneNote that, by default, secondary servers store zone files in a binary raw format.
Query a record of the transferred zone from the secondary server:
# dig +short @192.0.2.2 AAAA www.example.com 2001:db8:1::30This example assumes that the secondary server you set up in this procedure listens on IP address
192.0.2.2.