Managing networking infrastructure services

Red Hat Enterprise Linux 10

A guide to managing networking infrastructure services

Red Hat Customer Content Services

Abstract

This document describes how to set up and manage networking core infrastructure services, such as DNS and DHCP, on Red Hat Enterprise Linux.

Providing feedback on Red Hat documentation

We are committed to providing high-quality documentation and value your feedback. To help us improve, you can submit suggestions or report errors through the Red Hat Jira tracking system.

Procedure

Log in to the Content from redhat.atlassian.net is not included.Jira website.
If you do not have an account, select the option to create one.
Click Create in the top navigation bar.
Enter a descriptive title in the Summary field.
Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
Click Create at the bottom of the window.

Chapter 1. Configuring a BIND DNS server

To manage Domain Name System (DNS) services, configure the BIND DNS server to provide reliable name resolution for your network. You can use BIND as a caching server to improve lookup speeds for local networks or as a secondary server to ensure 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 (chroot) environment or the named-chroot service in a change-root environment.

Run the named service without a change-root environment. In this case, SELinux in the enforcing mode prevents exploitation of known BIND security vulnerabilities. By default, Red Hat Enterprise Linux (RHEL) uses SELinux in the enforcing mode.
Important
Running BIND on RHEL with SELinux in the enforcing mode is more secure than running BIND in a change-root environment.
Run the named-chroot service in a change-root environment.
By using the change-root feature, you can define that the root directory of a process and its sub-processes is different from 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 command 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 want to use BIND:

In the normal mode, use the named service.
In the change-root environment, use the named-chroot service. For this, install the named-chroot package.

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

Install the bind and bind-utils packages:
```
# dnf install bind bind-utils
```
Optional: If you want to run BIND in a change-root (chroot) environment, which isolates the application in a restricted directory structure for enhanced security, install the bind-chroot package:
```
# dnf install bind-chroot
```
The default option of running BIND on a host with SELinux in enforcing mode is more secure.
Edit the /etc/named.conf file, and update the options statement with the following settings:
```
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; };
```
These settings:
- Set which IPv4 and IPv6 interfaces BIND listens on (listen-on and listen-on-v6).
- Set which IP addresses and ranges can query this DNS server (allow-query).
- Set which IP addresses and ranges can send recursive queries to BIND (allow-recursion).
- Optional: forward queries to other DNS servers, such as those from your provider (forwarders). By default, BIND resolves queries by recursively asking root servers until it finds an authoritative DNS server (a server that holds the actual DNS records for a domain). Recursive queries are requests for resolving names that are not already in the cache.
  Warning
  Do not allow recursion on public IP addresses of the server. Otherwise, the server becomes the target of large-scale DNS amplification attacks.
  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:
```
# named-checkconf
```
No output means the syntax is valid.
Update the firewalld rules to allow incoming DNS traffic:
```
# firewall-cmd --permanent --add-service=dns
```
Reload the firewall configuration to apply the changes:
```
# firewall-cmd --reload
```
Start and enable BIND:
```
# systemctl enable --now named
```
If you want to run BIND in a change-root (chroot) 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:
```
# dig @<example_dns_server> www.example.org
```
```
...
__www.example.org.__    __86400__    IN    A    __198.51.100.34__

;; Query time: __917 msec__
...
```
This example assumes that BIND runs on the same host and responds to queries on the localhost interface.
After querying a record for the first time, BIND adds the entry to its cache.
Repeat the query from the last step:
```
# dig @<example_dns_server> www.example.org
```
```
__www.example.org.__    __85332__    IN    A    __198.51.100.34__

;; Query time: __1 msec__
...
```
Because of the cached entry, further requests for the same record are 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.3. Configuring logging on a BIND DNS server

To troubleshoot DNS issues and monitor server activity, configure logging on a BIND DNS server. You can set log locations, severity levels, and categories to track events such as zone transfers, security violations, and query patterns.

Prerequisites

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

Procedure

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;
     };

     ...
};
```
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.
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/
```
Verify the syntax of the /etc/named.conf file:
```
# named-checkconf
```
No output indicates that the syntax is correct.
Restart BIND:
```
# systemctl restart named
```
If you run BIND in a change-root (chroot) 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

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

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

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

