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 named or named-chroot service is running.

Procedure

  1. On the existing primary server:

    1. Create a shared key, and append it to the /etc/named.conf file:

      # 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-keygen command and automatically appends it to /etc/named.conf.

      You will require the output of the command later on the secondary server as well.

    2. Edit the zone definition in the /etc/named.conf file:

      1. In the allow-transfer statement, define that servers must provide the key specified in the example-transfer-key statement to transfer a zone:

        zone "example.com" {
            ...
            allow-transfer { key example-transfer-key; };
        };

        Alternatively, use BIND access control list (ACL) nicknames in the allow-transfer statement.

      2. 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 an NS record for the secondary server to the zone, you can, configure that BIND notifies this server anyway. For that, add the also-notify statement with the IP addresses of this secondary server to the zone:

        zone "example.com" {
            ...
            also-notify { 192.0.2.2; 2001:db8:1::2; };
        };
    3. Verify the syntax of the /etc/named.conf file:

      # named-checkconf

      If the command displays no output, the syntax is correct.

    4. Reload BIND:

      # systemctl reload named

      If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

  2. On the future secondary server:

    1. Edit the /etc/named.conf file as follows:

      1. Add the same key definition as on the primary server:

        key "example-transfer-key" {
                algorithm hmac-sha256;
                secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ=";
        };
      2. Add the zone definition to the /etc/named.conf file:

        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 the example.com zone.
        • The /var/named/slaves/example.com.zone file is the zone file. If you set a relative path, as in this example, this path is relative to the directory you set in directory in the options statement. 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.1 and 2001:db8:1::2. Alternatively, you can specify ACL nicknames. This secondary server will use the key named example-transfer-key to authenticate to the primary server.
    2. Verify the syntax of the /etc/named.conf file:

      # named-checkconf
    3. Reload BIND:

      # systemctl reload named

      If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

  3. Optional: Modify the zone file on the primary server and add an NS record for the new secondary server.

Verification

On the secondary server:

  1. Display the systemd journal entries of the named service:

    # 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-chroot command to display the journal entries.

  2. 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.zone

    Note that, by default, secondary servers store zone files in a binary raw format.

  3. Query a record of the transferred zone from the secondary server:

    # dig +short @192.0.2.2 AAAA www.example.com
    2001:db8:1::30

    This example assumes that the secondary server you set up in this procedure listens on IP address 192.0.2.2.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る