Chapter 4. Setting up and configuring a BIND DNS server

Procedure

1. Install the bind and bind-utils packages:

   # yum install bind bind-utils

   These packages provide BIND 9.11. If you require BIND 9.16, install the bind9.16 and bind9.16-utils packages.

2. If you want to run BIND in a change-root environment install the bind-chroot package:

   # yum install bind-chroot

   Note that running BIND on a host with SELinux in enforcing mode, which is default, is more secure.

3. Edit the /etc/named.conf file, and make the following changes in the options statement:

   1. Update the listen-on and listen-on-v6 statements to specify on which IPv4 and IPv6 interfaces BIND should listen:

      listen-on port 53 { 127.0.0.1; 192.0.2.1; };
      listen-on-v6 port 53 { ::1; 2001:db8:1::1; };

   2. Update the allow-query statement to configure from which IP addresses and ranges clients can query this DNS server:

      allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };

   3. Add an allow-recursion statement to define from which IP addresses and ranges BIND accepts recursive queries:

      allow-recursion { localhost; 192.0.2.0/24; 2001:db8:1::/64; };

      Warning

      Do not allow recursion on public IP addresses of the server. Otherwise, the server can become part of large-scale DNS amplification attacks.

   4. By default, BIND resolves queries by recursively querying from the root servers to an authoritative DNS server. Alternatively, you can configure BIND to forward queries to other DNS servers, such as the ones of your provider. In this case, add a forwarders statement with the list of IP addresses of the DNS servers that BIND should forward queries to:

      forwarders { 198.51.100.1; 203.0.113.5; };

      As a fall-back behavior, BIND resolves queries recursively if the forwarder servers do not respond. To disable this behavior, add a forward only; statement.

4. Verify the syntax of the /etc/named.conf file:

   # named-checkconf

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

5. Update the firewalld rules to allow incoming DNS traffic:

   # firewall-cmd --permanent --add-service=dns
   # firewall-cmd --reload

6. Start and enable BIND:

   # systemctl enable --now named

   If you want to run BIND in a change-root environment, use the systemctl enable --now named-chroot command to enable and start the service.

Verification

1. Use the newly set up DNS server to resolve a domain:

   # dig @localhost www.example.org
   ...
   www.example.org.    86400    IN    A    198.51.100.34
   
   ;; Query time: 917 msec
   ...

   This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

   After querying a record for the first time, BIND adds the entry to its cache.

2. Repeat the previous query:

   # dig @localhost www.example.org
   ...
   www.example.org.    85332    IN    A    198.51.100.34
   
   ;; Query time: 1 msec
   ...

   Because of the cached entry, further requests for the same record are significantly faster until the entry expires.

Procedure

1. Edit the /etc/named.conf file, and add category and channel phrases to the logging statement, for example:

   logging {
       ...
   
       category notify { zone_transfer_log; };
       category xfer-in { zone_transfer_log; };
       category xfer-out { zone_transfer_log; };
       channel zone_transfer_log {
           file "/var/named/log/transfer.log" versions 10 size 50m;
           print-time yes;
           print-category yes;
           print-severity yes;
           severity info;
        };
   
        ...
   };

   With this example configuration, BIND logs messages related to zone transfers to /var/named/log/transfer.log. BIND creates up to 10 versions of the log file and rotates them if they reach a maximum size of 50 MB.

   The category phrase defines to which channels BIND sends messages of a category.

   The channel phrase defines the destination of log messages including the number of versions, the maximum file size, and the severity level BIND should log to a channel. Additional settings, such as enabling logging the time stamp, category, and severity of an event are optional, but useful for debugging purposes.

2. Create the log directory if it does not exist, and grant write permissions to the named user on this directory:

   # mkdir /var/named/log/
   # chown named:named /var/named/log/
   # chmod 700 /var/named/log/

3. Verify the syntax of the /etc/named.conf file:

   # named-checkconf

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

4. Restart BIND:

   # systemctl restart named

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

Procedure

1. Edit the /etc/named.conf file and make the following changes:

   1. Add acl statements to the file. For example, to create an ACL named internal-networks for 127.0.0.1, 192.0.2.0/24, and 2001:db8:1::/64, enter:

      acl internal-networks { 127.0.0.1; 192.0.2.0/24; 2001:db8:1::/64; };
      acl dmz-networks { 198.51.100.0/24; 2001:db8:2::/64; };

   2. Use the ACL’s nickname in statements that support them, for example:

      allow-query { internal-networks; dmz-networks; };
      allow-recursion { internal-networks; };

2. Verify the syntax of the /etc/named.conf file:

   # named-checkconf

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

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.

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.

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.

Procedure