Edit the /etc/named.conf file and make the following changes:
1. Add acl statements to the file. For example, to create an ACL named internal-networks for 127.0.0.1, 192.0.2.0/24, and 2001:db8:1::/64, enter:
```
acl internal-networks { 127.0.0.1; 192.0.2.0/24; 2001:db8:1::/64; };
acl dmz-networks { 198.51.100.0/24; 2001:db8:2::/64; };
```
2. Use the nickname for the ACL in statements that support them, for example:
```
allow-query { internal-networks; dmz-networks; };
allow-recursion { internal-networks; };
```
Verify the syntax of the /etc/named.conf file:
```
# named-checkconf
```
No output indicates that the syntax is correct.
Reload BIND:
```
# systemctl reload named
```
If you run BIND in a change-root (chroot) environment, use the systemctl reload named-chroot command to reload the service.

Verification

Run 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
```
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
```
```
...
;; WARNING: recursion requested but not available
...
```

1.5. Configuring zones on a BIND DNS server

To manage domain name resolution (DNS) for your organization’s domains, configure zones on a BIND DNS server. A zone contains the DNS records that map domain names, such as www.example.com, to IP addresses. As a result, clients can resolve hosts in your zone.

1.5.1. The start of authority record in zone files

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, split the record into several lines in zone files. Add comments that start with a semicolon (;). If you split a SOA record, use parentheses to keep it 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

A fully qualified domain name (FQDN) ends with a dot, which marks the end of the DNS name. If a name in the zone file does not have a trailing dot, BIND adds the zone name to it.

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 zone name, also called the origin. If you set it to @, BIND uses the zone name from /etc/named.conf.
class: Always set this to Internet (IN).
type: Always set this to SOA.
mname (master name): The hostname of the primary name server for the zone.
rname (responsible name): The email address of the person responsible for the zone. Replace the at sign (@) with a dot (.).
serial: The version number of the zone file. Secondary servers update only if this number is higher than theirs.
You can use any number. A common format is <year><month><day><two_digit_number>. With this format, you can change the zone file up to 99 times per day.
refresh: How long secondary servers wait before checking for updates.
retry: How long secondary servers wait before retrying if the last update failed.
expire: How long secondary servers try to update. After this time, they stop trying if every update failed.
minimum: How long resolvers cache negative answers (such as NXDOMAIN responses) for a zone, as defined in RFC 2308. This value is also known as the negative caching time to live (TTL).

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.

1.5.2. Configuring a forward zone on a BIND primary server

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
```
No output indicates that 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, a server that holds the actual DNS records for a domain, 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 (chroot) 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.

Additional resources

1.5.3. Configuring a reverse zone on a BIND primary server

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

When creating a reverse zone, name the zone according to the class-based network addressing scheme. For example:

For a class A network such as 10.0.0.0/8, use the zone name 10.in-addr.arpa.
For a class B network such as 172.16.0.0/16, use the zone name 16.172.in-addr.arpa.
For a class C network such as 192.0.2.0/24, use the zone name 2.0.192.in-addr.arpa.

For subnets that do not align with traditional classful boundaries, such as, 192.0.2.0/28, use the appropriate zone naming format, for example 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, a server that holds the actual DNS records for a domain, 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 (chroot) 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 @<example_dns_server> -x 192.0.2.1
```
```
ns1.example.com
```
```
# dig +short @<example_dns_server> -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.

Additional resources

1.5.4. Updating a BIND zone file

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 (chroot) 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.

Additional resources

The SOA record in zone files
Configuring a forward zone on a BIND primary server
Configuring a reverse zone on a BIND primary server

1.5.5. Signing a DNSSEC zone with automated features

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.

After enabling the DNSSEC policy feature for a zone, BIND automatically performs the actions:

Creating the keys
Signing the zone
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;
};
```
- The dnssec-policy default; statement enables BIND’s automated DNSSEC key management and zone signing for this zone.
- The inline-signing yes; statement makes BIND to automatically sign the zone’s records and maintain the signed zone file.
Reload BIND:
```
# systemctl reload named
```
If you run BIND in a change-root (chroot) 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
...
```

Additional resources

Configuring a forward zone on a BIND primary server
Configuring a reverse zone on a BIND primary server

1.6. Configuring zone transfers among BIND DNS servers

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.

Zone transfers let one authoritative DNS server retrieve an entire DNS zone from another authoritative DNS server. The receiving server stores the zone content and uses it to answer queries while continuing to refresh its copy to remain consistent with the source.

Prerequisites

You have the administrative privileges.
On the targeted primary server, the zone for which you want to set up zone transfers is already configured.
On the targeted 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; };
};
```
  Servers must have the key from the example-transfer-key statement to transfer a zone. You can also 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; };
};
```
  After you update a zone, by default, BIND notifies every name server that has an NS record in the zone. If you do not plan to add an NS record for the secondary server, configure BIND to notify it anyway. To do this, add the also-notify statement with the IP addresses of the secondary server to the zone:
4. Verify the syntax of the /etc/named.conf file:
```
# named-checkconf
```
  No output indicates that the syntax is correct.
5. Reload BIND:
```
# systemctl reload named
```
  If you run BIND in a change-root (chroot) 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=";
};
```
2. 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 zone file is /var/named/slaves/example.com.zone. This path is set by the directory option. You can keep all secondary zone files in /var/named/slaves/.
  - Any host can query this zone. To limit access, set IP ranges or ACL nicknames.
  - No host can transfer the zone from this server.
  - The primary servers are 192.0.2.1 and 2001:db8:1::2. You can use ACL nicknames. This server uses the example-transfer-key to authenticate to the primary server.
