Versions Compared

Old Version 13

changes.mady.by.user Steven Kim

Saved on

compared with

New Version 14

changes.mady.by.user Steven Kim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 [Link] hardening their core systemsecurity[/Link].

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 (public and private keys **reference**). 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.

Without DNSSEC, DNS data is somewhat static, and days, weeks or even months can go by without updates in a zone. Once DNSSEC is deployed, signatures need to be refreshed regularly because they expire. In addition, the cryptographic key material (public and private keys) used to sign and validate the data must be rotated (“key rollover”) on a regular schedule to reduce the risk of exposure of key material, and to practice the process of an emergency key replacement (which is similar to a normal key rollover).

The above processes require proper monitoring of the DNSSEC signing process, the resulting zone, the expiration of the DNSSEC signatures, and proper handling of key materials. To achieve this, it is strongly suggested that the DNS operator responsible for managing the DNSSEC process put together a DPS, or DNSSEC Practice Statement, as defined in RFC 6841.

ccTLD operators should see the ICANN DNSSEC guidebook for ccTLDs for more information.


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


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

  1. Practice 4: Authoritative and recursive DNS service MUST NOT be mixed on the same DNS infrastructure.

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

While this configuration does allow for a simpler setup (and faster lookup times) when looking up names within an organization’s own domain/zone, there are other problems with this configuration, including the risk for those DNS servers answering queries for “stale” domains that have since been delegated to other nameservers. This is a risk when the DNS servers are publicly reachable from the Internet.


  1. 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. Also, solutions using load balancer aren’t recommended: in case of a failure of the load balancing system, all DNS services placed behind it become unavailable simultaneously.

It may be tempting to increase reliability

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

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

...

using a load balancer in front of multiple servers, but this 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.

...


  1. Practice 6: There MUST be diversity in the authoritative DNS software packages. For a given zone

...

  1. , make sure all all published nameservers aren’t running the same authoritative DNS software package

...

  1. and version.

MUST: Authoritative servers must be geographically and topologically distributed. (RFC2182)


Rationale: In the event of a vulnerability affecting a DNS software package, there is a risk that all of one’s DNS servers could become unavailable at the same time if they all run that same software and revision.


...

  1. Practice 7
  1. : All authoritative servers for a given zone

...

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

...

    1. MUST NOT be placed on the same subnet (this is already a requirement in some TLDs)
    2. All the authoritative servers for a given zone

...

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

...

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

...


Rationale: This builds upon Best Practice 5. As explained, nameservers must not be on the same subnet, but must also not be in the same physical location (such as the same rack, room and if possible, building). 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. Preferably, the servers should be in different Autonomous Systems, if possible in different cities or regions.


  1. Practice 8: 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)

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

...

.