Chapter 1. Setting up and configuring a BIND DNS server


To manage Domain Name System (DNS) services, configure the BIND DNS server. BIND is fully compliant with the Internet Engineering Task Force (IETF) DNS standards and draft standards. BIND acts as a caching server for local networks and as a secondary server to ensure high availability for zones.

1.1. Configuring BIND as a caching DNS server

To resolve and cache successful and failed lookup and answer requests to the same records from its cache, configure BIND as a caching DNS server. This can act as an authoritative DNS server for zones and improves the speed of DNS lookup.

Prerequisites

  • You have administrative privileges.
  • The IP address of the server is static.

Procedure

  1. Install the bind and bind-utils packages:

    # dnf install bind bind-utils
    Copy to Clipboard Toggle word wrap
  2. If you want to run BIND in a change-root environment install the bind-chroot package:

    # dnf install bind-chroot
    Copy to Clipboard Toggle word wrap

    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; };
      Copy to Clipboard Toggle word wrap
    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; };
      Copy to Clipboard Toggle word wrap
    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; };
      Copy to Clipboard Toggle word wrap
      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. However, 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; };
      Copy to Clipboard Toggle word wrap

      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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap
  6. Start and enable BIND:

    # systemctl enable --now named
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap
    ...
    __www.example.org.__    __86400__    IN    A    __198.51.100.34__
    
    ;; Query time: __917 msec__
    ...
    Copy to Clipboard Toggle word wrap

    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 query from the last step:

    # dig @localhost www.example.org
    Copy to Clipboard Toggle word wrap
    __www.example.org.__    __85332__    IN    A    __198.51.100.34__
    
    ;; Query time: __1 msec__
    ...
    Copy to Clipboard Toggle word wrap

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

    For details, see the named.conf(5) man page and the /usr/share/doc/bind/sample/etc/named.conf file on your system.

1.2. Configuring logging on a BIND DNS server

To write different events with defined severity level to separate files, configure logging on a BIND DNS server. On the server, the BIND package configures the /etc/named.conf file to use the default_debug channel, which logs entries when debug level is non zero to the /var/named/data/named.run file.

Prerequisites

  • You have already configured BIND as a caching name server.
  • You have started the named or named-chroot service.

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;
         };
    
         ...
    };
    Copy to Clipboard Toggle word wrap

    In 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 timestamp, 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/
    Copy to Clipboard Toggle word wrap
  3. Verify the syntax of the /etc/named.conf file:

    # named-checkconf
    Copy to Clipboard Toggle word wrap

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

  4. Restart BIND:

    # systemctl restart named
    Copy to Clipboard Toggle word wrap

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

Verification

  • Display the content of the log file:

    # cat /var/named/log/transfer.log
    Copy to Clipboard Toggle word wrap
    ...
    __06-Jul-2022 15:08:51.261 xfer-out: info: client @0x7fecbc0b0700 192.0.2.2#36121/key example-transfer-key (example.com): transfer of 'example.com/IN': AXFR started: TSIG example-transfer-key (serial 2022070603)__
    __06-Jul-2022 15:08:51.261 xfer-out: info: client @0x7fecbc0b0700 192.0.2.2#36121/key example-transfer-key (example.com): transfer of 'example.com/IN': AXFR ended__
    Copy to Clipboard Toggle word wrap

    For details, see the named.conf(5) man page on your system.

1.3. Writing BIND access control lists

To prevent unauthorized access and attacks, such as denial of service (DoS), you can control access to certain features of BIND by using access control list (ACL) statements. ACL statements are lists of IP addresses and ranges.

Warning

BIND uses only the first matching entry in an ACL. For example, if you define an ACL { 192.0.2/24; !192.0.2.1; } and the host with IP address 192.0.2.1 connects, BIND grants access even if the second entry excludes this address.

