APP.3.6 DNS Server

Description

Introduction

The Domain Name System (DNS) is a network service used to translate hostnames of IT systems into IP addresses. DNS can be compared to a telephone directory that resolves names not into phone numbers but into IP addresses. Typically, DNS is used to look up the corresponding IP address for a hostname (forward resolution). Conversely, if the IP address is known and the hostname is being sought, this is called reverse resolution.

Which hostnames map to which IP addresses is managed in the domain namespace. This namespace is hierarchically structured and is provided by DNS servers. The term “DNS server” technically refers to the software used, but is also commonly used as a synonym for the IT system on which this software operates.

DNS servers manage the domain namespace on the internet, but are also frequently deployed in an institution’s internal network. By default, so-called resolvers are installed on users’ IT systems. Queries to DNS servers are made through the resolver. In response, DNS servers return information about the domain namespace.

DNS servers can be distinguished by their roles. There are essentially two different types: advertising DNS servers and resolving DNS servers. Advertising DNS servers are typically responsible for processing queries from the internet. Resolving DNS servers, on the other hand, process queries from an institution’s internal network.

The failure of a DNS server can have a severe impact on IT infrastructure operations. It is not the failed DNS system itself that is problematic, but rather the DNS-based services that become restricted as a result. Web servers or email servers may become unreachable, or remote maintenance may stop working. Since DNS is required by many network applications, the specification (RFC 1034) mandates that at least two authoritative DNS servers (advertising DNS servers) be operated for each zone.

Objective

This building block describes the threats specific to a DNS server and the resulting requirements for secure deployment.

Scope and Modeling

The building block APP.3.6 DNS Server must be applied to every DNS server deployed in the information domain.

This building block contains fundamental requirements that must be observed and fulfilled when an institution deploys DNS servers. The focus is on the availability of DNS servers and the integrity of transmitted information. Problems that may arise when DNS servers are used are also addressed.

General and operating-system-specific aspects of a server are not the subject of this building block. These are covered in the building block SYS.1.1 General Server and in the corresponding operating-system-specific building blocks of the SYS IT Systems layer, e.g. SYS.1.3 Server under Linux and Unix or SYS.1.2.3 Windows Server.*

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block APP.3.6 DNS Server.

DNS Server Failure

If a DNS server fails, the entire IT Operations can be affected. Since clients and other servers of the institution are then unable to resolve internal and external addresses based on hostnames, no data connections can be established. External IT systems, such as those of mobile employees, customers, and business partners, can no longer access the institution’s servers. This typically disrupts essential business processes.

Insufficient Bandwidth Capacity

If the bandwidth capacity for a DNS server is insufficient, access times to internal and external services can increase. As a result, these services may only be available in a limited capacity or not at all. The DNS server may also become more susceptible to overload through a Denial-of-Service (DoS) attack.

Missing or Inadequate Planning of DNS Deployment

Errors in planning often prove particularly severe, as they can easily create widespread security vulnerabilities. If DNS deployment is not planned or is inadequately planned, this can lead to problems and security vulnerabilities during ongoing operations. For example, if the firewall rules governing DNS traffic are defined too permissively, this may result in an attack. However, if the rules are formulated too restrictively, legitimate clients cannot submit queries to the DNS servers and are impaired when using services such as email or FTP.

Incorrect Domain Information

Even if DNS deployment is carefully planned so that all security-relevant aspects are considered, this is not sufficient if domain information is created with semantic or syntactic errors. This applies, for example, when a hostname is assigned an incorrect IP address, data is missing, unauthorized characters are used, or forward and reverse resolution are inconsistent. If domain information contains errors, services that use that information will only function in a limited capacity due to the incorrect data.

Misconfiguration of a DNS Server

Security-critical default settings, self-configured security-critical settings, or erroneous configurations can cause a DNS server to malfunction. For example, if a resolving DNS server is configured to accept recursive queries without restriction—from both the internal data network and the internet—the increased load may severely impair the server’s availability. Additionally, this could make it vulnerable to DNS reflection attacks.

Similarly, with misconfigured DNS servers, there is a risk that zone transfers are not restricted to authorized DNS servers. This means that any host capable of sending queries to the DNS servers can read out the complete domain information from those servers. The data obtained in this way can facilitate future attacks.

DNS Manipulation

