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은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동