APP.3.6 DNS Servers
IntroductionA domain name system (DNS) is a network service used to resolve the host names of IT systems into IP addresses. A DNS can be compared to a telephone book that resolves names into IP addresses rather than telephone numbers. A DNS usually searches for the IP address that corresponds to a given host name (forward resolution). Searching for a host name based on a known IP address, on the other hand, is referred to as reverse resolution. The associations between host names and IP addresses are managed in the domain name space. The domain name space has a hierarchical structure and is provided by DNS servers. While the term “DNS server” actually refers to the software used, it is mostly also used as a synonym for the IT system on which this software is run. DNS servers manage the domain name space on the Internet, but are often also used within an organisation’s internal network. Resolvers are installed as standard components on users’ IT systems. Requests are made to DNS servers via the resolver. In response, the DNS servers return information about the domain namespace. DNS servers can be differentiated by the tasks they perform. There are basically two different types: advertising DNS servers and resolving DNS servers. Advertising DNS servers are usually responsible for processing requests from the Internet. Resolving DNS servers process requests from an organisation's internal network. A DNS server failure may have severe consequences for the operation of IT infrastructure. While a failed DNS system is not a major problem in itself, it does result in restricted DNS-based services. Web servers or e-mail servers may no longer be available, or remote maintenance may no longer function. Since DNS is required by a very large number of network applications, RFC 1034 specifies that at least two authoritative DNS servers (advertising DNS servers) must be operated for every zone. ObjectiveThis module describes the threats specific to DNS servers and the related requirements that ensure their secure operation. Scoping and ModellingModule APP.3.6 DNS Servers must be applied to each DNS server used in the information domain under consideration. This module includes basic specifications to be considered and met when an organisation uses a DNS server. The focus here is on the availability of DNS servers and the integrity of the information transferred. This module also covers problems that can occur in the use of DNS servers. General and operating-system-specific aspects of a server are not included in this module. These are covered in module SYS1.1 General Server and in the corresponding operating-system-specific modules of the SYS IT Systems layer, e.g. SYS.1.3 Linux and Unix Servers or SYS.1.2.2 Windows Server 2012. Useful ResourcesThe BSI has published the following additional documents related to DNS: - BSI publication on cyber security BSI-CS 055: “Sichere Bereitstellung von DNS-Diensten: Handlungsempfehlungen für Internet-Service-Provider (ISP) und große Unternehmen” [Secure Provision of DNS Services: Recommendations for Internet Service Providers (ISPs) and Large Companies]
- BSI publication on cyber security BSI-CS 121: “Umsetzung von DNSSEC: Handlungsempfehlungen zur Einrichtung und zum Betrieb der Domain Name Security Extensions” [Use of DNSSEC: Recommendations for Setting up and Operating the Domain Name Security Extensions]
- Secure connection of local networks to the Internet (ISi-LANA)
The National Institute of Standards and Technology (NIST) provides recommendations on using DNS in the NIST Special Publication 800-81-2, “Secure Domain Name System (DNS)— Deployment Guide”. RFC 1034, “Domain Names—Concepts and Facilities”, provides additional information on DNS.
1. Oversigt
| Titel |
Standard |
|
APP.3.6.A1 Planning the Use of VPNs (B)
|
The use of DNS servers MUST be planned carefully. The manner in which the DNS network service should be set up MUST be determined first. Sensitive domain information MUST also be identified. The manner in which DNS servers are to be incorporated into the network of the information domain in question MUST be planned. All decisions MUST be documented appropriately.
|
|
APP.3.6.A2 Deployment of Redundant DNS Servers (B)
|
Advertising DNS servers MUST be designed for redundancy. There MUST be at least one additional secondary DNS server for every advertising DNS server.
|
|
APP.3.6.A3 Use of Separate DNS Servers for Internal and External Requests (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 to only accept requests from the internal network. If a resolving DNS server sends requests, it MUST use random source ports. If DNS servers delivering forged domain information are known, the resolving DNS server MUST be prevented from sending requests to these DNS servers. An advertising DNS server MUST be configured to always handle requests from the Internet iteratively. It MUST be ensured that DNS zone transfers between primary and secondary DNS servers function appropriately. Zone transfers MUST be configured so that they are only possible between primary and secondary DNS servers. Zone transfers MUST be limited to certain IP addresses. The version of the DNS server product used MUST be hidden.
|
|
APP.3.6.A6 Securing Dynamic DNS Updates (B)
|
It MUST be ensured that only legitimate IT systems are allowed to modify domain information. The domain information that can be changed by the IT systems MUST be specified.
|
|
APP.3.6.A7 Monitoring of DNS Servers (B)
|
DNS servers must be monitored continuously. In particular, DNS server load MUST be monitored in order adapt the performance capacity of the hardware in good time. DNS servers MUST be configured in such a way that at least the following security-relevant events are logged: - number of DNS requests
- number of errors in DNS requests
- errors in extension mechanisms for DNS (EDNS)
- expiring zones
- failed zone transfers
|
|
APP.3.6.A8 Administration of Domain Names [Central Administration] (B)
|
It MUST be ensured that the registrations for all of the domains that an organisation uses are extended regularly and in good time. An employee MUST be assigned responsibility for the administration of Internet domain names. If an organisation commissions an Internet service provider to handle domain administration, it MUST be ensured that the organisation retains control of the domains.
|
|
APP.3.6.A9 Creation of a Business Continuity Plan for DNS Servers (B)
|
A business continuity plan MUST be drawn up for DNS servers. This business continuity plan MUST be integrated into the existing business continuity plans of the organisation in question. The DNS server business continuity plan MUST describe a data backup concept for the zone and configuration files. The business continuity plan for the zone and configuration files MUST be integrated into the organisation's existing backup plan. The contingency plan for DNS servers MUST include a plan to restore all the DNS servers in the information domain under consideration.
|
|
APP.3.6.A10 Selection of a Suitable DNS Server Product (S)
|
If a DNS server product is procured, care SHOULD be taken to ensure that it has proven itself sufficiently in practice. The DNS server product SHOULD support the current RFC standards. Furthermore, the DNS server product SHOULD support the person in charge in creating syntactically correct master files.
|
|
APP.3.6.A11 Sufficient Capacity of DNS Servers (S)
|
The hardware of a DNS server SHOULD have sufficient capacity. A DNS server's hardware SHOULD be used exclusively to operate the server. The network connections of all the DNS servers in the information domain under consideration SHOULD be dimensioned sufficiently.
|
|
APP.3.6.A13 Limited Visibility of Domain Information (S)
|
An information domain's name space should be divided into a public and an organisation-internal area. The public part SHOULD only include the domain information required by services that are to be accessible from external sources. IT systems in the internal network SHOULD not be assigned any DNS names that may be resolved from external sources if they have a public IP address.
|
|
APP.3.6.A14 Location of Name Servers (S)
|
Primary and secondary advertising DNS servers SHOULD be located in different network segments.
|
|
APP.3.6.A15 Analysis of Log Data (S)
|
DNS server log data SHOULD be checked regularly. The DNS server log data SHOULD be evaluated regularly. At a minimum, the following security-relevant events SHOULD be evaluated: - number of DNS requests
- number of errors in DNS requests
- errors in extension mechanisms for DNS (EDNS)
- expiring zones
- failed zone transfers
- changes in the ratio of errors to DNS requests
|
|
APP.3.6.A16 Integrating a DNS Server into a “P-A-P” Structure (S)
|
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 the process, the advertising DNS server SHOULD be placed in a demilitarised zone (DMZ) of the outer packet filter. The resolving DNS server SHOULD be installed in a DMZ of the internal packet filter.
|
|
APP.3.6.A17 Use of DNSSEC (S)
|
The DNS protocol extension DNSSEC SHOULD be enabled on both resolving DNS servers and advertising DNS servers. The key signing keys (KSK) and zone signing keys (ZSK) used for this SHOULD be changed at regular intervals.
|
|
APP.3.6.A18 Advanced Securing of Zone Transfers (S)
|
Transaction signatures (TSIG) SHOULD be used additionally to achieve stronger security of zone transfers.
|
|
APP.3.6.A19 Disposal of DNS Servers (S)
|
A DNS server SHOULD be deleted from both the domain name space and the network system.
|
|
APP.3.6.A20 Feasibility Reviews of Business Continuity Plans (H)
|
An organisation SHOULD check the feasibility of its business continuity plan for DNS servers on a regular basis.
|
|
APP.3.6.A21 Hidden Master (H)
|
In order to make attacks on a primary advertising DNS server more difficult, a hidden master configuration SHOULD be established.
|
|
APP.3.6.A22 Connecting DNS Servers via Different Providers (H)
|
Externally available DNS servers SHOULD be connected using different providers.
|
1.1 Referencer
1.2 Identificerede krav
1.3 Relaterede reguleringer
2. Identificerede krav
3. Relaterede reguleringer
Reguleringer
| Kilde |
Regulering |
Linkede sager
|