In addition to implementing best practices for DNS security and for DNS availability and resilience, all operators must pay careful attention to practices for hardening the platforms their DNS services use. There are three types of hardening practices: network security, host and service security, and customer-facing portal and service security.

Practice 1

ACLs MUST be implemented to restrict network traffic to your DNS servers.

  1. For authoritative operators, the ACLs MUST allow only DNS traffic and associated ICMP response codes to your authoritative DNS servers; access to all other services and ports on your network for DNS servers MUST be denied.
  2. For all DNS operator types (authoritative and recursive), incoming traffic from all so-called Bogon IP subnets MUST be blocked, including private RFC 1918 addresses, and possibly RFC 6598 (Shared IPv4 address space) for v4. Recursive DNS operators should of course NOT block private/shared IP address space deployed within the organization. See https://ipgeolocation.io/resources/bogon.html

ACLs must be configured to allow only necessary network traffic from legitimate IP address space (and any internal IP address ranges) to reach your DNS servers. This reduces the risk of denial of service conditions (including amplification attacks) and zone transfer hijacking.

Practice 2

BCP38/MANRS egress filtering MUST be implemented so that no network traffic can leave your network with a source IP address that is not assigned to you or your customers.

This is a well-established best practice for all organizations and networks, not just for DNS environments. It prevents your internal network traffic or your customers’ internal network traffic from leaking onto other networks and being exposed.

Practice 3

The configuration of each DNS server MUST be locked down. This includes the following:

  1. All services and software packages that are not required for offering DNS service on the system MUST be uninstalled or disabled.
  2. Hosts running DNS services MUST only run DNS software. In other words, DNS servers MUST NOT run other services, such as web or email servers.
  3. All relevant logging channels and levels for the DNS subsystem MUST be enabled. Logs MUST be sent to a central location for archiving, inspection, and auditing, and they MUST be retained for a reasonable time in accordance with retention policies.

Minimizing the software and services on each DNS server reduces the likelihood and frequency of exploitable vulnerabilities. Logging is critical for identifying and analyzing attacks. Configuring DNS services to only respond to queries from known subnets avoids leaks of internal DNS information if the servers are inadvertently accessible due to ACL misconfiguration.

Practice 4

User permissions and application access to system resources MUST be limited. File permissions and ownership restrictions MUST be set so that users and services not directly associated with management of the DNS subsystem do not have read or write access to DNS service configuration, data files, and database subsystems.

This minimizes what any non-DNS users of a DNS server can do on the server. Even if an attacker compromises one of these user accounts, the privileges the attacker has with regards to DNS will be minimal or nonexistent.

Practice 5

System and service configuration files MUST be versioned. For authoritative operators, zone files/data MUST also be versioned.

File versioning enables detection of file corruption and unauthorized changes. It also makes it possible to roll back changes.

Practice 6

Access to management services (e.g., SSH, web-based configuration tools) MUST be restricted. All services not needed for DNS or management MUST be disabled or uninstalled if possible, otherwise network access to the unnecessary services MUST be blocked.

At the software level, the DNS service should be configured to only accept queries from authorized clients (known subnets/networks). At the host level, any services that are not actively being used should be stopped and disabled from starting, or even uninstalled. Services that are necessary for production purposes should see their access restricted to the IP address ranges of the management networks/clients. This includes telemetry/monitoring services (SNMP and similar).

Likewise, access to management services such as SSH or HTTPS (for web-based configuration) should be restricted to only allow traffic from known management networks/clients.

Practice 7

Access to the system console MUST be secured using cryptographic keys, protected with a passphrase (e.g. SSH keys) or using suitable two-factor authentication (OTP generator or token-based).

Requiring strong authentication measures can prevent an attacker from gaining unauthorized access to administrator accounts, which could be catastrophic.

Practice 8

Credentials for customer access (registrants and other domain contacts) MUST follow sound credential management practices, including offering two-factor authentication as an option.

Sound credential management practices including having credential management policies, such as password policies, and enforcing those policies through technology, processes, and customer awareness. Two-factor authentication is particularly important so that customers who are concerned about unauthorized access to their accounts can choose to use it, thus reducing the likelihood of their accounts being compromised. Customers should be strongly encouraged to enable two-factor authentication on their accounts.