3. Verify the syntax of the /etc/named.conf file:
```
# named-checkconf
```
4. Reload BIND:
```
# systemctl reload named
```
  If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

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

Additional resources

Configuring a forward zone on a BIND primary server
Configuring 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

To rewrite a DNS response for blocking access to certain domains or hosts, configure response policy zones (RPZ) in BIND. You can use DNS blocking and filtering with RPZ. You can configure actions for blocked entries, such as returning an NXDOMAIN error.

If you have many 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
```
No output indicates that 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, a server that holds the actual DNS records for a domain, 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 (chroot) 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 @<example_dns_server> 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 @<example_dns_server> www.example.net
```
```
...
;; connection timed out; no servers could be reached
...
```

Additional resources

Content from datatracker.ietf.org is not included.IETF draft: DNS Response Policy Zones (RPZ)

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

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

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 ) ]; … };
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;};
```
To apply your changes, restart the named service:
```
# systemctl restart named.service
```
Configure a periodic rollout for active logs:
```
# sudoedit /etc/cron.daily/dnstap
```
```
#!/bin/sh
rndc dnstap -roll 3
mv /var/named/data/dnstap.bin.1 /var/log/named/dnstap/dnstap-$(date -I).bin

# use dnstap-read to analyze saved logs
sudo chmod a+x /etc/cron.daily/dnstap
```
- 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.
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
```

Chapter 2. Configuring an unbound DNS server

To securely validate, resolve, and cache Domain Name System (DNS) queries, configure the unbound DNS service. This service provides a lightweight caching DNS server with DNS Security Extensions (DNSSEC) validation enabled by default and stronger protection against DNS spoofing attacks.

2.1. Configuring Unbound as a caching DNS server

To resolve and cache successful and failed lookup, and answer requests to the same records from its cache, configure the unbound DNS service.

Prerequisites

You have administrative privileges.

Procedure

Install the unbound package:
```
# dnf install unbound
```
Edit the /etc/unbound/unbound.conf file, and make the following changes in the server clause:
1. Add interface parameters to configure on which IP addresses the unbound service listens for queries, for example:
```
interface: 127.0.0.1
interface: 192.0.2.1
interface: 2001:db8:1::1
```
  With these settings, unbound only listens on the specified IPv4 and IPv6 addresses.
  Limiting the interfaces to the required ones prevents clients from unauthorized networks, such as the internet, from sending queries to this DNS server.
2. Add access-control parameters to configure from which subnets clients can query the DNS service, for example:
```
access-control: 127.0.0.0/8 allow
access-control: 192.0.2.0/24 allow
access-control: 2001:db8:1::/64 allow
```
Create private keys and certificates for remotely managing the unbound service:
```
# systemctl restart unbound-keygen
```
Note
If you skip this step, verifying the configuration in the next step will report the missing files. However, the unbound service automatically creates the files if they are missing.

Verify the configuration file:

# unbound-checkconf

unbound-checkconf: no errors in /etc/unbound/unbound.conf

Update the firewalld rules to allow incoming DNS traffic:
```
# firewall-cmd --permanent --add-service=dns
# firewall-cmd --reload
```
Enable and start the unbound service:
```
# systemctl enable --now unbound
```

Verification