A DNS cache poisoning attack aims to cause the targeted IT system to store false mappings of IP addresses and names. This exploits the fact that DNS servers cache received domain information for a certain period of time, allowing forged data to spread widely. When queries are then submitted to the manipulated DNS server, it returns the forged data as a response. The IT system that receives this response caches it, and its cache is thus also “poisoned.” The stored data has a defined time to live (TTL). When the resolving DNS server is queried for a manipulated address, it will not query another DNS server again until the TTL has expired. This allows manipulated DNS information to persist for a long time, even after it has already been corrected on the originally attacked DNS server. If attackers succeed, for example, in taking over the name resolution for a domain by manipulating entries so that their DNS servers are queried, all subdomains are automatically affected as well. DNS cache poisoning attacks are often carried out with the aim of redirecting queries to malicious servers.

DNS Hijacking

DNS hijacking is an attack method used to route communication between advertising DNS servers and resolvers through the attackers’ IT system. This man-in-the-middle attack allows attackers to intercept and record communication between the servers. The far greater danger, however, is that a successful attack enables arbitrary modification of all data traffic between the two IT systems. After a successful DNS hijacking attack, when a client’s resolver sends a query to a DNS server, attackers can, for example, alter the mapping of names to IP addresses. DNS hijacking can also be combined with other attacks, such as phishing.

DNS DoS

In a DoS attack against a DNS server, so many queries are sent to it that the network connection to the DNS server or the DNS server itself becomes overloaded. The queries are typically sent via botnets to achieve the necessary data rate. A DNS server overloaded in this way can no longer respond to legitimate queries.

DNS Reflection

A DNS reflection attack is a DoS attack where the target is not the DNS server to which the queries are sent, but rather the IT system that receives the responses. This exploits the fact that certain queries generate a disproportionately large volume of response data. An amplification factor of 100 or more is possible, meaning the response, measured in bytes, is at least one hundred times larger than the query. The number and size of responses overloads the network bandwidth or the receiving IT system beyond its capacity. Thus, any technical IT component can be the attack target. DNS reflection attacks are facilitated by open resolvers.

Requirements

The following are the specific requirements of the building block APP.3.6 DNS Server. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

Further roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is reasonable and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled with priority for this building block.

APP.3.6.A1 Planning of DNS Deployment (B)

The deployment of DNS servers MUST be carefully planned. First, it MUST be determined how the DNS network service is to be structured. It MUST be defined which domain information requires protection. It MUST be planned how DNS servers are to be integrated into the information domain’s network. The decisions made MUST be documented appropriately.

APP.3.6.A2 Use of Redundant DNS Servers (B)

Advertising DNS servers MUST be designed redundantly. For each advertising DNS server, there MUST be at least one additional secondary DNS server.

APP.3.6.A3 Use of Separate DNS Servers for Internal and External Queries (B)

Advertising DNS servers and resolving DNS servers MUST be separated on the server side. The resolvers of internal IT systems MUST ONLY use internal resolving DNS servers.

APP.3.6.A4 Secure Basic Configuration of a DNS Server (B)

A resolving DNS server MUST be configured so that it only accepts queries from the internal network. When a resolving DNS server sends queries, it MUST use random source ports. If DNS servers are known to provide incorrect domain information, the resolving DNS server MUST be prevented from sending queries to them. An advertising DNS server MUST be configured to always process queries from the internet iteratively.

It MUST be ensured that DNS zone transfers between primary and secondary DNS servers function correctly. Zone transfers MUST be configured so that they are only possible between primary and secondary DNS servers. Zone transfers MUST be restricted to specific IP addresses. The version of the DNS server product in use MUST be hidden.

APP.3.6.A5 DISCONTINUED (B)

This requirement has been discontinued.

APP.3.6.A6 Securing Dynamic DNS Updates (B)

It MUST be ensured that only authorized IT systems are permitted to modify domain information. It MUST be defined which domain information the IT systems are allowed to modify.

APP.3.6.A7 Monitoring DNS Servers (B)

DNS servers MUST be continuously monitored. The load on DNS servers MUST be monitored so that hardware capacity can be adjusted in a timely manner. DNS servers MUST be configured to log at minimum the following security-relevant events:

• Number of DNS queries,
• Number of errors in DNS queries,
• EDNS errors (EDNS - Extension Mechanisms for DNS),
• expiring zones, and
• failed zone transfers.

APP.3.6.A8 Management of Domain Names (B) [Central Administration]

It MUST be ensured that registrations for all domains used by an institution are renewed regularly and in a timely manner. A person MUST be designated to be responsible for managing internet domain names. If service providers are commissioned to manage domains, it MUST be ensured that the institution retains control over the domains.

