Page History
There are two types of best practices for operators of authoritative servers for critical zones:
DNS security, and DNS availability and resilience. In addition to these two categories specific to the core DNS, all operators must pay careful attention to practices related to hardening their core systemsecurity.
DNS Security: These best practices are aimed at improving the security of your DNS service itself, helping prevent users from being served malicious data, and lowering the chances of data corruption going unnoticed.
Practice 1: Authoritative zones MUST be DNSSEC signed and best practices for key management MUST be followed.
Rationale: Signing a zone using DNSSEC authenticates the origin of the data and protects the data’s integrity. DNSSEC is built on top of public key cryptography. Zone owners use a private key to create digital signatures of the DNS data, and publish it in the zone alongside the data. Also published in the zone is the public key used by DNSSEC-enabled resolvers to verify (or validate) the signatures. If the signature matches the data published, then the data hasn’t been corrupted or tampered with on its path from the authoritative servers for the zone, through one or more resolvers, to the final client. The keys used to sign the data are in turn signed by the operators of the parent zone, all the way to the root of the DNS. ccTLD operators should check the ICANN DNSSEC guidebook for ccTLDs for more information. |
Practice 2: Access to zone transfer between authoritative servers MUST be limited. Configure ACLs and TSIG in the DNS Authoritative software package to restrict zone transfers to secondary servers only.
Rationale: Third parties who are involved in providing secondary service for a zone have no reason to request the entire content of a zone. While DNS data is public, there are some security risks associated with unauthorized parties having access to an entire zone’s content. Also, large zones can cause significant amounts of traffic if zone transfers are repeated multiple times. |
Practice 3: Zone file integrity MUST be controlled to avoid unexpected modifications (malicious or accidental).
Rationale: In the event of data corruption or suspected security breach leading to unauthorized modification of DNS data, a mechanism should be implemented to detect such changes and when they occurred. |
DNS Availability and Resilience: These best practices aim to improve the robustness, resilience, and stability of your DNS infrastructure. Some of the recommendations can be implemented with minimal changes or additions to your infrastructure.
Practice 4: Authoritative and recursive DNS service MUST NOT coexist on the same DNS server. In the context of authoritative servers, this means you MUST disable recursive DNS resolution on servers configured to serve authoritative DNS data (if the software allows running both authoritative and recursive at the same time).
Rationale: DNS software packages such as ISC BIND can be configured to function as authoritative and recursive resolution on the same installation. Historically, this was to avoid the cost and overhead of two separate servers, particularly before virtualization was common. This is still the default behavior in most Windows DNS deployments as well. Clients in Active Directory enabled environments are typically configured to send recursive DNS lookups to DNS servers that by default serve a copy of the organization’s DNS zone. Queries for other domain names are resolved as usual (either directly, or by forwarding queries to an external server). |
Practice 5: At least two distinct nameservers MUST be used for any given zone. Note that this is usually a requirement when registering domain names in most TLDs (gTLD, ccTLD, …).
Rationale: If the equipment, network or location where your DNS servers are located suffers an outage (software, hardware, network, etc.), this shouldn’t affect the ability for the rest of the Internet to look up data in the affected domains, even if part or all of the servers and services referenced in the affected domains may be unreachable. Some software may behave in unpredictable ways or cause unnecessary timeouts as they attempt to look up information from unreachable DNS servers. It may be tempting to increase reliability using a load balancer in front of multiple servers, but that usually isn’t practical because it doesn’t easily allow for geographical diversity, introduces complexity, and risks overloading stateful systems in case of D/DoS type traffic patterns. Also, in case of a failure of the load balancing system, all DNS services placed behind it become unavailable simultaneously. |
Practice 6: There MUST be diversity in the authoritative operations to promote resilience. This MUST cover one or more of the practices below:
- Software Diversity: For a given zone, make sure all published nameservers aren’t running the same authoritative DNS software package and version.
- Network Diversity: For a given zone, make sure all authoritative servers are not placed within the same Autonomous System (AS) or within the same subnet.
- Geographical Diversity: For a given zone, make sure all the authoritative servers are in different physical locations (not the same rack and room or city, region, or country).
Rationale: In the event of a vulnerability affecting a DNS software package or an operational issue occurring (e.g., network outage, power outage), there is a risk that all of one’s DNS servers could become unavailable at the same time if the servers operational practices and location are not sufficiently diversified. This is especially true for critical zone operators such as TLDs where the DNS is the service, and everything must be done to maintain service in the case of an outage to avoid major downtime for a large part of the Internet in a country or region. |
Practice 7: Monitoring of the services, servers, and network equipment that make up your DNS infrastructure MUST be implemented.
Rationale: Monitoring of your DNS service is critical to ensure that it is available to users and customers. This can be achieved through local monitoring (hosted on premises) or a remote location, and either managed by yourself or a third party (outsourced/cloud based) |
1. Scope/Audience (What are critical zones?)
- Zones managed by Top Level Domains (TLDs) operators/registries, including: -
- Other delegation-centric zones of national importance for TLDs
- SLDs tied to critical services such as healthcare and e-governance/citizen and ID services(e.g: mitid.dk)
- Finance/banking sites
2. Availability and resiliency of the DNS service
- MUST: Do not mix authoritative and recursive name servers on the same DNS infrastructure.
- 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.
- 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.
MUST: Authoritative servers must be geographically and topologically distributed. (RFC2182)
MUST: All authoritative servers for a given zone must not be placed on the same network infrastructure. This includes the following:
All the authoritative servers for a given zone must not be placed on the same subnet
All the authoritative servers for a given zone must be in different physical locations (not the same rack and room).
SHOULD: All the authoritative servers for a given zone should not be placed within the same Autonomous System.
SHOULD: All the authoritative servers for a given zone should be in different geographical areas (preferably different cities or regions).
- MUST: Enable monitoring of your services, servers, and network equipment that make up your DNS infrastructure.
3. Architectural recommendations
- 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
...
5. Host and service security
- MUST: Lock down the host configuration (hardening).
- MUST: Uninstall/disable services and software packages that are not required for offering DNS service on the system.
- 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.).
- 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.
- MAY: Query logging for audit purposes/incident analysis (local laws and regulations permitting).
- 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.
- 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.
- MAY: Consider placing the DNS service and associated support services in a containerized environment.
- 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.
- MUST: Filter access to management services.
- MUST: Restrict access to management IP addresses and services (e.g: SSH, web based configuration tools).
- MUST: Close everything except DNS by default.
- 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
- 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 - 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.
- 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
...
. |