Crypto Policies provide a centralized control over crypto algorithms usage of many packages. BIND is supported by crypto policy, but the BIND configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, ensure that the /etc/named.conf includes the appropriate configuration: In the options section of /etc/named.conf, make sure that the following line is not commented out or superseded by later includes: include "/etc/crypto-policies/back-ends/bind.config";
Overriding the system crypto policy makes the behavior of the BIND service violate expectations, and makes system configuration more fragmented.
If it is necessary for a secondary nameserver to receive zone data via zone transfer from the primary server, follow the instructions here. Use dnssec-keygen to create a symmetric key file in the current directory:
$ cd /tmp $ sudo dnssec-keygen -a HMAC-MD5 -b 128 -n HOST dns.example.com Kdns.example.com .+aaa +iiiiiThis output is the name of a file containing the new key. Read the file to find the base64-encoded key string:
$ sudo cat Kdns.example.com .+NNN +MMMMM .key dns.example.com IN KEY 512 3 157 base64-key-stringAdd the directives to /etc/named.conf on the primary server:
key zone-transfer-key {
algorithm hmac-md5;
secret "base64-key-string ";
};
zone "example.com " IN {
type master;
allow-transfer { key zone-transfer-key; };
...
};
Add the directives below to /etc/named.conf on the secondary nameserver:
key zone-transfer-key {
algorithm hmac-md5;
secret "base64-key-string ";
};
server IP-OF-MASTER {
keys { zone-transfer-key; };
};
zone "example.com " IN {
type slave;
masters { IP-OF-MASTER ; };
...
};
The BIND transaction signature (TSIG) functionality allows primary and secondary nameservers to use a shared secret to verify authorization to perform zone transfers. This method is more secure than using IP-based limiting to restrict nameserver access, since IP addresses can be easily spoofed. However, if you cannot configure TSIG between your servers because, for instance, the secondary nameserver is not under your control and its administrators are unwilling to configure TSIG, you can configure an allow-transfer directive with numerical IP addresses or ACLs as a last resort.
Is there a mission-critical reason to enable the risky dynamic update functionality? If not, edit /etc/named.conf. For each zone specification, correct the following directive if necessary:
zone "example.com " IN {
allow-update { none; };
...
};
Dynamic updates allow remote servers to add, delete, or modify any entries in your zone file. Therefore, they should be considered highly risky, and disabled unless there is a very good reason for their use. If dynamic updates must be allowed, IP-based ACLs are insufficient protection, since they are easily spoofed. Instead, use TSIG keys (see the previous section for an example), and consider using the update-policy directive to restrict changes to only the precise type of change needed.
Is it necessary for a secondary nameserver to receive zone data via zone transfer from the primary server? If not, follow the instructions in this section. If so, see the next section for instructions on protecting zone transfers. Add or correct the following directive within /etc/named.conf:
options {
allow-transfer { none; };
...
}
If both the primary and secondary nameserver are under your control, or if you have only one nameserver, it may be possible to use an external configuration management mechanism to distribute zone updates. In that case, it is not necessary to allow zone transfers within BIND itself, so they should be disabled to avoid the potential for abuse.
The named service is provided by the bind package.
The bind package can be removed with the following command:
$ sudo dnf remove bind
If there is no need to make DNS server software available, removing it provides a safeguard against its activation.
dnsmasq is a lightweight tool that provides DNS caching, DNS forwarding and
DHCP (Dynamic Host Configuration Protocol) services.
The dnsmasq package can be removed with the following command:
$ sudo dnf remove dnsmasq
Unless a system is specifically designated to act as a DNS caching, DNS forwarding and/or DHCP server, it is recommended that the package be removed to reduce the potential attack surface.
The named service can be disabled with the following command:
$ sudo systemctl mask --now named.service
All network services involve some risk of compromise due to implementation flaws and should be disabled if possible.