APP.3.6.A9 Creating an Emergency Plan for DNS Servers (B)

An emergency plan for DNS servers MUST be created. The emergency plan for DNS servers MUST be integrated into the institution’s existing emergency plans. The emergency plan for DNS servers MUST describe a data backup concept for zone and configuration files. The data backup concept for zone and configuration files MUST be integrated into the institution’s existing data backup concept. The emergency plan for DNS servers MUST include a recovery plan for all DNS servers in the information domain.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.

APP.3.6.A10 Selection of a Suitable DNS Server Product (S)

When procuring a DNS server product, it SHOULD be ensured that it has proven sufficiently reliable in practice. The DNS server product SHOULD support current RFC standards. The DNS server product SHOULD assist those responsible in creating syntactically correct master files.

APP.3.6.A11 Adequate Sizing of DNS Servers (S)

The hardware of the DNS server SHOULD be adequately sized. The hardware of the DNS server SHOULD be used exclusively for operating this DNS server. The network connections of all DNS servers in the information domain SHOULD be adequately dimensioned.

APP.3.6.A12 DISCONTINUED (S)

This requirement has been discontinued.

APP.3.6.A13 Restriction of the Visibility of Domain Information (S)

The namespace of an information domain SHOULD be divided into a public and an institution-internal area. The public section SHOULD only contain domain information required by services that are intended to be accessible from outside. IT systems in the internal network SHOULD not receive an externally resolvable DNS name, even if they have a public IP address.

APP.3.6.A14 Placement of Nameservers (S)

Primary and secondary advertising DNS servers SHOULD be placed in different network segments.

APP.3.6.A15 Evaluation of Log Data (S)

The log files of the DNS server SHOULD be regularly reviewed. The log files of the DNS server SHOULD be regularly evaluated. At minimum the following security-relevant events SHOULD be evaluated:

• Number of DNS queries,
• Number of errors in DNS queries,
• EDNS errors,
• expiring zones,
• failed zone transfers, and
• changes in the ratio of errors to DNS queries.

APP.3.6.A16 Integration of a DNS Server into a “P-A-P” Structure (S)

The DNS servers SHOULD be integrated into a “Packet Filter – Application-Level Gateway – Packet Filter” (P-A-P) structure (see also NET.1.1 Network Architecture and Design). In this case, the advertising DNS server SHOULD be located in a demilitarized zone (DMZ) of the outer packet filter. The resolving DNS server SHOULD be placed in a DMZ of the inner packet filter.

APP.3.6.A17 Use of DNSSEC (S)

The DNS protocol extension DNSSEC SHOULD be activated on both resolving DNS servers and advertising DNS servers. The key-signing keys (KSK) and zone-signing keys (ZSK) used SHOULD be rotated regularly.

APP.3.6.A18 Extended Security of Zone Transfers (S)

To further secure zone transfers, Transaction Signatures (TSIG) SHOULD additionally be used.

APP.3.6.A19 Decommissioning of DNS Servers (S)

The DNS server SHOULD be removed from both the domain namespace and the network.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection that corresponds to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the context of an individual risk analysis.

APP.3.6.A20 Review of the Emergency Plan for Feasibility (H)

It SHOULD be regularly checked whether the emergency plan for DNS servers is feasible.

APP.3.6.A21 Hidden Master (H)

To make attacks on the primary advertising DNS server more difficult, a so-called hidden master arrangement SHOULD be implemented.

APP.3.6.A22 Connecting DNS Servers Through Different Providers (H)

Externally accessible DNS servers SHOULD be connected through different providers.

Additional Information

Good to Know

The BSI has published the following further documents on the topic of DNS:

• BSI Cybersecurity Publication BSI-CS 055: “Secure Provision of DNS Services: Recommendations for Internet Service Providers (ISPs) and Large Enterprises”
• BSI Cybersecurity Publication BSI-CS 121: “Implementation of DNSSEC: Recommendations for Setting Up and Operating Domain Name Security Extensions”
• Secure Connection of Local Networks to the Internet (ISi-LANA)

The National Institute of Standards and Technology (NIST) provides recommendations for DNS deployment in NIST Special Publication 800-81-2 “Secure Domain Name System (DNS) – Deployment Guide.”

In the Request for Comments (RFC) series, RFC 1034 “Domain Names – Concepts and Facilities” provides further information on DNS.