Chapter 2. Configuring zones on a BIND DNS server

2.1. The start of authority record in zone files
Copia collegamento

To manage several DNS servers authoritative for a zone and DNS resolvers, you can use the start of authority (SOA) record. This record is essential in a DNS zone.

A SOA record in BIND has the following syntax:

name class type mname rname serial refresh retry expire minimum

For better readability, you need to split the record in zone files into several lines with comments that start with a semicolon (;). Note that, if you split a SOA record, parentheses keep the record together:

@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

Important

Note the trailing dot at the end of the fully-qualified domain name (FQDN). FQDN consists of several domain labels, separated by dots. Because the DNS root has an empty label, FQDN ends with a dot. Therefore, BIND appends the zone name to the names without a trailing dot.

A hostname without a trailing dot, for example, ns1.example.com expands 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 update is successful.
retry: The amount of time after which a secondary server retries to query the primary server if the zone update is unsuccessful.
expire: The amount of time after which a secondary server stops querying the primary server, if all earlier attempts failed.
minimum: RFC 2308 changed the meaning of this field to the negative caching time. Compliant resolvers use it to decide 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.

2.2. Setting up a forward zone on a BIND primary server
Copia collegamento

To enable mapping domain names to IP addresses and other information, set up a forward zone on a BIND primary server. For example, if you are responsible for the example.com domain, you can set up a forward zone in BIND to resolve names, such as www.example.com.

Prerequisites

You have installed the bind package on the server.
You have configured the server to run as a caching name server.
The named or named-chroot service is running.

Procedure

Add a zone definition to the /etc/named.conf file:
```
zone "example.com" {
    type master;
    file "example.com.zone";
    allow-query { any; };
    allow-transfer { none; };
};
```
These settings define:
- This server is 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. However, you can 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:
```
# named-checkconf
```
If the command displays no output, the syntax is correct.

Create the /var/named/example.com.zone file, for example, with the following content:

$TTL 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

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.
Has 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.
Sets mail.example.com as the mail exchanger (MX) of the example.com domain. The numeric value in front of the hostname 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:

# chown root:named /var/named/example.com.zone
# chmod 640 /var/named/example.com.zone

Verify the syntax of the /var/named/example.com.zone file:

# named-checkzone example.com /var/named/example.com.zone
zone example.com/IN: loaded serial 2022070601
OK

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

Query different records from the example.com zone, and verify that the output matches the records you have configured in the zone file:
```
# 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
```
This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

2.3. Setting up a reverse zone on a BIND primary server
Copia collegamento

To map IP addresses to names, you can set up a reverse zone on a BIND primary server. For example, if you have the 192.0.2.0/24 IP range, 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 classful IP addresses for a specific network, name the zone likewise. 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

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

Procedure

Add a zone definition to the /etc/named.conf file:
```
zone "2.0.192.in-addr.arpa" {
    type master;
    file "2.0.192.in-addr.arpa.zone";
    allow-query { any; };
    allow-transfer { none; };
};
```
These settings define:
- This server is 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. However, you can 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:
```
# named-checkconf
```
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:

$TTL 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.

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.
Has the required Start of Authority (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:

# chown root:named /var/named/2.0.192.in-addr.arpa.zone
# chmod 640 /var/named/2.0.192.in-addr.arpa.zone

Verify the syntax of the /var/named/2.0.192.in-addr.arpa.zone file:

# 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

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

Query different records from the reverse zone, and verify that the output matches the records you have configured in the zone file:
```
# dig +short @localhost -x 192.0.2.1
```
```
ns1.example.com
```
```
# dig +short @localhost -x 192.0.2.30
```
```
www.example.com
```
This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

2.4. Updating a BIND zone file
Copia collegamento

To update several DNS servers authoritative for a zone, update a zone file only on the primary server. For example, if you change the IP address of a server, you need to update the zone file. Other DNS servers that store a copy of the zone receive the update through a zone transfer.

Prerequisites

You have configured a zone.
You have started the named or named-chroot service.
You have administrative privileges.

Procedure

Optional: Identify the path to the zone file in the /etc/named.conf file:
```
options {
    ...
    directory       "/var/named";
}

zone "example.com" {
    ...
    file "example.com.zone";
};
```
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:
1. Make the required changes.
2. Increment the serial number in the start of authority (SOA) record.
  Important
  If the serial number is equal to or lower than the former value, secondary servers will not update their copy of the zone.

Verify the syntax of the zone file:

# named-checkzone example.com /var/named/example.com.zone

zone __example.com/IN__: loaded serial __2022062802__
OK

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

Query the record you have added, modified, or removed, for example:
```
# dig +short @localhost A ns2.example.com
```
```
192.0.2.2
```
This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

2.5. DNSSEC zone signing using the automated key generation and zone maintenance features
Copia collegamento

To ensure authenticity of zone information for clients, you can sign zones with Domain Name System Security Extensions (DNSSEC). Signed zones contain additional resource records.

Important

For enabling external DNS servers to verify the authenticity of a zone, add the public key of the zone to the parent zone. Contact your domain provider or registry for further details.

After enabling the DNSSEC policy feature for a zone, BIND automatically performs actions. It includes creating the keys, signing the zone, and maintaining the zone, including re-signing and periodically replacing the keys. In BIND, you can use the built-in default DNSSEC policy, which uses single ECDSAP256SHA key signatures. However, create your own policy to use custom keys, algorithms, and timings.

Prerequisites

You have installed the bind package on the server.
You have configured the zone for which you want to enable DNSSEC.
The named or named-chroot service is running.
You have configured the server to synchronize the time with a time server. Always check for the correct system time before enabling DNSSEC validation.

Procedure

Add the dnssec-policy default; and inline-signing yes; in the /etc/named.conf file to enable DNSSEC for the zone:
```
zone "example.com" {
    ...
    dnssec-policy default;
    inline-signing yes;
};
```
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.

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:

# dnssec-dsfromkey /var/named/Kexample.com.+013+61141.key

example.com. IN DS 61141 13 2 3E184188CF6D2521EDFDC3F07CFEE8D0195AACBD85E68BAE0620F638B4B1B027

DNSKEY format:

# grep DNSKEY /var/named/Kexample.com.+013+61141.key

example.com. 3600 IN DNSKEY 257 3 13 sjzT3jNEp120aSO4mPEHHSkReHUf7AABNnT8hNRTzD5cKMQSjDJin2I3 5CaKVcWO1pm+HltxUEt+X9dfp8OZkg==

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 do this.

Verification

Query your own DNS server for a record from the zone for which you enabled DNSSEC signing:

# 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==

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

After the server adds the public key to the parent zone and propagates it to other servers, verify that the server sets the authenticated data (ad) flag on queries to the signed zone:
```
# dig @localhost example.com +dnssec
```
```
...
;; flags: qr rd ra **ad**; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
```

2.6. Configuring zone transfers among BIND DNS servers
Copia collegamento

To ensure that all DNS servers that have a copy of the zone to have up-to-date data, configure zone transfers among BIND DNS servers.

Prerequisites

You have the administrative privileges.
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 as a caching name server.
On both servers, the named or named-chroot service is running.

Procedure

On the existing primary server:
1. Generate 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=__"; };
  Output appends to the /etc/named.conf file.
  You will require this output later on the secondary server as well.
2. In the allow-transfer statement, configure the zone in the /etc/named.conf file to require the key for transfers:
  zone "example.com" { ... allow-transfer { key example-transfer-key; }; };
  Define that servers must have the key specified in the example-transfer-key statement to transfer a zone. However, you can use BIND access control list (ACL) nicknames in the allow-transfer statement.
3. Configure the zone to display the secondary server IP addresses:
  zone "example.com" { ... also-notify { 192.0.2.2; 2001:db8:1::2; }; };
  By default, after updating a zone, BIND notifies all name servers that 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:
4. Verify the syntax of the /etc/named.conf file:
  # named-checkconf
  If the command displays no output, the syntax is correct.
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.
On the future secondary server:
1. Add the shared key block to /etc/named.conf (same as the primary server):
  key "example-transfer-key" { algorithm hmac-sha256; secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ="; };
  1. Add the secondary 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; }; };
    
    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. However, you can 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. However, 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.
