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:

name class type mname rname serial refresh retry expire minimum

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:

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

중요

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

참고

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.

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:
```
zone "example.com" {
    type master;
    file "example.com.zone";
    allow-query { any; };
    allow-transfer { none; };
};
```
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:
```
# 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.
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:

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

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.

참고

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:
```
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 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:
```
# 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.
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:

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

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:
```
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.
  중요
  If the serial number is equal to or lower than the previous 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.

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.

중요

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 bind package is installed.
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; and inline-signing yes; to the zone for which you want to enable DNSSEC:
```
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 accomplish 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 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:
```
#  dig @localhost example.com +dnssec
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
```

1.5. Configuring zones on a BIND DNS server

1.5.1. The SOA record in zone files
링크 복사

1.5.2. Setting up a forward zone on a BIND primary server
링크 복사

1.5.3. Setting up a reverse zone on a BIND primary server
링크 복사

1.5.4. Updating a BIND zone file
링크 복사

1.5.5. DNSSEC zone signing using the automated key generation and zone maintenance features
링크 복사

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.5. Configuring zones on a BIND DNS server

1.5.1. The SOA record in zone files링크 복사링크가 클립보드에 복사되었습니다!

1.5.2. Setting up a forward zone on a BIND primary server링크 복사링크가 클립보드에 복사되었습니다!

1.5.3. Setting up a reverse zone on a BIND primary server링크 복사링크가 클립보드에 복사되었습니다!

1.5.4. Updating a BIND zone file링크 복사링크가 클립보드에 복사되었습니다!

1.5.5. DNSSEC zone signing using the automated key generation and zone maintenance features링크 복사링크가 클립보드에 복사되었습니다!

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.5.1. The SOA record in zone files
링크 복사

1.5.2. Setting up a forward zone on a BIND primary server
링크 복사

1.5.3. Setting up a reverse zone on a BIND primary server
링크 복사

1.5.4. Updating a BIND zone file
링크 복사

1.5.5. DNSSEC zone signing using the automated key generation and zone maintenance features
링크 복사