Query the unbound DNS server listening on the localhost interface to resolve a domain:
```
# dig @localhost www.example.com
```
```
...
__www.example.com.__    __86400__    IN    A    __198.51.100.34__

;; Query time: __330 msec__
...
```
After querying a record for the first time, unbound adds the entry to its cache.
Repeat the last query:
```
# dig @localhost www.example.com
```
```
...
__www.example.com.__    __85332__    IN    A    __198.51.100.34__

;; Query time: __1 msec__
...
```
Because of the cached entry, further requests for the same record are significantly faster until the entry expires.
For details, see unbound.conf(5) man page on your system.

Chapter 3. Providing DHCP services

To automatically assign IP addresses and other network settings to client devices, use the dynamic host configuration protocol (DHCP). You can configure Kea as a DHCP server to centrally manage network configurations for your clients.

3.1. The difference between static and dynamic IP addressing

To manage how devices receive their unique network addresses, you can select between two methods: static and dynamic IP addressing.

Static IP addressing

When you assign a static IP address to a device, the address does not change over time unless you change it manually. Use static IP addressing if you want to:

Ensure network address consistency for servers such as DNS, and authentication servers.
Use out-of-band management devices that work independently of other network infrastructure.

Dynamic IP addressing

When you configure a device to use a dynamic IP address, the address can change over time. For this reason, dynamic addresses are typically used for devices that connect to the network occasionally because the IP address can be different after rebooting the host.

Dynamic IP addresses are more flexible, easier to set up, and administer. DHCP is a traditional method of dynamically assigning network configurations to hosts.

Note

Choose static IP addressing for servers, network infrastructure, and devices requiring consistent access. Use dynamic IP addressing for workstations, laptops, mobile devices, and temporary clients.

3.2. DHCP transaction phases

DHCP works in four phases: Discovery, Offer, Request, Acknowledgment, also called the DORA process. DHCP uses this process to assign IP addresses to clients.

Discovery: The DHCP client sends a message to discover the DHCP server in the network. The client broadcasts this message at the network and data link layer.
Offer: The DHCP server receives the client’s message and offers an IP address to the client. The server unicasts this message at the data link layer and broadcasts it at the network layer.
Request: The DHCP client requests the offered IP address from the DHCP server. The client unicasts this message at the data link layer and broadcasts it at the network layer.
Acknowledgment: The DHCP server sends an acknowledgment to the client. The server unicasts this message at the data link layer and broadcasts it at the network layer. This acknowledgment is the final message in the DHCP DORA process.

3.3. Overview of using Kea for DHCPv4 and DHCPv6

To manage both DHCPv4 and DHCPv6 services independently, use Kea. Kea is an open source DHCP server with a modular design. Each protocol has its own configuration file, you can use it to run a DHCPv4 server, a DHCPv6 server, or both to meet network requirements.

For each protocol, Kea uses a separate configuration file and service:

DHCPv4

Configuration file: /etc/kea/kea-dhcp4.conf
Systemd service name: kea-dhcp4

DHCPv6

Configuration file: /etc/kea/kea-dhcp6.conf
Systemd service name: kea-dhcp6

3.4. Overview of the Kea lease database

A DHCP lease is the period for which Kea assigns a network address to a client. The lease databases store details about each lease. These details include the assigned IP address, the media access control (MAC) address, and the lease expiration time.

All timestamps in the lease databases are in Coordinated Universal Time (UTC).

Kea supports the following lease databases:

memfile (default)

A text-based file stored on the disk. By default, Kea stores the DHCP leases in the following files:

For DHCPv4: /var/lib/kea/kea-leases4.csv
For DHCPv6: /var/lib/kea/kea-leases6.csv
Warning
Do not edit the lease files by hand. Kea keeps lease data in memory for speed. It does not check the lease files while running. Kea overwrites any changes the next time it writes to the files. This can result in file corruption or wrong lease data.

mysql

A MySQL database.

pgsql

A PostgreSQL database.

Kea updates the lease database in the following cases:

On lease updates
On graceful shutdown
During periodic lease file cleanup (LFC) processes
On API requests

3.5. Configuring a Kea DHCP server

To centrally manage and automatically assign IP addresses and network settings across your infrastructure, set up the Kea DHCP server. Kea reduces manual configuration overhead and ensures consistent network settings for all client devices.

Prerequisites

You have installed the kea package.
You have administrative privileges.

Procedure

