Chapter 1. Setting up and configuring a BIND DNS server BIND is a feature-rich DNS server that is fully compliant with the Internet Engineering Task Force (IETF) DNS standards and draft standards. For example, administrators frequently use BIND as: Caching DNS server in the local network Authoritative DNS server for zones Secondary server to provide high availability for zones 1.1. Considerations about protecting BIND with SELinux or running it in a change-root environment To secure a BIND installation, you can: Run the named service without a change-root environment. In this case, SELinux in enforcing mode prevents exploitation of known BIND security vulnerabilities. By default, Red Hat Enterprise Linux uses SELinux in enforcing mode. Important Running BIND on RHEL with SELinux in enforcing mode is more secure than running BIND in a change-root environment. Run the named-chroot service in a change-root environment. Using the change-root feature, administrators can define that the root directory of a process and its sub-processes is different to the / directory. When you start the named-chroot service, BIND switches its root directory to /var/named/chroot/ . As a consequence, the service uses mount --bind commands to make the files and directories listed in /etc/named-chroot.files available in /var/named/chroot/ , and the process has no access to files outside of /var/named/chroot/ . If you decide to use BIND: In normal mode, use the named service. In a change-root environment, use the named-chroot service. This requires that you install, additionally, the named-chroot package. 1.2. Configuring BIND as a caching DNS server By default, the BIND DNS server resolves and caches successful and failed lookups. The service then answers requests to the same records from its cache. This significantly improves the speed of DNS lookups. Prerequisites The IP address of the server is static. Procedure Install the bind and bind-utils packages: If you want to run BIND in a change-root environment install the bind-chroot package: Note that running BIND on a host with SELinux in enforcing mode, which is default, is more secure. Edit the /etc/named.conf file, and make the following changes in the options statement: Update the listen-on and listen-on-v6 statements to specify on which IPv4 and IPv6 interfaces BIND should listen: Update the allow-query statement to configure from which IP addresses and ranges clients can query this DNS server: Add an allow-recursion statement to define from which IP addresses and ranges BIND accepts recursive queries: Warning Do not allow recursion on public IP addresses of the server. Otherwise, the server can become part of large-scale DNS amplification attacks. 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: 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. Verify the syntax of the /etc/named.conf file: If the command displays no output, the syntax is correct. Update the firewalld rules to allow incoming DNS traffic: Start and enable BIND: 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 Use the newly set up DNS server to resolve a domain: 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. Repeat the query: Because of the cached entry, further requests for the same record are significantly faster until the entry expires. steps Configure the clients in your network to use this DNS server. If a DHCP server provides the DNS server setting to the clients, update the DHCP server's configuration accordingly. Additional resources Considerations about protecting BIND with SELinux or running it in a change-root environment named.conf(5) man page on your system /usr/share/doc/bind/sample/etc/named.conf 1.3. Configuring logging on a BIND DNS server The configuration in the default /etc/named.conf file, as provided by the bind package, uses the default_debug channel and logs messages to the /var/named/data/named.run file. The default_debug channel only logs entries when the server's debug level is non-zero. Using different channels and categories, you can configure BIND to write different events with a defined severity to separate files. Prerequisites BIND is already configured, for example, as a caching name server. The named or named-chroot service is running. Procedure Edit the /etc/named.conf file, and add category and channel phrases to the logging statement, for example: 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. Create the log directory if it does not exist, and grant write permissions to the named user on this directory: Verify the syntax of the /etc/named.conf file: If the command displays no output, the syntax is correct. Restart BIND: 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: Additional resources named.conf(5) man page on your system 1.4. Writing BIND ACLs Controlling access to certain features of BIND can prevent unauthorized access and attacks, such as denial of service (DoS). BIND access control list ( acl ) statements are lists of IP addresses and ranges. Each ACL has a nickname that you can use in several statements, such as allow-query , to refer to the specified 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, access is granted even if the second entry excludes this address. BIND has the following built-in ACLs: none : Matches no hosts. any : Matches all hosts. localhost : Matches the loopback addresses 127.0.0.1 and ::1 , as well as the IP addresses of all interfaces on the server that runs BIND. localnets : Matches the loopback addresses 127.0.0.1 and ::1 , as well as all subnets the server that runs BIND is directly connected to. Prerequisites BIND is already configured, for example, as a caching name server. The named or named-chroot service is running. Procedure Edit the /etc/named.conf file and make the following changes: 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: Use the ACL's nickname in statements that support them, for example: Verify the syntax of the /etc/named.conf file: If the command displays no output, the syntax is correct. Reload BIND: 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 in this procedure allows only recursive queries from the defined IP addresses. In this case, enter the following command on a host that is not within the ACL's definition to attempt resolving an external domain: If the command returns no output, BIND denied access, and the ACL works. For a verbose output on the client, use the command without +short option: 1.5. Configuring zones on a BIND DNS server A DNS zone is a database with resource records for a specific sub-tree in the domain space. For example, if you are responsible for the example.com domain, you can set up a zone for it in BIND. As a result, clients can, resolve www.example.com to the IP address configured in this zone. 1.5.1. The SOA record in zone files The start of authority (SOA) record is a required record in a DNS zone. This record is important, for example, if multiple DNS servers are authoritative for a zone but also to DNS resolvers. A SOA record in BIND has the following syntax: For better readability, administrators typically split the record in zone files into multiple lines with comments that start with a semicolon ( ; ). Note that, if you split a SOA record, parentheses keep the record together: Important Note the trailing dot at the end of the fully-qualified domain names (FQDNs). FQDNs consist of multiple domain labels, separated by dots. Because the DNS root has an empty label, FQDNs end with a dot. Therefore, BIND appends the zone name to names without a trailing dot. A hostname without a trailing dot, for example, ns1.example.com would be expanded to ns1.example.com.example.com. , which is not the correct address of the primary name server. These are the fields in a SOA record: name : The name of the zone, the so-called origin . If you set this field to @ , BIND expands it to the zone name defined in /etc/named.conf . class : In SOA records, you must set this field always to Internet ( IN ). type : In SOA records, you must set this field always to SOA . mname (master name): The hostname of the primary name server of this zone. rname (responsible name): The email address of who is responsible for this zone. Note that the format is different. You must replace the at sign ( @ ) with a dot ( . ). serial : The version number of this zone file. Secondary name servers only update their copies of the zone if the serial number on the primary server is higher. The format can be any numeric value. A commonly-used format is <year><month><day><two-digit-number> . With this format, you can, theoretically, change the zone file up to a hundred times per day. refresh : The amount of time secondary servers should wait before checking the primary server if the zone was updated. retry : The amount of time after that a secondary server retries to query the primary server after a failed attempt. expire : The amount of time after that a secondary server stops querying the primary server, if all attempts failed. minimum : RFC 2308 changed the meaning of this field to the negative caching time. Compliant resolvers use it to determine how long to cache NXDOMAIN name errors. Note A numeric value in the refresh , retry , expire , and minimum fields define a time in seconds. However, for better readability, use time suffixes, such as m for minute, h for hours, and d for days. For example, 3h stands for 3 hours. Additional resources RFC 1035 : Domain names - implementation and specification RFC 1034 : Domain names - concepts and facilities RFC 2308 : Negative caching of DNS queries (DNS cache) 1.5.2. Setting up a forward zone on a BIND primary server Forward zones map names to IP addresses and other information. For example, if you are responsible for the domain example.com , you can set up a forward zone in BIND to resolve names, such as www.example.com . Prerequisites BIND is already configured, for example, as a caching name server. The named or named-chroot service is running. Procedure Add a zone definition to the /etc/named.conf file: These settings define: This server as the primary server ( type master ) for the example.com zone. The /var/named/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. Any host can query this zone. 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. Verify the syntax of the /etc/named.conf file: If the command displays no output, the syntax is correct. Create the /var/named/example.com.zone file, for example, with the following content: This zone file: Sets the default time-to-live (TTL) value for resource records to 8 hours. Without a time suffix, such as h for hour, BIND interprets the value as seconds. Contains the required 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. Sets mail.example.com as the mail exchanger ( MX ) of the example.com domain. The numeric value in front of the host name is the priority of the record. Entries with a lower value have a higher priority. Sets the IPv4 and IPv6 addresses of www.example.com , mail.example.com , and ns1.example.com . Set secure permissions on the zone file that allow only the named group to read it: Verify the syntax of the /var/named/example.com.zone file: Reload BIND: If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service. Verification Query different records from the example.com zone, and verify that the output matches the records you have configured in the zone file: This example assumes that BIND runs on the same host and responds to queries on the localhost interface. Additional resources The SOA record in zone files Writing BIND ACLs RFC 1912 - Common DNS operational and configuration errors 1.5.3. Setting up a reverse zone on a BIND primary server Reverse zones map IP addresses to names. For example, if you are responsible for IP range 192.0.2.0/24 , you can set up a reverse zone in BIND to resolve IP addresses from this range to hostnames. Note If you create a reverse zone for whole classful networks, name the zone accordingly. For example, for the class C network 192.0.2.0/24 , the name of the zone is 2.0.192.in-addr.arpa . If you want to create a reverse zone for a different network size, for example 192.0.2.0/28 , the name of the zone is 28-2.0.192.in-addr.arpa . Prerequisites BIND is already configured, for example, as a caching name server. The named or named-chroot service is running. Procedure Add a zone definition to the /etc/named.conf file: These settings define: This server as the primary server ( type master ) for the 2.0.192.in-addr.arpa reverse zone. The /var/named/2.0.192.in-addr.arpa.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. Any host can query this zone. 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. Verify the syntax of the /etc/named.conf file: If the command displays no output, the syntax is correct. Create the /var/named/2.0.192.in-addr.arpa.zone file, for example, with the following content: This zone file: Sets the default time-to-live (TTL) value for resource records to 8 hours. Without a time suffix, such as h for hour, BIND interprets the value as seconds. Contains the required SOA resource record with details about the zone. Sets ns1.example.com as an authoritative DNS server for this reverse 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. Sets the pointer ( PTR ) record for the 192.0.2.1 and 192.0.2.30 addresses. Set secure permissions on the zone file that only allow the named group to read it: Verify the syntax of the /var/named/2.0.192.in-addr.arpa.zone file: Reload BIND: If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service. Verification Query different records from the reverse zone, and verify that the output matches the records you have configured in the zone file: This example assumes that BIND runs on the same host and responds to queries on the localhost interface. Additional resources The SOA record in zone files Writing BIND ACLs RFC 1912 - Common DNS operational and configuration errors 1.5.4. Updating a BIND zone file In certain situations, for example if an IP address of a server changes, you must update a zone file. If multiple DNS servers are responsible for a zone, perform this procedure only on the primary server. Other DNS servers that store a copy of the zone will receive the update through a zone transfer. Prerequisites The zone is configured. The named or named-chroot service is running. Procedure Optional: Identify the path to the zone file in the /etc/named.conf file: You find the path to the zone file in the file statement in the zone's definition. A relative path is relative to the directory set in directory in the options statement. Edit the zone file: Make the required changes. Increment the serial number in the start of authority (SOA) record. Important If the serial number is equal to or lower than the value, secondary servers will not update their copy of the zone. Verify the syntax of the zone file: Reload BIND: If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service. Verification Query the record you have added, modified, or removed, for example: This example assumes that BIND runs on the same host and responds to queries on the localhost interface. Additional resources The SOA record in zone files Setting up a forward zone on a BIND primary server Setting up a reverse zone on a BIND primary server 1.5.5. DNSSEC zone signing using the automated key generation and zone maintenance features You can sign zones with domain name system security extensions (DNSSEC) to ensure authentication and data integrity. Such zones contain additional resource records. Clients can use them to verify the authenticity of the zone information. If you enable the DNSSEC policy feature for a zone, BIND performs the following actions automatically: Creates the keys Signs the zone Maintains the zone, including re-signing and periodically replacing the keys. Important To enable external DNS servers to verify the authenticity of a zone, you must add the public key of the zone to the parent zone. Contact your domain provider or registry for further details on how to accomplish this. This procedure uses the built-in default DNSSEC policy in BIND. This policy uses single ECDSAP256SHA key signatures. Alternatively, create your own policy to use custom keys, algorithms, and timings. Prerequisites The zone for which you want to enable DNSSEC is configured. The named or named-chroot service is running. The server synchronizes the time with a time server. An accurate system time is important for DNSSEC validation. Procedure Edit the /etc/named.conf file, and add dnssec-policy default; to the zone for which you want to enable DNSSEC: Reload BIND: If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service. BIND stores the public key in the /var/named/K <zone_name> .+ <algorithm> + <key_ID> .key file. Use this file to display the public key of the zone in the format that the parent zone requires: DS record format: DNSKEY format: Request to add the public key of the zone to the parent zone. Contact your domain provider or registry for further details on how to accomplish this. Verification Query your own DNS server for a record from the zone for which you enabled DNSSEC signing: This example assumes that BIND runs on the same host and responds to queries on the localhost interface. After the public key has been added to the parent zone and propagated to other servers, verify that the server sets the authenticated data ( ad ) flag on queries to the signed zone: Additional resources Setting up a forward zone on a BIND primary server Setting up a reverse zone on a BIND primary server 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 On the existing primary server: Create a shared key, and append it to the /etc/named.conf file: 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. Edit the zone definition in the /etc/named.conf file: In the allow-transfer statement, define that servers must provide the key specified in the example-transfer-key statement to transfer a zone: Alternatively, use BIND access control list (ACL) nicknames in the allow-transfer statement. 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: Verify the syntax of the /etc/named.conf file: If the command displays no output, the syntax is correct. Reload BIND: If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service. On the future secondary server: Edit the /etc/named.conf file as follows: Add the same key definition as on the primary server: Add the zone definition to the /etc/named.conf file: 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. Verify the syntax of the /etc/named.conf file: Reload BIND: If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service. Optional: Modify the zone file on the primary server and add an NS record for the new secondary server. Verification On the secondary server: Display the systemd journal entries of the named service: If you run BIND in a change-root environment, use the journalctl -u named-chroot command to display the journal entries. Verify that BIND created the zone file: Note that, by default, secondary servers store zone files in a binary raw format. Query a record of the transferred zone from the secondary server: This example assumes that the secondary server you set up in this procedure listens on IP address 192.0.2.2 . Additional resources Setting up a forward zone on a BIND primary server Setting up a reverse zone on a BIND primary server Writing BIND ACLs Updating a BIND zone file 1.7. Configuring response policy zones in BIND to override DNS records Using DNS blocking and filtering, administrators can rewrite a DNS response to block access to certain domains or hosts. In BIND, response policy zones (RPZs) provide this feature. You can configure different actions for blocked entries, such as returning an NXDOMAIN error or not responding to the query. If you have multiple DNS servers in your environment, use this procedure to configure the RPZ on the primary server, and later configure zone transfers to make the RPZ available on your secondary servers. Prerequisites BIND is already configured, for example, as a caching name server. The named or named-chroot service is running. Procedure Edit the /etc/named.conf file, and make the following changes: Add a response-policy definition to the options statement: 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 step. Add a zone definition for the RPZ you set in the step: 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. Verify the syntax of the /etc/named.conf file: If the command displays no output, the syntax is correct. Create the /var/named/rpz.local file, for example, with the following content: 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) . Verify the syntax of the /var/named/rpz.local file: Reload BIND: If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service. Verification Attempt to resolve a host in example.org , that is configured in the RPZ to return an NXDOMAIN error: This example assumes that BIND runs on the same host and responds to queries on the localhost interface. Attempt to resolve a host in the example.net domain, that is configured in the RPZ to drop queries: Additional resources IETF draft: DNS Response Policy Zones (RPZ) 1.8. Recording DNS queries by using dnstap As a network administrator, you can record Domain Name System (DNS) details to analyze DNS traffic patterns, monitor DNS server performance, and troubleshoot DNS issues. If you want an advanced way to monitor and log details of incoming name queries, use the dnstap interface that records sent messages from the named service. You can capture and record DNS queries to collect information about websites or IP addresses. Prerequisites The bind-9.16.23-1 package or a later version is installed. Warning If you already have a BIND version installed and running, adding a new version of BIND will overwrite the existing version. Procedure Enable dnstap and the target file by editing the /etc/named.conf file in the options block: 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 ) ]; ... }; To customize the behavior of the dnstap utility on the recorded packets, modify the dnstap-output option by providing additional parameters, as follows: 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 . Alternatively, 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 : To apply your changes, restart the named service: 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. 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.