Each ACL has a nickname that you can use in several statements, such as allow-query, which refers to the specified IP addresses and ranges. BIND has the following built-in ACL statements:

  • none: Matches no hosts.
  • any: Matches all hosts.
  • localhost: Matches the loopback addresses 127.0.0.1 and ::1, and the IP addresses of all interfaces on the server that runs BIND.
  • localnets: Matches the loopback addresses 127.0.0.1 and ::1, and all subnets the server that runs BIND is directly connected to.

Prerequisites

  • You have configured BIND as a caching name server.
  • The named or named-chroot service is running.

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; };
      Copy to Clipboard Toggle word wrap
    2. Use the nickname for the ACL in statements that support them, for example:

      allow-query { internal-networks; dmz-networks; };
      allow-recursion { internal-networks; };
      Copy to Clipboard Toggle word wrap
  2. Verify the syntax of the /etc/named.conf file:

    # named-checkconf
    Copy to Clipboard Toggle word wrap

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

  3. Reload BIND:

    # systemctl reload named
    Copy to Clipboard Toggle word wrap

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

Verification

  • Execute an action that triggers a feature, which uses the configured ACL. For example, the ACL allows only recursive queries from the defined IP addresses. In this case, enter the following command on a host that is not within the definition of ACL to try to resolve an external domain:

    # dig +short @192.0.2.1 www.example.com
    Copy to Clipboard Toggle word wrap

    If the command returns no output, access denied for BIND, and the ACL works.

  • Display output on a client, use the last command without the +short option:

    # dig @192.0.2.1 www.example.com
    Copy to Clipboard Toggle word wrap
    ...
    ;; WARNING: recursion requested but not available
    ...
    Copy to Clipboard Toggle word wrap

1.4. Recording DNS queries by using dnstap

To analyze Domain Name System (DNS) traffic patterns, monitor DNS server performance and troubleshoot related issues, record DNS details by using the dnstap interface. To monitor and log incoming name queries for collecting website and IP address details, dnstap records messages sent by the named service.

Prerequisites

  • You have administrative privileges.
  • You have installed the bind package.
Warning

If you already have a BIND version installed and running, adding a new version of BIND overwrites the existing version.

Procedure

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

    options
    {
    # ...
    dnstap { all; }; # Configure filter
    dnstap-output file "/var/named/data/dnstap.bin" versions 2;
    # ...
    };
    # end of options
    Copy to Clipboard Toggle word wrap
  2. Add dnstap filters to the dnstap block in the /etc/named.conf file to specify which types of DNS traffic you want to log. 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 has several definitions delimited by a semicolon (;) in the dnstap {} block with the following syntax: dnstap { ( all | auth | client | forwarder | resolver | update ) [ ( query | response ) ]; …​ };

  3. Change the dnstap-output option by adding additional parameters to customize the behavior of the dnstap utility on the recorded packets:

    • size (unlimited | <size>): Enable automatic rolling over of the dnstap file when its size reaches the specified limit.
    • versions (unlimited | <integer>): Specify the number of automatically rolled files to keep.
    • suffix (increment | timestamp ): Choose the naming convention for rolled out files. By default, the increment starts with .0. However, you can use the UNIX timestamp by setting the timestamp value.

      The following example requests auth responses only, client queries, and both queries and responses of dynamic updates:

      Example:
      
      dnstap {auth response; client query; update;};
      Copy to Clipboard Toggle word wrap
  4. To apply your changes, restart the named service:

    # systemctl restart named.service
    Copy to Clipboard Toggle word wrap
  5. Configure a periodic rollout for active logs:

    # sudoedit /etc/cron.daily/dnstap
    Copy to Clipboard Toggle word wrap
    #!/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
    Copy to Clipboard Toggle word wrap
    • The cron scheduler runs the contents of the user-edited script only one time in 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. This value limits the number of backup log files to three. Also, this option moves the binary log file to another directory and renames it. 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 enough.
  6. Use the dnstap-read utility to read and print output logs in a human-readable format such as a YAML file:

    # dnstap-read -p /var/named/data/dnstap.bin
    Copy to Clipboard Toggle word wrap
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top