If you are configuring an IPv4 network:
1. Edit the /etc/kea/kea-dhcp4.conf file, and use the following configuration:
```
{
  "Dhcp4": {
    "description": "Global settings that apply to all subnets unless overridden",
    "valid-lifetime": 86400,
    "option-data": [
      {
        "name": "domain-name",
        "data": "example.com"
      },
      {
        "name": "domain-name-servers",
        "data": "192.0.2.53"
      }
    ],

    "interfaces-config": {
      "interfaces": [ "enp1s0" ]
    },

    "subnet4": [
      {
        "id": 1,
        "description": "A definition of a subnet that is directly connected to the server",
        "subnet": "192.0.2.0/24",
        "pools": [
          { "pool": "192.0.2.20  - 192.0.2.100" },
          { "pool": "192.0.2.150 - 192.0.2.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.0.2.1" }
        ]
      },

      {
        "id": 2,
        "description": "A definition of a remote subnet served through a DHCP relay",
        "subnet": "198.51.100.0/24",
        "pools": [
          { "pool": "198.51.100.20 - 198.51.100.100" }
        ],
        "relay": {
          "ip-addresses": [ "198.51.100.5" ]
        },
        "option-data": [
          { "name": "routers", "data": "198.51.100.1" },
          { "name": "domain-name-servers", "data": "198.51.100.53" }
        ]
      }
    ]
  }
}
```
  This example configures Kea to serve two subnets: one directly connected to the server and a remote one that uses a DHCP relay agent.
  interfaces
  Defines the network interfaces on which Kea listens for DHCP requests. If a subnet is not directly connected to the server, list the interfaces to make the subnet accessible through these interfaces.
  id
  Defines a unique integer for the subnet, if you define more than one subnet.
  subnet
  Defines the subnet in Classless Inter-Domain Routing (CIDR) format.
  pools
  Defines the IP address ranges so that Kea can assign addresses to clients.
  option-data
  Defines DHCP options sent to clients, such as the default gateway and DNS servers. Per-subnet option-data settings override global settings.
  relay
  Defines the IP addresses of DHCP relay agents. While this setting is optional for remote subnets, it improves the security to limit forwarded requests to trusted agents. Do not use this parameter for directly-connected subnets.
2. Verify the syntax of the configuration file:
```
# kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
```
  If the command returns Syntax check failed, fix the errors shown in the report.
3. Update the firewalld rules to allow incoming DHCPv4 traffic:
```
# firewall-cmd --permanent --add-service=dhcp
```
4. Reload the firewall configuration to apply the changes:
```
# firewall-cmd --reload
```
5. Enable and start the service:
```
# systemctl enable --now kea-dhcp4
```

If you are configuring an IPv6 network:

Edit the /etc/kea/kea-dhcp6.conf file, and use the following configuration:

{
  "Dhcp6": {
    "description": "Global settings that apply to all subnets unless overridden",
    "valid-lifetime": 86400,
    "option-data": [
      {
        "name": "domain-name",
        "data": "example.com"
      },
      {
        "name": "dns-servers",
        "data": "2001:db8:0:1::53"
      }
    ],

    "interfaces-config": {
      "interfaces": [ "enp1s0" ]
    },

    "subnet6": [
      {
        "id": 1,
        "description": "A definition of a subnet that is directly connected to the server",
        "subnet": "2001:db8:0:1::/64",
        "pools": [
          { "pool": "2001:db8:0:1::1000 - 2001:db8:0:1::2000" },
          { "pool": "2001:db8:0:1::4000 - 2001:db8:0:1::5000" }
        ]
      },

      {
        "id": 2,
        "description": "A definition of a remote subnet served through a DHCP relay",
        "subnet": "2001:db8:0:2::/64",
        "pools": [
          { "pool": "2001:db8:0:2::1000 - 2001:db8:0:2::2000" }
        ],
        "relay": {
          "ip-addresses": [ "2001:db8:0:2::5" ]
        },
        "option-data": [
          { "name": "dns-servers", "data": "2001:db8:0:1::53" }
        ]
      }
    ]
  }
}

This example configures Kea to serve two subnets: one directly connected to the server and a remote one that uses a DHCP relay agent.

Verify the syntax of the configuration file:
```
# kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
```
If the command returns Syntax check failed, fix the errors shown in the report.
Update the firewalld rules to allow incoming DHCPv6 traffic:
```
# firewall-cmd --permanent --add-service=dhcpv6
```
Reload the firewall configuration to apply the changes:
```
# firewall-cmd --reload
```
Enable and start the service:
```
# systemctl enable --now kea-dhcp6
```