Commands:
dnf install bind bind-utils
dnf install bind-chroot
listen-on port 53 { 127.0.0.1; 192.0.2.1; }; listen-on-v6 port 53 { ::1; 2001:db8:1::1; };
allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
allow-recursion { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
forwarders { 198.51.100.1; 203.0.113.5; };
named-checkconf
firewall-cmd --permanent --add-service=dns firewall-cmd --reload
systemctl enable --now named
dig @ localhost www.example.org www.example.org. 86400 IN A 198.51.100.34 ;; Query time: 917 msec
dig @ localhost www.example.org www.example.org. 85332 IN A 198.51.100.34 ;; Query time: 1 msec
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; }; };
mkdir /var/named/log/ chown named:named /var/named/log/ chmod 700 /var/named/log/
named-checkconf
systemctl restart named
cat /var/named/log/transfer.log 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
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; };
allow-query { internal-networks; dmz-networks; }; allow-recursion { internal-networks; };
named-checkconf
systemctl reload named
dig +short @ 192.0.2.1 www.example.com
dig @ 192.0.2.1 www.example.com ;; WARNING: recursion requested but not available
name class type mname rname serial refresh retry expire minimum
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2022070601 ; serial number 1d ; refresh period 3h ; retry period 3d ; expire time 3h ) ; minimum TTL
zone " example.com " { type master; file " example.com.zone "; allow-query { any; }; allow-transfer { none; }; };
named-checkconf
USDTTL 8h @ IN SOA ns1.example.com. hostmaster.example.com. ( 2022070601 ; serial number 1d ; refresh period 3h ; retry period 3d ; expire time 3h ) ; minimum TTL IN NS ns1.example.com. IN MX 10 mail.example.com. www IN A 192.0.2.30 www IN AAAA 2001:db8:1::30 ns1 IN A 192.0.2.1 ns1 IN AAAA 2001:db8:1::1 mail IN A 192.0.2.20 mail IN AAAA 2001:db8:1::20
chown root:named /var/named/ example.com.zone chmod 640 /var/named/ example.com.zone
named-checkzone example.com /var/named/example.com.zone zone example.com/IN : loaded serial 2022070601 OK
systemctl reload named
dig +short @ localhost AAAA www.example.com 2001:db8:1::30 dig +short @ localhost NS example.com ns1.example.com. dig +short @ localhost A ns1.example.com 192.0.2.1
zone " 2.0.192.in-addr.arpa " { type master; file " 2.0.192.in-addr.arpa.zone "; allow-query { any; }; allow-transfer { none; }; };
named-checkconf
USDTTL 8h @ IN SOA ns1.example.com. hostmaster.example.com. ( 2022070601 ; serial number 1d ; refresh period 3h ; retry period 3d ; expire time 3h ) ; minimum TTL IN NS ns1.example.com. 1 IN PTR ns1.example.com. 30 IN PTR www.example.com.
chown root:named /var/named/ 2.0.192.in-addr.arpa.zone chmod 640 /var/named/ 2.0.192.in-addr.arpa.zone
named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.in-addr.arpa.zone zone 2.0.192.in-addr.arpa/IN : loaded serial 2022070601 OK
systemctl reload named
dig +short @ localhost -x 192.0.2.1 ns1.example.com. dig +short @ localhost -x 192.0.2.30 www.example.com.
options { directory " /var/named "; } zone " example.com " { file " example.com.zone "; };
named-checkzone example.com /var/named/example.com.zone zone example.com/IN : loaded serial 2022062802 OK
systemctl reload named
dig +short @ localhost A ns2.example.com 192.0.2.2
zone " example.com " { dnssec-policy default; };
systemctl reload named
dnssec-dsfromkey /var/named/K example.com.+013+61141 .key example.com. IN DS 61141 13 2 3E184188CF6D2521EDFDC3F07CFEE8D0195AACBD85E68BAE0620F638B4B1B027
grep DNSKEY /var/named/K example.com.+013+61141.key example.com. 3600 IN DNSKEY 257 3 13 sjzT3jNEp120aSO4mPEHHSkReHUf7AABNnT8hNRTzD5cKMQSjDJin2I3 5CaKVcWO1pm+HltxUEt+X9dfp8OZkg==
dig +dnssec +short @ localhost A www.example.com 192.0.2.30 A 13 3 28800 20220718081258 20220705120353 61141 example.com. e7Cfh6GuOBMAWsgsHSVTPh+JJSOI/Y6zctzIuqIU1JqEgOOAfL/Qz474 M0sgi54m1Kmnr2ANBKJN9uvOs5eXYw==
dig @ localhost example.com +dnssec ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
tsig-keygen example-transfer-key | tee -a /etc/named.conf key " example-transfer-key " { algorithm hmac-sha256; secret " q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ= "; };
zone " example.com " { allow-transfer { key example-transfer-key; }; };
zone " example.com " { also-notify { 192.0.2.2; 2001:db8:1::2; }; };
named-checkconf
systemctl reload named
key " example-transfer-key " { algorithm hmac-sha256; secret " q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ= "; };
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; }; };
named-checkconf
systemctl reload named
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)
ls -l /var/named/slaves/ total 4 -rw-r--r--. 1 named named 2736 Jul 6 15:08 example.com.zone
dig +short @ 192.0.2.2 AAAA www.example.com 2001:db8:1::30
options { response-policy { zone " rpz.local "; }; }
zone "rpz.local" { type master; file "rpz.local"; allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; }; allow-transfer { none; }; };
named-checkconf
USDTTL 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.
named-checkzone rpz.local /var/named/rpz.local zone rpz.local/IN : loaded serial 2022070601 OK
systemctl reload named
dig @localhost www.example.org ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN , id: 30286
dig @localhost www.example.net ;; connection timed out; no servers could be reached
options { dnstap { all; }; # Configure filter dnstap-output file "/var/named/data/dnstap.bin" versions 2; }; end of options
Example: dnstap {auth response; client query; update;};
systemctl restart named.service
Example: sudoedit /etc/cron.daily/dnstap #!/bin/sh rndc dnstap -roll 3 mv /var/named/data/dnstap.bin.1 /var/log/named/dnstap/dnstap-USD(date -I).bin use dnstap-read to analyze saved logs sudo chmod a+x /etc/cron.daily/dnstap
Example: dnstap-read -p /var/named/data/dnstap.bin