You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

1. Scope/Audience (What are critical zones?)

  1. Zones managed by Top Level Domains (TLDs) operators/registries, including: -
    1. TLD zones themselves and subdomains thereof (e.g.: gov.uk)
    2. any auxiliary zones necessary to the operation of a ccTLD (e.g.: nic.uk, nic.fr, nic.dk)
  2. Other delegation-centric zones of national importance for TLDs
  3. SLDs tied to critical services such as healthcare and e-governance/citizen and ID services(e.g: mitid.dk)
  4. Finance/banking sites

2. Availability and resiliency of the DNS service

  1. MUST: Do not mix authoritative and recursive name servers on the same DNS infrastructure.
  2. MUST: Use at least two distinct nameservers for any given zone. Solutions using a load balancer in front of multiple servers usually aren’t practical because they don’t easily allow for geographical diversity, introduce complexity, and risk overloading stateful systems in case of D/DoS type traffic patterns.
  3. MUST: Have software diversity. For a given zone with two or more published authoritative nameservers, all nameservers must not be running the same authoritative DNS software package. Use software from two or more vendors.
  4. MUST: Geographical / Topologically distributed auth. Servers (RFC2182)
    1. MUST: All authoritative servers for a given zone must not be placed on the same network infrastructure:
      1. All the authoritative servers for a given zone must not be placed on the same subnet
      2. All the authoritative servers for a given zone must be in different physical locations (not the same rack and room).
    2. SHOULD: All the authoritative servers for a given zone must not be placed within the same Autonomous System
    3. SHOULD: All the authoritative servers for a given zone should be in different geographical areas (preferably different cities or regions)
  5. MUST: Enable monitoring of your services, servers, and network equipment that make up your DNS infrastructure.

3. Architectural recommendations

  1. SHOULD: Your publicly accessible authoritative servers should not be serving “primary” data. If possible, the source of authority should be somewhere else, and your public authoritative servers are serving a copy of the zone data. This is sometimes called a Hidden SOA architecture.

4. Network security

  1. MUST: Implement BCP38/MANRS - egress filtering, so that no network traffic can leave your network with a source IP address that is not assigned to you or your customers.
  2. MUST: Implement ACLs to only allow DNS traffic and associated ICMP response codes to your DNS servers. Disable access to other services and ports on your network for those systems running DNS.
  3. SHOULD: Avoid enabling stateful packet filtering / reflexive access-lists in front of a DNS server. Very active DNS servers can easily overwhelm stateful packet filters and load balancers.

5. Host and service security

  1. MUST: Lock down the host configuration (hardening).
    1. MUST: Uninstall/disable services and software packages that are not required for offering DNS service on the system.
    2. MUST: Only run DNS software on the systems that will be offering DNS service (i.e.: do not co-locate with web server / mail server, etc.).
    3. MUST: Enable all relevant logging channels and levels for the DNS subsystem, including suitable retention policies. Send logs to a central location for archiving, inspection and auditing.
    4. MAY: Query logging for audit purposes/incident analysis (local laws and regulations permitting).
  2. MUST: Limit user permissions and application access to system resources. File permissions and ownership restrictions must be set so that users and services not directly associated with management of the DNS subsystem have no read or write access to DNS service configuration, data files and database subsystems.
    1. MAY: Consider using AppArmor or another capabilities-based security mechanism to restrict which files and resources the DNS subsystem is allowed to access on the host OS.
    2. MAY: Consider placing the DNS service and associated support services in a containerized environment.
  3. MUST: System and service configuration files and zone files/data alike must be versioned, enabling detection of corruption/unauthorized changes, and making it possible to roll back changes.
  4. MUST: Filter access to management services.
    1. MUST: Restrict access to management IP addresses and services (e.g: SSH, web based configuration tools).
    2. MUST: Close everything except DNS by default.
  5. MUST: 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).

6. DNS security

  1. MUST: Authoritative zones must be DNSSEC signed and best practices for key management followed. ccTLD operators: see the ICANN DNSSEC guidebook for ccTLDs:
    https://www.icann.org/en/system/files/files/octo-029-12nov21-en.pdf
  2. MUST: Limit access to zone transfer between authoritative servers. Configure ACLs and TSIG in the DNS Authoritative software package to restrict zone transfers to secondary servers.

7. Customer-facing portals and services

  1. MUST: Credentials for customer access (registrants and other domain contacts) must offer two-factor authentication as an option.
  2. SHOULD: Customers/registrants should be strongly encouraged to enable two-factor authentication on their accounts.
  • No labels