Optional: Add an NS record for the new secondary server to the zone file on the primary server.

Verification

On the secondary server:

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.

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

2.7. Configuring response policy zones in BIND to override DNS records
Copia collegamento

To rewrite a DNS response to block access to certain domains or hosts by using DNS blocking and filtering, configure response policy zones (RPZ) in BIND. You can configure different actions for blocked entries, such as returning an NXDOMAIN error or not responding to the query.

If you have several DNS servers, configure the RPZ on the primary server, and later configure zone transfers to make the RPZ available on the secondary servers.

Prerequisites

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

Procedure

Edit the /etc/named.conf file to 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.
Add a zone definition for the RPZ you set in the last step:
```
zone "rpz.local" {
    type master;
    file "rpz.local";
    allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
    allow-transfer { none; };
};
```
- This server is the primary server (type master) for the RPZ named rpz.local.
- The /var/named/rpz.local file is the zone file. In this example, if you set a relative path, 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. However, 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:
```
# named-checkconf
```
If the command displays no output, the syntax is correct.

Create the /var/named/rpz.local file 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 .
pass:[].example.org IN CNAME .example.net IN CNAME rpz-drop.pass:[].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.
Has 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.

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

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

Try to resolve a host in the example.org domain that the RPZ is configured 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.

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

# dig @localhost www.example.net

...
;; connection timed out; no servers could be reached
...

Questo contenuto non è disponibile nella lingua selezionata.

2.1. The start of authority record in zone files
Copia collegamento

2.2. Setting up a forward zone on a BIND primary server
Copia collegamento

2.3. Setting up a reverse zone on a BIND primary server
Copia collegamento

2.4. Updating a BIND zone file
Copia collegamento

2.5. DNSSEC zone signing using the automated key generation and zone maintenance features
Copia collegamento

2.6. Configuring zone transfers among BIND DNS servers
Copia collegamento

2.7. Configuring response policy zones in BIND to override DNS records
Copia collegamento

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Rendiamo l’open source più inclusivo

Informazioni su Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 2. Configuring zones on a BIND DNS server

2.1. The start of authority record in zone filesCopia collegamentoCollegamento copiato negli appunti!

2.2. Setting up a forward zone on a BIND primary serverCopia collegamentoCollegamento copiato negli appunti!

2.3. Setting up a reverse zone on a BIND primary serverCopia collegamentoCollegamento copiato negli appunti!

2.4. Updating a BIND zone fileCopia collegamentoCollegamento copiato negli appunti!

2.5. DNSSEC zone signing using the automated key generation and zone maintenance featuresCopia collegamentoCollegamento copiato negli appunti!

2.6. Configuring zone transfers among BIND DNS serversCopia collegamentoCollegamento copiato negli appunti!

2.7. Configuring response policy zones in BIND to override DNS recordsCopia collegamentoCollegamento copiato negli appunti!

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Rendiamo l’open source più inclusivo

Informazioni su Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.1. The start of authority record in zone files
Copia collegamento

2.2. Setting up a forward zone on a BIND primary server
Copia collegamento

2.3. Setting up a reverse zone on a BIND primary server
Copia collegamento

2.4. Updating a BIND zone file
Copia collegamento

2.5. DNSSEC zone signing using the automated key generation and zone maintenance features
Copia collegamento

2.6. Configuring zone transfers among BIND DNS servers
Copia collegamento

2.7. Configuring response policy zones in BIND to override DNS records
Copia collegamento