Verification

Configure a network connection with DHCP on a client.
Connect the client to the network.

Check if the client received an IP address from the DHCP server:

# ip address show <interface>

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:17:b8:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.20/24 brd 192.0.2.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1::1000/64 scope global noprefixroute
       valid_lft forever preferred_lft forever

Troubleshooting

Check the IPv4 and IPv6 addresses Kea is listening on:
```
# ss -lunp | grep -E ':(67|547)'
```
If Kea does not listen on all interfaces you configured, check the interfaces-config setting in the Kea configuration files.

Next steps

Configure logging

3.6. Configuring `loggers` in Kea

To customize log settings depending on priority, such as the severity level, configure loggers in Kea. By default, Kea writes log messages to the systemd journal and the /var/log/messages files, if the rsyslogd service is running.

Prerequisites

You have installed the kea package on the server.
You have started the kea-dhcp4 and kea-dhcp6 services.
You have administrative privileges.

Procedure

To configure an IPv4 network, edit the /etc/kea/kea-dhcp4.conf file:
1. Add the loggers configuration to the Dhcp4 parameter:
```
{
  "Dhcp4": {
    ...,
    "loggers":[
      {
        "name":"kea-dhcp4",
        "output-options":[
           {
            "output":"kea-dhcp4.log",
            "maxsize":104857600,
            "maxver":5
           }
        ],
        "severity":"INFO",
      }
    ],
    ...
```
  The settings specified in the example are:
  name
  Defines the name of the binary the logger settings apply to.
  output
  Sets the log file name in the /var/lib/kea/ directory.
  maxsize
  Sets the maximum size of the log file before Kea rotates it. The default value is 10240000 bytes.
  maxver
  Sets the maximum number of rotated versions Kea will keep. Note that a maxsize value less than 204800 bytes disables rotation.
  severity
  Specifies the category of messages logged. You can set one of the following values: NONE, FATAL, ERROR, WARN, INFO, and DEBUG. Kea logs only messages of the configured severity and those with a higher level.
2. Verify the syntax of the configuration file:
```
# kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
```
  If the command returns Syntax check failed, fix the errors shown in the report.
3. Restart the kea-dhcp4 service:
```
# systemctl restart kea-dhcp4
```

To configure an IPv6 network, edit the /etc/kea/kea-dhcp6.conf file:

Add the loggers configuration to the Dhcp6 parameter:

{
  "Dhcp6": {
    ...,
    "loggers":[
      {
        "name":"kea-dhcp6",
        "output-options":[
           {
            "output":"kea-dhcp6.log",
            "maxsize":104857600,
            "maxver":5
           }
        ],
        "severity":"INFO",
      }
    ],
    ...

Verify the syntax of the configuration file:
```
# kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
```
If the command returns Syntax check failed, fix the errors shown in the report.
Restart the kea-dhcp6 service:
```
# systemctl restart kea-dhcp6
```

Verification

Monitor the log file to check if it displays messages of the expected severity.

3.7. Assigning a static address to a host by using DHCP

To assign a fixed IP address to a media access control (MAC) address, a DHCP unique identifier (DUID), or other identifiers, use a reservation inside a subnet definition in Kea. For example, use this method to always assign the same IP address to a server or network device.

Prerequisites

You have configured the kea-dhcp4 and kea-dhcp6 services.
You have administrative privileges.

Procedure

If you are configuring an IPv4 network:
1. Edit the /etc/kea/kea-dhcp4.conf file, and add a reservation to the subnet4 parameter:
```
{
  "Dhcp4": {
    "subnet4": [
      {
        "subnet": "192.0.2.0/24",
	...,
        "reservations": [
          {
            "hw-address": "52:54:00:72:2f:6e",
            "ip-address": "192.0.2.130"
          }
        ],
	...
```
  This example configures Kea to always assign the 192.0.2.130 IP address to the host with the 52:54:00:72:2f:6e MAC address.
  For further examples, see the /usr/share/doc/kea/examples/kea4/reservations.json file provided by the kea-doc package.
2. Verify the syntax of the configuration file:
```
# kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
```
  If the command returns Syntax check failed, fix the errors shown in the report.
3. Restart the kea-dhcp4 service:
```
# systemctl restart kea-dhcp4
```
If you are configuring an IPv6 network:
1. Edit the /etc/kea/kea-dhcp6.conf file, and add a reservation to the subnet6 parameter:
```
{
  "Dhcp6": {
    "subnet6": [
      {
        "subnet": "2001:db8:0:1::/64",
  ...,
        "reservations": [
          {
            "hw-address": "52:54:00:72:2f:6e",
            "ip-address": "2001:db8:0:1::99"
          }
        ];
  ...
```
  This example configures Kea to always assign the 2001:db8:0:1::99 IP address to the host with the 52:54:00:72:2f:6e MAC address.
  For further examples, see the /usr/share/doc/kea/examples/kea6/reservations.json file provided by the kea-doc package.
2. Verify the syntax of the configuration file:
```
# kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
```
  If the command returns Syntax check failed, fix the errors shown in the report.
3. Restart the kea-dhcp6 service:
```
# systemctl restart kea-dhcp6
```

Verification

Connect the client for which you configured the fixed IP address to the network.
On the client, check whether it received the reserved IP address:
```
# ip address show <interface>
```
Replace <interface> with the name of the network interface, for example enp1s0.
The output should show the reserved IP address 192.0.2.130 for IPv4 or 2001:db8:0:1::99 for IPv6.

3.8. Classifying clients in Kea

To group clients based on specific criteria and allow for granular control over network configuration, use Kea client classes. You can apply special processing rules or assign different DHCP options to clients.

You can create a client class that assigns Voice over IP (VoIP) devices to a specific IP pool. This is to ensure that VoIP phones get different IP addresses than other devices on the network. For example, in IPv4 networks, you can use a substring expression to test for the first 3 octets of their media access control (MAC) address. In IPv6 networks where the MAC address is not a reliable indicator, you can test for a sub-string of the DHCPv6 vendor class option.

Prerequisites

You have configured the kea-dhcp4 and kea-dhcp6 services and are active.
You have administrative privileges.

Procedure

To configure an IPv4 network, edit the /etc/kea/kea-dhcp4.conf file

Add client classes to the Dhcp4 parameter:

{
  "Dhcp4": {
    ...
    "client-classes": [
      {
          "name": "VoIP-Phones",
          "test": "substring(pkt4.mac, 0, 3) == 0x525400"
      },
      {
          "name": "Others",
          "test": "not member('VoIP-Phones')"
      }
    ],
    ...

In this example, devices with a MAC address starting with 52:54:00 match the VoIP-Phones client class. The Others client class includes devices that do not match the rule.

Assign the client classes to your pool definitions:

{
  "Dhcp4": {
    "subnet4": [
      {
        "subnet": "192.0.2.0/24",
	"pools": [
          {
            "pool": "192.0.2.20  - 192.0.2.100",
            "client-class": "Others"
          },
          {
            "pool": "192.0.2.150 - 192.0.2.200",
            "client-class": "VoIP-Phones"
          }
        ],
        ...

Depending on which client class a host matches, Kea assigns an IP address from the corresponding pool.

Verify the syntax of the configuration file:
```
# kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
```
If the command returns Syntax check failed, fix the errors shown in the report.
Restart the kea-dhcp4 service:
```
# systemctl restart kea-dhcp4
```

To configure an IPv6 network, edit the /etc/kea/kea-dhcp6.conf file:

Add client classes to the Dhcp6 parameter:

{
  "Dhcp6": {
    ...
    "client-classes": [
      {
          "name": "VoIP-Phones",
          "test": "option[16].exists and (substring(option[16].hex, 0, 8) == '00000009')",
      },
      {
          "name": "Others",
          "test": "not member('VoIP-Phones')"
      }
    ],
    ...

In this example, devices that send a DHCPv6 vendor class option (option 16) where the hexadecimal value begins with 00000009 match the VoIP-Phones client class. The Others client class includes devices that do not match the rule.

Assign the client classes to your pool definitions:

{
  "Dhcp6": {
    "subnet6": [
      {
        "subnet": "2001:db8:0:1::/64",
	"pools": [
          {
            "pool": "2001:db8:0:1::1000 - 2001:db8:0:1::2000",
            "client-class": "Others"
          },
          {
            "pool": "2001:db8:0:1::4000 - 2001:db8:0:1::5000",
            "client-class": "VoIP-Phones"
          }
        ],
        ...

Depending on which client class a host matches, Kea assigns an IP from the corresponding pool.

Verify the syntax of the configuration file:
```
# kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
```
If the command returns Syntax check failed, fix the errors shown in the report.
Restart the kea-dhcp6 service:
```
# systemctl restart kea-dhcp6
```

Verification

Connect clients that match the rules in the client classes and verify that Kea assigned an IP address from the associated pool.

3.9. Comparison of DHCPv6 to `radvd`

To use DHCPv6 in subnets that require a default gateway setting, configure an additional router advertisement service, such as Router Advertisement Daemon (radvd).

In an IPv6 network, only router advertisement messages have information about the IPv6 default gateway. The radvd service uses flags in router advertisement packets to announce the availability of a DHCPv6 server.

The following table compares features of DHCPv6 and radvd:

Table 3.1. Comparison of DHCPv6 and radvd features

Functionality	DHCPv6	`radvd`
Provides information about the default gateway	no	yes
Guarantees random addresses to protect privacy	yes	no
Sends further network configuration options	yes	no
Maps media access control (MAC) addresses to IPv6 addresses	yes	no

3.10. Configuring the `radvd` service for IPv6 routers

To manage router advertisement messages, configure the router advertisement daemon (radvd) service. This service sends router advertisement messages for IPv6 stateless auto-configuration. You can configure addresses, settings, routes, and select a default router based on these advertisements.

Note

You can only set /64 prefixes in the radvd service. To use other prefixes, use DHCPv6.

Prerequisites

You have the administrative privileges.

Procedure

Install the radvd package:
```
# dnf install radvd
```
Edit the /etc/radvd.conf file to configure radvd with the following parameters:
```
interface enp1s0
{
  AdvSendAdvert on;
  AdvManagedFlag on;
  AdvOtherConfigFlag on;

  prefix 2001:db8:0:1::/64 {
  };
};
```
- Send router advertisement messages on the enp1s0 interface for the 2001:db8:0:1::/64 subnet.
- The AdvManagedFlag on flag defines that the client should receive the IP address from a DHCP server.
- The AdvOtherConfigFlag flag defines that clients should receive non-address information from the DHCP server as well.
Enable radvd to start automatically when the system boots:
```
# systemctl enable --now radvd
```
For details, see radvd.conf(5) man page and /usr/share/doc/radvd/radvd.conf.example file on your system.

Verification

Display the content of router advertisement packages and the configured values radvd sends:
```
# radvdump
```

Additional resources

Can I use a prefix length other than 64 bits in IPv6 Router Advertisements? (Red Hat Knowledgebase)

Legal Notice

Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.

The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.

All other trademarks are the property of their respective owners.

Managing networking infrastructure services

A guide to managing networking infrastructure services

Providing feedback on Red Hat documentation

Chapter 1. Configuring a BIND DNS server

1.1. Considerations about protecting BIND with SELinux or running it in a change-root environment

1.2. Configuring BIND as a caching DNS server

1.3. Configuring logging on a BIND DNS server

1.4. Creating BIND access control lists

1.5. Configuring zones on a BIND DNS server

1.5.1. The start of authority record in zone files

1.5.2. Configuring a forward zone on a BIND primary server

1.5.3. Configuring a reverse zone on a BIND primary server

1.5.4. Updating a BIND zone file

1.5.5. Signing a DNSSEC zone with automated features

1.6. Configuring zone transfers among BIND DNS servers

1.7. Configuring response policy zones in BIND to override DNS records

1.8. Recording DNS queries by using dnstap

Chapter 2. Configuring an unbound DNS server

2.1. Configuring Unbound as a caching DNS server

Chapter 3. Providing DHCP services

3.1. The difference between static and dynamic IP addressing

3.2. DHCP transaction phases

3.3. Overview of using Kea for DHCPv4 and DHCPv6

3.4. Overview of the Kea lease database

3.5. Configuring a Kea DHCP server

3.6. Configuring loggers in Kea

3.7. Assigning a static address to a host by using DHCP

3.8. Classifying clients in Kea

3.9. Comparison of DHCPv6 to radvd

3.10. Configuring the radvd service for IPv6 routers

Legal Notice

1.8. Recording DNS queries by using `dnstap`

3.6. Configuring `loggers` in Kea

3.9. Comparison of DHCPv6 to `radvd`

3.10. Configuring the `radvd` service for IPv6 routers