1. Edit the /etc/named.conf file, and make the following changes:

   1. Add a response-policy definition to the options statement:

      options {
          ...
      
          response-policy {
              zone "rpz.local";
          };
      
          ...
      }

      You can set a custom name for the RPZ in the zone statement in response-policy. However, you must use the same name in the zone definition in the next step.

   2. Add a zone definition for the RPZ you set in the previous step:

      zone "rpz.local" {
          type master;
          file "rpz.local";
          allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
          allow-transfer { none; };
      };

      These settings state:

      • This server is the primary server (type master) for the RPZ named rpz.local.
      • The /var/named/rpz.local 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.
      • Any hosts defined in allow-query can query this RPZ. Alternatively, specify IP ranges or BIND access control list (ACL) nicknames to limit the access.
      • No host can transfer the zone. Allow zone transfers only when you set up secondary servers and only for the IP addresses of the secondary servers.

2. Verify the syntax of the /etc/named.conf file:

   # named-checkconf

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

3. Create the /var/named/rpz.local file, for example, with the following content:

   $TTL 10m
   @ IN SOA ns1.example.com. hostmaster.example.com. (
                             2022070601 ; serial number
                             1h         ; refresh period
                             1m         ; retry period
                             3d         ; expire time
                             1m )       ; minimum TTL
   
                    IN NS    ns1.example.com.
   
   example.org      IN CNAME .
   *.example.org    IN CNAME .
   example.net      IN CNAME rpz-drop.
   *.example.net    IN CNAME rpz-drop.

   This zone file:

   • Sets the default time-to-live (TTL) value for resource records to 10 minutes. Without a time suffix, such as h for hour, BIND interprets the value as seconds.
   • Contains the required start of authority (SOA) resource record with details about the zone.
   • Sets ns1.example.com as an authoritative DNS server for this zone. To be functional, a zone requires at least one name server (NS) record. However, to be compliant with RFC 1912, you require at least two name servers.
   • Return an NXDOMAIN error for queries to example.org and hosts in this domain.
   • Drop queries to example.net and hosts in this domain.

   For a full list of actions and examples, see IETF draft: DNS Response Policy Zones (RPZ).

4. Verify the syntax of the /var/named/rpz.local file:

   # named-checkzone rpz.local /var/named/rpz.local
   zone rpz.local/IN: loaded serial 2022070601
   OK

5. 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.

Verification

1. Attempt to resolve a host in example.org, that is configured in the RPZ to return an NXDOMAIN error:

   # dig @localhost www.example.org
   ...
   ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30286
   ...

   This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

2. Attempt to resolve a host in the example.net domain, that is configured in the RPZ to drop queries:

   # dig @localhost www.example.net
   ...
   ;; connection timed out; no servers could be reached
   ...

Procedure

1. Enable dnstap and the target file by editing the /etc/named.conf file in the options block:

   options
   {
   # ...
   dnstap { all; }; # Configure filter
   dnstap-output file "/var/named/data/dnstap.bin";
   # ...
   };
   # end of options

2. To specify which types of DNS traffic you want to log, add dnstap filters to the dnstap block in the /etc/named.conf file. You can use the following filters:

   • auth - Authoritative zone response or answer.
   • client - Internal client query or answer.
   • forwarder - Forwarded query or response from it.
   • resolver - Iterative resolution query or response.
   • update - Dynamic zone update requests.
   • all - Any from the above options.

   • query or response - If you do not specify a query or a response keyword, dnstap records both.

     Note

     The dnstap filter contains multiple definitions delimited by a ; in the dnstap {} block with the following syntax: dnstap { ( all | auth | client | forwarder | resolver | update ) [ ( query | response ) ]; …​ };

3. To apply your changes, restart the named service:

   # systemctl restart named.service

4. Configure a periodic rollout for active logs

   In the following example, the cron scheduler runs the content of the user-edited script once a day. The roll option with the value 3 specifies that dnstap can create up to three backup log files. The value 3 overrides the version parameter of the dnstap-output variable, and limits the number of backup log files to three. Additionally, the binary log file is moved to another directory and renamed, and it never reaches the .2 suffix, even if three backup log files already exist. You can skip this step if automatic rolling of binary logs based on size limit is sufficient.

   Example:
   
   sudoedit /etc/cron.daily/dnstap
   
   #!/bin/sh
   rndc dnstap -roll 3
   mv /var/named/data/dnstap.bin.1 /var/log/named/dnstap/dnstap-$(date -I).bin
   
   # use dnstap-read to analyze saved logs
   sudo chmod a+x /etc/cron.daily/dnstap

5. Handle and analyze logs in a human-readable format by using the dnstap-read utility:

   In the following example, the dnstap-read utility prints the output in the YAML file format.

   Example:
   
   dnstap-read -y [file-name]