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

Compare with Current View Page History

« Previous Version 12 Next »

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

  1. Zones managed by Top-level Domain (TLD) operators/registries, including TLD zones themselves (e.g., .com, .info, .be) and their subdomains (e.g., co.uk, co.za), and 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: Authoritative servers must be geographically and topologically distributed. (RFC2182)

    1. MUST: All authoritative servers for a given zone must not be placed on the same network infrastructure. This includes the following:

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

      3. SHOULD: All the authoritative servers for a given zone should not be placed within the same Autonomous System.

      4. 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 and privacy

  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.
  3. MUST: Zone File Integrity
    Some method of controlling the zone file’s integrity for any unexpected modifications (malicious or accidental) must be implemented. For static zones, this could for example be done using the ZONEMD (RFC8976) message digest and Resource Record, or existing revision control / versioning procedures, if those are implemented (see Host and Service security). If the zone is dynamic, and producing a message digest for the entire zone is impractical due to size or rate of change, revision control and versioning must enable auditing to narrow down when a given error or malicious change was introduced.

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