Free DISA STIG and SRG Library | Vaulted

Domain Name System (DNS) Security Requirements Guide

Version 2 Release 4
2015-10-23
U_Domain_Name_System_V2R4_Manual-xccdf.xml
The DNS Security Requirements Guide (SRG) is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the NIST 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.

Vulnerabilities (98)

The DNS implementation must limit the number of concurrent sessions client connections to the number of allowed dynamic update clients.

Finding ID
SRG-APP-000001-DNS-000115
Rule ID
SV-69023r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000001-DNS-000115
CCI
CCI-000054
Target Key
(None)
Documentable
No
Discussion

Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation. Name servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements. Primary name servers also make outbound connections to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates. Additionally the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.

Fix Text

Configure the DNS primary server to explicitly specify which hosts from which it accepts dynamic updates.

Check Content

Review the DNS server configuration and ensure a limit has been defined for the number of inbound dynamic update sessions by defining the finite group of hosts allowed to provide those dynamic updates. If the DNS server configuration does not explicitly specify which hosts from which it accepts dynamic updates, this is a finding.

The DNS server implementation must be configured to provide audit record generation capability for DoD-defined auditable events within all DNS server components.

Finding ID
SRG-APP-000089-DNS-000004
Rule ID
SV-69027r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000089-DNS-000004
CCI
CCI-000169
Target Key
(None)
Documentable
No
Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. The DoD has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions.

Fix Text

Configure the DNS server to generate events for successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels) events within all DNS server components.

Check Content

Review the DNS server implementation configuration to determine if the DNS server is configured to generate audit events for successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels) events within all DNS server components. If the DNS server is not configured to generate audit events for successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels) events within all DNS server components, this is a finding.

The DNS server implementation must be configured to provide audit record generation capability for DoD-defined auditable events within all DNS server components.

Finding ID
SRG-APP-000089-DNS-000005
Rule ID
SV-69029r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000089-DNS-000005
CCI
CCI-000169
Target Key
(None)
Documentable
No
Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. The DoD has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions.

Fix Text

Configure the DNS server to generate audit events for successful and unsuccessful logon attempts, privileged activities and system-level access within all DNS server components.

Check Content

Review the DNS server implementation configuration to determine if the DNS server is configured to generate audit events for successful and unsuccessful logon attempts, privileged activities and system-level access. If the DNS server is not configured to generate audit events for successful and unsuccessful logon attempts, privileged activities and system-level access, this is a finding.

The DNS server implementation must produce audit records containing information to establish what type of events occurred.

Finding ID
SRG-APP-000095-DNS-000006
Rule ID
SV-69031r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000095-DNS-000006
CCI
CCI-000130
Target Key
(None)
Documentable
No
Discussion

Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS implementation. Without log records that aid in the establishment of what types of events occurred and when those events occurred, there is no traceability for forensic or analytical purposes, and the cause of events is severely hindered.

Fix Text

Configure the DNS server to log events with enough information to determine what type of event has occurred on the system.

Check Content

Review the DNS system configuration to determine if it is configured to log sufficient information to establish what type of events has occurred on the system. If the logging function is not configured to produce log records with information regarding the type of event, this is a finding.

The DNS server implementation must produce audit records containing information to establish where the events occurred.

Finding ID
SRG-APP-000097-DNS-000008
Rule ID
SV-69033r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000097-DNS-000008
CCI
CCI-000132
Target Key
(None)
Documentable
No
Discussion

Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. Associating information about where the event occurred within the application provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as application components, modules, session identifiers, filenames, host names, and functionality.

Fix Text

Configure the DNS server to produce log records that contain information that establishes where events have occurred. Additionally, configure the audit facility of the DNS system to provide information where events have occurred.

Check Content

Review the DNS system configuration to determine if it is configured to produce, capture and store log records which contain information to establish where events have occurred on the system. If the logging function is not configured to produce log records with information regarding where the event took place, this is a finding.

The DNS server implementation must produce audit records containing information to establish the source of the events.

Finding ID
SRG-APP-000098-DNS-000009
Rule ID
SV-69035r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000098-DNS-000009
CCI
CCI-000133
Target Key
(None)
Documentable
No
Discussion

Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. Associating information about the source of the event within the application provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. In addition to logging where events occur within the application, the application must also produce audit records that identify the application itself as the source of the event. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know the source of the event, particularly in the case of centralized logging. In the case of centralized logging, the source would be the application name accompanied by the host or client name.

Fix Text

Configure the DNS server to produce log records which indicate the source of the events. Additionally, configure the audit facility of the DNS system to provide information to establish the source of events.

Check Content

Review the DNS server configuration to determine if the source of the events is a configurable option within the audit/logging utility and if it is being captured and stored. If the DNS is not configured to capture and store the source of an event, this is a finding.

The DNS server implementation must produce audit records that contain information to establish the outcome of the events.

Finding ID
SRG-APP-000099-DNS-000010
Rule ID
SV-69037r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000099-DNS-000010
CCI
CCI-000134
Target Key
(None)
Documentable
No
Discussion

Without information about the outcome of events, security personnel cannot make an accurate assessment about whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.

Fix Text

Configure the DNS server to produce log records that contain information about success and failure of events on the system. Additionally, configure the audit facility of the DNS system to provide information to establish the success or failure of the event.

Check Content

Review the DNS server configuration to determine if it is configured to produce, capture, and store log records which contain information about success and failure of events on the system. If the logging function is not configured to produce log records with information regarding success and failure of events, this is a finding.

The DNS server implementation must generate audit records containing information that establishes the identity of any individual or process associated with the event.

Finding ID
SRG-APP-000100-DNS-000011
Rule ID
SV-69039r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000100-DNS-000011
CCI
CCI-001487
Target Key
(None)
Documentable
No
Discussion

Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event. Event identifiers (if authenticated or otherwise known) include, but are not limited to, user database tables, primary key values, user names, or process identifiers.

Fix Text

Configure the DNS system audit settings to log specific user information whenever user information is available.

Check Content

Review the DNS system configuration to determine if audit records exist without specific user information, when user information is available. If audit records exist without specific user information when user information is available, this is a finding.

The DNS server implementations audit records must be backed up at least every seven days onto a different system or system component than the system or component being audited.

Finding ID
SRG-APP-000125-DNS-000012
Rule ID
SV-69041r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000125-DNS-000012
CCI
CCI-001348
Target Key
(None)
Documentable
No
Discussion

Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on a defined frequency helps to assure, in the event of a catastrophic system failure, the audit records will be retained. This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records. This requirement only applies to applications that have a native backup capability for audit records. Operating system backup requirements cover applications that do not provide native backup functions.

Fix Text

Configure the DNS server or the underlying O/S to send audit log content to a centralized logging facility.

Check Content

Review the DNS system configuration to determine if audit record content is sent to a centralized audit log repository, either directly by the DNS system or by the underlying O/S. If the DNS system is not configured to support centralized logging and auditing, this is a finding.

The DNS server implementation must be configured to prohibit or restrict unapproved ports and protocols.

Finding ID
SRG-APP-000142-DNS-000014
Rule ID
SV-69043r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000142-DNS-000014
CCI
CCI-000382
Target Key
(None)
Documentable
No
Discussion

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the application must support the organizational requirements by providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.

Fix Text

Configure the DNS implementation for incoming traffic on UDP/53 and TCP/53 and outgoing traffic sent from a random port rather than the DNS software's default port.

Check Content

Review the DNS system configuration to ensure the system is configured for incoming traffic only on UDP/53 and TCP/53 and outgoing DNS traffic sent from a random port rather than the DNS software's default port. If the DNS implementation is not configured for incoming traffic on UDP/53 and TCP/53 and outgoing traffic sent from a random port rather than the DNS software's default port, this is a finding.

The DNS server implementation must uniquely identify the other DNS server before responding to a server-to-server transaction.

Finding ID
SRG-APP-000158-DNS-000015
Rule ID
SV-69045r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000158-DNS-000015
CCI
CCI-000778
Target Key
(None)
Documentable
No
Discussion

Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair (TSIG) or using PKI-based authentication (SIG(0)), thus uniquely identifying the other server.

Fix Text

Configure the DNS server to verify another DNS server's unique identify, through the use of TSIG or SIG(0), when accepting server-to-server (zone transfer) transactions from other DNS servers.

Check Content

Review the DNS server implementation configuration to determine if it validates other DNS servers' unique identify, through the use TSIG or SIG(0), when accepting server-to-server (zone transfer) transactions from the other DNS servers. If the DNS server does not validate other DNS servers' unique identity, through the use of either TSIG or SIG(0), when accepting server-to-server (zone transfer) transactions from those other DNS servers, this is a finding.

The DNS server implementation, when using PKI-based authentication, must enforce authorized access to the corresponding private key.

Finding ID
SRG-APP-000176-DNS-000017
Rule ID
SV-69047r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000017
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. SIG(0) is used for server-to-server authentication for DNS transactions, and it uses PKI-based authentication. So, in cases where SIG(0) is being used instead of TSIG (which uses a shared key, not PKI-based authentication), this requirement is applicable.

Fix Text

Configure the DNS server to enforce authorized access to the corresponding private key when using PKI-based authentication.

Check Content

Review the DNS server implementation configuration to determine if the DNS server, when using PKI-based authentication (e.g., SIG(0)), enforces authorized access to the corresponding private key. If the DNS server does not enforce authorized access to the private key, this is a finding.

The key file must be owned by the account under which the name server software is run.

Finding ID
SRG-APP-000176-DNS-000018
Rule ID
SV-69049r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000018
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key can also be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.

Fix Text

Change ownership for the key file to the account under which the name server software is run.

Check Content

Review the DNS system to determine ownership of the key file and the account under which the name server software is run. If the key file owner is not the same account as the account under which the name server is run, this is a finding.

Read/Write access to the key file must be restricted to the account that runs the name server software only.

Finding ID
SRG-APP-000176-DNS-000019
Rule ID
SV-69051r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000019
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key can also be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.

Fix Text

Apply permissions to the key file to provide read/modify permissions only to the account under which the name server software is run.

Check Content

Review the DNS system to determine privileges on the key file and the account under which the name server software is run. If the account under which the name server software is run is not the only account which has read/modify permissions to the key file, this is a finding.

A unique TSIG key must be generated for each pair of communicating hosts.

Finding ID
SRG-APP-000176-DNS-000076
Rule ID
SV-69053r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000076
CCI
CCI-001339
Target Key
(None)
Documentable
No
Discussion

To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message. The process of authenticating the source of a message and its integrity through hash-based message authentication codes (HMAC) is specified through a set of DNS specifications known collectively as TSIG. The sender of the message uses the HMAC function to generate a MAC and sends this MAC along with the message to the receiver. The receiver, who shares the same secret key, uses the key and HMAC function used by the sender to compute the MAC on the received message. The receiver then compares the computed MAC with the received MAC; if the two values match, it provides assurance that the message has been received correctly and that the sender belongs to the community of users sharing the same secret key. Thus, message source authentication and integrity verification are performed in a single process. To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.

Fix Text

Regenerate a unique TSIG key for each pair of communicating hosts within the DNS architecture.

Check Content

Review the DNS implementation. Verify that each pair of communicating hosts has a unique TSIG key (i.e., a separate key for each secondary name server to authenticate transactions with the primary name server, etc.) If a unique TSIG key has not been generated for each pair of communicating hosts, this is a finding.

Only the private key corresponding to the ZSK alone must be kept on the name server that does support dynamic updates.

Finding ID
SRG-APP-000176-DNS-000094
Rule ID
SV-69055r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000094
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.

Fix Text

Store the private keys of the ZSK and KSK off-line in an encrypted file system.

Check Content

Review the DNS name server and documentation to determine whether it accepts dynamic updates. If dynamic updates are accepted, verify only the private keys corresponding to the ZSK (Zone Signing Key) are located on the server. If the private keys to the KSK are located on the name server that accepts dynamic updates, this is a finding.

Signature generation using the KSK must be done off-line, using the KSK-private stored off-line.

Finding ID
SRG-APP-000176-DNS-000096
Rule ID
SV-69057r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000096
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

Security-relevant information is any information within information systems that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce system security policies or maintain the isolation of code and data. Security-relevant information includes, for example, file permissions, cryptographic key management information, configuration parameters for security services, and access control lists. Secure, non-operable system states include the times in which information systems are not performing mission/business-related processing (e.g., the system is off-line for maintenance, troubleshooting, boot-up, and shut down).

Fix Text

Create operation documentation to include the safe management of keys and key storage within the DNS implementation. Include in the documentation steps to ensure signature generation using the KSK are done off-line, using the KSK-private stored off-line or the secure, protected module.

Check Content

Verify the DNS operational procedures and confirm procedures exist to enforce generating signatures using the KSK are performed off-line, using the KSK-private stored off-line or the secure, protected module. If the procedures do not exist or the procedures do not specify to perform the signature generation off-line from the name server, this is a finding.

The DNS server implementation must employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions.

Finding ID
SRG-APP-000185-DNS-000021
Rule ID
SV-69059r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000185-DNS-000021
CCI
CCI-000877
Target Key
(None)
Documentable
No
Discussion

If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric. This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch). Lack of authentication enables anyone to gain access to the network or possibly a network element that provides opportunity for intruders to compromise resources within the network infrastructure. Network access control mechanisms interoperate to prevent unauthorized access and to enforce the organization's security policy. Authorization for access to any network element requires an individual account identifier that has been approved, assigned, and configured on an authentication server. Authentication of all administrator accounts for all privilege levels must be accomplished using two or more factors that include the following: (i) something you know (e.g., password/PIN); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric).

Fix Text

Configure the DNS system to utilize multifactor authentication for nonlocal access for maintenance and diagnostics.

Check Content

Review the DNS implementation's authentication methods and settings to determine if multifactor authentication is utilized to gain nonlocal access for maintenance and diagnostics. If multifactor authentication is not utilized, this is a finding.

A DNS server implementation must provide additional data origin artifacts along with the authoritative data the system returns in response to external name/address resolution queries.

Finding ID
SRG-APP-000213-DNS-000024
Rule ID
SV-69061r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000213-DNS-000024
CCI
CCI-001178
Target Key
(None)
Documentable
No
Discussion

The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. The security objective is to verify the integrity of each response received. An integral part of integrity verification is to ensure that valid data has originated from the right source. Establishing trust in the source is called data origin authentication. The security objectives—and consequently the security services—that are required for securing the DNS query/response transaction are data origin authentication and data integrity verification. The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF’s DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor.

Fix Text

Generate an RRSET for each zone hosted by the DNS server to include an RRSIG, DNSKEY and NSEC for each zone.

Check Content

Review the zones hosted by the DNS server. Verify each of the zones have been digitally signed. To determine if the zones have been digitally signed, verify the existence of an RRSET for each zone, which will include, at a minimum, an RRType RRSIG (Resource Record Signature) as well as an RRType DNSKEY and RRType NSEC (Next Secure). If the DNS server's zones do not contain these additional RRs along with the regular RRs, this is a finding.

A DNS server implementation must provide the means to indicate the security status of child zones.

Finding ID
SRG-APP-000214-DNS-000025
Rule ID
SV-69063r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000214-DNS-000025
CCI
CCI-001179
Target Key
(None)
Documentable
No
Discussion

If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down. A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. In DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and Domain Name System Security Extensions (DNSSEC). When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate. In DNS, a trust anchor is a DNSKEY that is placed into a validating resolver so the validator can cryptographically validate the results for a given request back to a known public key (the trust anchor). An example means to indicate the security status of child subspaces is through the use of delegation signer (DS) resource records in the DNS. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Without path validation and a chain of trust, there can be no trust that the data integrity authenticity has been maintained during a transaction.

Fix Text

Configure each child zone to upload its DS RRset to the parent zone.

Check Content

Review the zones hosted by the DNS server. Every zone should have an RRSET which includes the RRTypes of RRSIG, DNSKEY and NSEC. If a zone has a child, the RRSET should also include the RRType DS (Delegation Signer) RR, which contain the (hash) public key of child zones. If the zones hosted by the DNS server do not have any child domains, this is not a finding. If the zones hosted by the DNS server have child domains, and there is not an RRType DS RR in the zone's RRSET, this is a finding.

The validity period for the RRSIGs covering the DS RR for a zones delegated children must be no less than two days and no more than one week.

Finding ID
SRG-APP-000214-DNS-000079
Rule ID
SV-69065r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000214-DNS-000079
CCI
CCI-001179
Target Key
(None)
Documentable
No
Discussion

The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. To prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to 1 week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.

Fix Text

Configure RRSIGs for all zones' delegated children to be greater than two days and less than one week.

Check Content

Review the DNS configuration files. Ensure the validity period for RRSIGs for all zones' delegated children has been explicitly configured and is configured for a range of no less than two days and no more than one week. If the validity period for the RRSIGs for all zones' delegated children is less than two days or greater than one week, this is a finding.

The DNS server implementation must enforce approved authorizations for controlling the flow of information between DNS servers and between DNS servers and DNS clients based on DNSSEC policies.

Finding ID
SRG-APP-000215-DNS-000003
Rule ID
SV-69067r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000215-DNS-000003
CCI
CCI-001663
Target Key
(None)
Documentable
No
Discussion

A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. Application-specific examples of enforcement occurs in systems that employ rule sets or establish configuration settings that restrict information system services or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy. Within the context of DNS, this is applicable in terms of controlling the flow of DNS information between systems, such as DNS zone transfers.

Fix Text

Configure the DNS server to enforce approved authorizations for controlling the information flow by applying DNSSEC and TSIG signing practices to the DNS implementation.

Check Content

Review the DNS server implementation configuration to determine if the DNS server enforces approved authorizations for controlling the information flow by using DNSSEC and TSIG signing practices that restrict zone transfers between DNS servers, and dynamic updates from DNS clients to the master name server, to digitally signed traffic. If the DNS server does not enforce approved authorizations for controlling the information flow by using DNSSEC and TSIG signing practices, restricting zone transfers between DNS servers and dynamic updates from DNS clients to the master name server to digitally signed traffic, this is a finding.

A DNS server implementation must provide the means to enable verification of a chain of trust among parent and child domains (if the child supports secure resolution services).

Finding ID
SRG-APP-000215-DNS-000026
Rule ID
SV-69069r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000215-DNS-000026
CCI
CCI-001663
Target Key
(None)
Documentable
No
Discussion

If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down. A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS to map between host/service names and network addresses must provide other means to assure the authenticity and integrity of response data. DNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the delegation signer (DS) resource records in the DNS, the security status of a child domain can be validated. The DS resource record is used to identify the DNSSEC signing key of a delegated zone. Starting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of a Resource Record (RR) Set. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus. This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured.

Fix Text

Configure a recursive, caching only server with the ability to perform DNSSEC validation. Configure an authoritative name server to sign all zones and to update the entire chain of trust with the signature.

Check Content

If the system being reviewed is an authoritative server, it must be able to provide records that can be authenticated (DS, RRSIG, etc.). Compare the child zone's hash stored in the child's DS RR to the hash for the child's zone in the parent's zone information. Verify it is the same hash. If the hashes do not match, or the child zone is not digitally signed, this is a finding. If the system is a recursive server, it must be able to pass DNSSEC data and perform DNSSEC validation. If DNSSEC validation capability is not enabled on a recursive DNS server, this is a finding. If the hash for child domains is not reflected in the parent zone and the chain of trust is not verifiable, this is a finding.

The DNS implementation must protect the authenticity of communications sessions for zone transfers.

Finding ID
SRG-APP-000219-DNS-000028
Rule ID
SV-69071r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000219-DNS-000028
CCI
CCI-001184
Target Key
(None)
Documentable
No
Discussion

DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. If communication sessions are not provided appropriate validity protections, such as the employment of DNSSEC, the authenticity of the data cannot be guaranteed.

Fix Text

Configure the DNS server with transaction signing (TSIG) or SIG(0).

Check Content

Review the DNS server implementation to confirm zone transfers are signing using transaction signing (TSIG) shared key or via SIG(0) asymmetric cryptography public keys. If the DNS server does not ensure integrity of zone transfers by TSIG or SIG(0) signing, this is a finding.

The DNS implementation must protect the authenticity of communications sessions for dynamic updates.

Finding ID
SRG-APP-000219-DNS-000029
Rule ID
SV-69073r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000219-DNS-000029
CCI
CCI-001184
Target Key
(None)
Documentable
No
Discussion

DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. If communication sessions are not provided appropriate validity protections, such as the employment of DNSSEC, the authenticity of the data cannot be guaranteed.

Fix Text

Configure the DNS server to employ mechanisms to protect the authenticity of communications sessions for dynamic updates.

Check Content

Review the DNS server configuration to determine if communication sessions for dynamic updates are provided authenticity protection. If communications sessions do not employ authenticity protections, this is a finding.

The DNS implementation must protect the authenticity of communications sessions for queries.

Finding ID
SRG-APP-000219-DNS-000030
Rule ID
SV-69075r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000219-DNS-000030
CCI
CCI-001184
Target Key
(None)
Documentable
No
Discussion

The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. An integral part of integrity verification is to ensure that valid data has originated from the right source. DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust.

Fix Text

Configure the DNS server to provide resolvers with verification of query response integrity via DNSSEC.

Check Content

Review the DNS server configuration to ensure all zones are configured to provide resolvers with verification of query response integrity via DNSSEC. If the DNS Server configuration is not configured to provide resolvers with verification of query response integrity via the implementation of DNSSEC, this is a finding.

The DNS server implementation must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.

Finding ID
SRG-APP-000225-DNS-000031
Rule ID
SV-69077r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000225-DNS-000031
CCI
CCI-001190
Target Key
(None)
Documentable
No
Discussion

Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Applications or systems that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption of mission-essential processes. In general, application security mechanisms should be designed so that a failure will follow the same execution path as disallowing the operation. For example, security methods, such as isAuthorized(), isAuthenticated(), and validate(), should all return false if there is an exception during processing. If security controls can throw exceptions, they must be very clear about exactly what that condition means. Abort refers to stopping a program or function before it has finished naturally. The term abort refers to both requested and unexpected terminations.

Fix Text

Configure the DNS server to fail to a secure state if system initialization fails, shutdown fails, or aborts fail.

Check Content

Review the DNS server implementation configuration to determine if the DNS server fails to a secure state if system initialization fails, shutdown fails, or aborts fail. If the DNS server does not fail to a secure state under these conditions, this is a finding.

In the event of a system failure, the DNS server implementation must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.

Finding ID
SRG-APP-000226-DNS-000032
Rule ID
SV-69079r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000226-DNS-000032
CCI
CCI-001665
Target Key
(None)
Documentable
No
Discussion

Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving application state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes.

Fix Text

Configure the DNS server to preserve any information necessary to determine cause of system failure and any information necessary to return to operations with least disruption to mission processes.

Check Content

Review the DNS server implementation configuration to determine if the DNS server preserves any information necessary to determine cause of system failure and any information necessary to return to operations with least disruption to mission processes. If the DNS server does not preserve the necessary information, this is a finding.

The DNS server implementation must protect the confidentiality and integrity of secret/private cryptographic keys at rest and the integrity of DNS information at rest.

Finding ID
SRG-APP-000231-DNS-000033
Rule ID
SV-69081r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000231-DNS-000033
CCI
CCI-001199
Target Key
(None)
Documentable
No
Discussion

Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use. The DNS server must protect the confidentiality and integrity of shared keys (for TSIG) and private keys (for SIG(0)) and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.

Fix Text

Configure the DNS server to protect the confidentiality and integrity of secret/private cryptographic keys at rest and the integrity of DNS information at rest.

Check Content

Review the DNS server implementation configuration to determine if the DNS server protects the confidentiality and integrity of secret/private cryptographic keys at rest and the integrity of DNS information at rest. If the DNS server does not properly protect confidentiality and integrity, this is a finding.

The DNS server implementation must prevent unauthorized and unintended information transfer via shared system resources.

Finding ID
SRG-APP-000243-DNS-000034
Rule ID
SV-69083r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000243-DNS-000034
CCI
CCI-001090
Target Key
(None)
Documentable
No
Discussion

Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. There may be shared resources with configurable protections (e.g., files on storage) that may be assessed on specific information system components. The purpose of this control is to prevent information, produced by the actions of a prior process (or the actions of a process acting on behalf of a prior user) from being available to any current DNS process that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse.

Fix Text

Configure the DNS system to protect object reuse to prevent unauthorized and unintended information transfer via shared system resources.

Check Content

Review the DNS vendor documentation and system configuration to determine if object reuse is protected. If object reuse is not protected, this is a finding.

The DNS server implementation must restrict the ability of individuals to use the DNS server to launch Denial of Service (DoS) attacks against other information systems.

Finding ID
SRG-APP-000246-DNS-000035
Rule ID
SV-69085r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000246-DNS-000035
CCI
CCI-001094
Target Key
(None)
Documentable
No
Discussion

A DoS is a condition where a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Individuals of concern can include hostile insiders or external adversaries that have successfully breached the information system and are using the system as a platform to launch cyber attacks on third parties. Applications and application developers must take the steps needed to ensure users cannot use an authorized application to launch DoS attacks against other systems and networks. For example, applications may include mechanisms that throttle network traffic so users are not able to generate unlimited network traffic via the application. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks. When it comes to DoS attacks, most of the attention is paid to ensuring that systems and applications are not victims of these attacks. A DoS attack against the DNS infrastructure has the potential to cause a denial of service to all network users. As the DNS is a distributed backbone service of the Internet, numerous forms of attacks result in DoS, and they are still prevalent on the Internet today. Some potential DoS attacks against the DNS include malformed packet flood, spoofed source addresses, and distributed DoS, and the DNS can be exploited to launch amplification attacks upon other systems. While it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that end, a variety of technologies exist to limit the effects of DoS attacks, such as careful configuration of resolver and recursion functionality. DNS administrators must take the steps needed to ensure other systems and tools cannot use exploits to launch DoS attacks against other systems and networks. An example would be designing the DNS architecture to include mechanisms that throttle DNS traffic and resources so that users/other DNS servers are not able to generate unlimited DNS traffic via the application.

Fix Text

Configure the DNS system to restrict the ability of users or other systems to launch Denial of Service (DoS) attacks from the DNS system.

Check Content

Review the DNS server implementation documentation and system settings to determine if the system restricts the ability of users or systems to launch Denial of Service (DoS) attacks against other information systems or networks from the DNS server. If the DNS system is not configured to restrict this ability, this is a finding.

The DNS server implementation must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.

Finding ID
SRG-APP-000247-DNS-000036
Rule ID
SV-69087r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000247-DNS-000036
CCI
CCI-001095
Target Key
(None)
Documentable
No
Discussion

A DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. In the case of application DoS attacks, care must be taken when designing the application to ensure the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time. A denial of service (DoS) attack against the DNS infrastructure has the potential to cause a DoS to all network users. As the DNS is a distributed backbone service of the Internet, various forms of amplification attacks resulting in DoS, while utilizing the DNS, are still prevalent on the Internet today. Some potential DoS flooding attacks against the DNS include malformed packet flood, spoofed source addresses, and distributed DoS. Without the DNS, users and systems would not have the ability to perform simple name to IP resolution. Configuring the DNS implementation to defend against cache poisoning, employing increased capacity and bandwidth, building redundancy into the DNS architecture, utilizing DNSSEC, limiting and securing recursive services, DNS black holes, etc., may reduce the susceptibility to some flooding types of DoS attacks.

Fix Text

Configure the DNS server to manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of DoS attacks.

Check Content

Review the DNS server implementation and configuration to determine if excess capacity and bandwidth are managed and redundancy is built into the system to limit the effects of information flooding types of DoS attacks. If excess capacity and bandwidth are not managed, or redundancy is not built into the architecture, this is a finding.

The DNS server implementation must check the validity of all data inputs except those specifically identified by the organization.

Finding ID
SRG-APP-000251-DNS-000037
Rule ID
SV-69089r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000251-DNS-000037
CCI
CCI-001310
Target Key
(None)
Documentable
No
Discussion

Invalid user input occurs when a user inserts data or characters into an application's data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior, potentially leading to an application or information system compromise. Invalid input is one of the primary methods employed when attempting to compromise an application. Checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, and acceptable values) verifies that inputs match specified definitions for format and content. Software applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the tainted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing to interpreters prevents the content from being unintentionally interpreted as commands. Input validation helps to ensure accurate and correct inputs and prevent attacks such as cross-site scripting and a variety of injection attacks. Attacks may be generated by entering invalid data into DNS transactions, in the hopes that the data will not be handled correctly and will allow a vulnerable condition to be exploited. To safeguard against this, all data entered in untrusted DNS transactions (e.g., DNS queries from external hosts) should be checked for validity before being processed further.

Fix Text

Configure the DNS server to check the validity of all data inputs except those specifically identified by the organization.

Check Content

Review the DNS server implementation configuration to determine if the DNS server checks the validity of all data inputs except those specifically identified by the organization. If the DNS server does not check the validity of all data inputs, this is a finding.

The DNS server implementation must be configured to generate audit records for failed security verification tests so that the ISSO and ISSM can be notified of the failures.

Finding ID
SRG-APP-000275-DNS-000040
Rule ID
SV-69091r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000275-DNS-000040
CCI
CCI-001294
Target Key
(None)
Documentable
No
Discussion

Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. If personnel are not notified of failed security verification tests, they will not be able to take corrective action and the unsecure condition(s) will remain. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. The DNS server should be configured to generate audit records whenever a self-test fails. The OS/NDM is responsible for generating notification messages related to this audit record.

Fix Text

Configure the DNS server to generate audit records for failed security verification tests so that the ISSO and ISSM can be notified of the failures.

Check Content

Review the DNS server implementation configuration to determine if the DNS server is configured to generate audit records for failed security verification tests so that the ISSO and ISSM can be notified of the failures. If the DNS server is not configured to generate such audit records, this is a finding.

The DNS Name Server software must be configured to refuse queries for its version information.

Finding ID
SRG-APP-000333-DNS-000104
Rule ID
SV-69093r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000333-DNS-000104
CCI
CCI-002201
Target Key
(None)
Documentable
No
Discussion

Each newer version of the name server software, especially the BIND software, generally is devoid of vulnerabilities found in earlier versions because it has design changes incorporated to take care of those vulnerabilities. Of course, these vulnerabilities have been exploited (i.e., some form of attack was launched), and sufficient information has been generated with respect to the nature of those exploits. Thus, it makes good business sense to run the latest version of name server software because theoretically it is the safest version. In some installations, it may not be possible to switch over to the latest version of name server software immediately. If the version of the name server software is revealed in queries, this information may be used by attackers who are looking for a specific version of the software which has a discovered weakness. To prevent information about which version of name server software is running on a system, name servers should be configured to refuse queries for its version information.

Fix Text

Configure the name server to refuse queries for its version information.

Check Content

Review the DNS configuration files. Verify the DNS name server is explicitly configured to refuse queries asking for its version information. If the name server is not configured to explicitly refuse queries asking for its version information, this is a finding.

The HINFO, RP, TXT and LOC RR types must not be used in the zone SOA.

Finding ID
SRG-APP-000333-DNS-000107
Rule ID
SV-69095r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000333-DNS-000107
CCI
CCI-002201
Target Key
(None)
Documentable
No
Discussion

There are several types of RRs in the DNS that are meant to convey information to humans and applications about the network, hosts, or services. These RRs include the Responsible Person (RP) record, the Host Information (HINFO) record, the Location (LOC) record, and the catch-all text string resource record (TXT) [RFC1035]. Although these record types are meant to provide information to users in good faith, they also allow attackers to gain knowledge about network hosts before attempting to exploit them. For example, an attacker may query for HINFO records, looking for hosts that list an OS or platform known to have exploits. Therefore, great care should be taken before including these record types in a zone. In fact, they are best left out altogether. More careful consideration should be taken with the TXT resource record type. A DNS administrator will have to decide if the data contained in a TXT RR constitutes an information leak or is a necessary piece of information. For example, several authenticated email technologies use TXT RR's to store email sender policy information such as valid email senders for a domain. These judgments will have to be made on a case-by-case basis. A DNS administrator should take care when including HINFO, RP, TXT, LOC, or other RR types that could divulge information that would be useful to an attacker or the external view of a zone if using split DNS. RRs such as HINFO and TXT provide information about software name and versions (e.g., for resources such as Web servers and mail servers) that will enable the well-equipped attacker to exploit the known vulnerabilities in those software versions and launch attacks against those resources.

Fix Text

Configure the DNS configuration to not include any HINFO, RP, TXT, or LOC RR type RRs.

Check Content

Review the DNS configuration files. Verify there are not any HINFO, RP, TXT, or LOC RR type RRs in the configuration. If there are any HINFO, RP, TXT or LOC RR type RRs in the configuration, this is a finding.

The DNS server implementation must be configured to allow DNS administrators to change the auditing to be performed on all DNS server components, based on all selectable event criteria.

Finding ID
SRG-APP-000353-DNS-000045
Rule ID
SV-69097r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000353-DNS-000045
CCI
CCI-001914
Target Key
(None)
Documentable
No
Discussion

If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost. This requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours. For a DNS server, the actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.

Fix Text

Configure the DNS server to allow DNS administrators to change the auditing to be performed on all DNS server components, based on all selectable event criteria.

Check Content

Review the DNS server implementation configuration to determine if the DNS server is configured to allow DNS administrators to change the auditing to be performed on all DNS server components, based on all selectable event criteria. If the DNS server is not configured to allow DNS administrators to change the auditing to be performed on all DNS server components, based on all selectable event criteria, this is a finding.

The DNS implementation must limit the number of concurrent sessions for zone transfers to the number of secondary name servers.

Finding ID
SRG-APP-000001-DNS-000001
Rule ID
SV-69099r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000001-DNS-000001
CCI
CCI-000054
Target Key
(None)
Documentable
No
Discussion

Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation. Name servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements. Primary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates. Additionally, the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.

Fix Text

Configure the DNS primary server to explicitly specify which hosts to which it sends zone transfers.

Check Content

Review the DNS server configuration and ensure a limit has been defined for the number of outbound zone transfers to only be allowed to the specified secondary name servers. If the DNS server configuration does not explicitly specify which hosts to which it sends zone transfers, this is a finding.

The DNS implementation must prohibit recursion on authoritative name servers.

Finding ID
SRG-APP-000383-DNS-000047
Rule ID
SV-69101r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000383-DNS-000047
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation. DNSSEC ensures that the answer received when querying for name resolution actually comes from a trusted name server. Since DNSSEC is still far from being globally deployed external to DoD, and many resolvers either haven’t been updated or don’t support DNSSEC, maintaining cached zone data separate from authoritative zone data mitigates the gap until all DNS data is validated with DNSSEC. Since DNS forwarding of queries can be accomplished in some DNS applications without caching locally, DNS forwarding is the method to be used when providing external DNS resolution to internal clients.

Fix Text

Ensure the DNS server is not defined as both authoritative and recursive.

Check Content

Review the DNS server configuration to determine if recursion is being performed on an authoritative name server. If an authoritative name server also performs recursion, this is a finding.

The DNS server implementation must require devices to re-authenticate for each zone transfer and dynamic update request connection attempt.

Finding ID
SRG-APP-000390-DNS-000048
Rule ID
SV-69103r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000390-DNS-000048
CCI
CCI-002039
Target Key
(None)
Documentable
No
Discussion

Without re-authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. In addition to the re-authentication requirements associated with session locks, organizations may require re-authentication of devices, including, but not limited to, the following other situations: (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) After a fixed period of time; or (v) Periodically. DNS does perform server authentication when DNSSEC or TSIG/SIG(0) are used, but this authentication is transactional in nature (each transaction has its own authentication performed). So this requirement is applicable for every server-to-server transaction request.

Fix Text

Configure the DNS server to require devices to re-authenticate each time a zone transfer is initiated and each time a client makes a dynamic update request. Note that the requirement should be inherently met if DNSSEC and TSIG/SIG(0) are enabled.

Check Content

Review the DNS server implementation configuration to determine if the DNS server requires devices to re-authenticate each time a zone transfer is initiated and each time a client makes a dynamic update request. If the DNS server does not require devices to re-authenticate each time a zone transfer is initiated and each time a client makes a dynamic update request, this is a finding. Note that the requirement should be inherently met if DNSSEC and TSIG/SIG(0) are enabled.

The DNS server implementation must authenticate the other DNS server before responding to a server-to-server transaction.

Finding ID
SRG-APP-000394-DNS-000049
Rule ID
SV-69107r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000394-DNS-000049
CCI
CCI-001958
Target Key
(None)
Documentable
No
Discussion

Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system. This requirement applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair (TSIG) or using PKI-based authentication (SIG(0)).

Fix Text

Configure the DNS server to authenticate the other DNS server before responding to a server-to-server transaction.

Check Content

Review the DNS server implementation configuration to determine if the DNS server authenticates the other DNS server before responding to a server-to-server transaction. If the DNS server does not authenticate the other DNS server, this is a finding.

The DNS server implementation must authenticate another DNS server before establishing a remote and/or network connection using bidirectional authentication that is cryptographically based.

Finding ID
SRG-APP-000395-DNS-000050
Rule ID
SV-69109r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000395-DNS-000050
CCI
CCI-001967
Target Key
(None)
Documentable
No
Discussion

Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. This requirement applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair (TSIG) or using PKI-based authentication (SIG(0)).

Fix Text

Configure the DNS server to authenticate another DNS server before establishing a remote and/or network connection using bidirectional authentication that is cryptographically based.

Check Content

Review the DNS server implementation configuration to determine if the DNS server authenticates another DNS server before establishing a remote and/or network connection using bidirectional authentication that is cryptographically based. If the DNS server does not authenticate another DNS server before establishing a connection, this is a finding.

The DNS server implementation, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.

Finding ID
SRG-APP-000401-DNS-000051
Rule ID
SV-69111r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000401-DNS-000051
CCI
CCI-001991
Target Key
(None)
Documentable
No
Discussion

Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates). SIG(0) is used for server-to-server authentication for DNS transactions, and it uses PKI-based authentication. So, in cases where SIG(0) is being used instead of TSIG (which uses a shared key, not PKI-based authentication), this requirement is applicable.

Fix Text

Configure the DNS server, for PKI-based authentication, to implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.

Check Content

Review the DNS server implementation configuration to determine if the DNS server, for PKI-based authentication (i.e., SIG(0)), implements a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network. If the DNS server does not implement such a cache of revocation data, this is a finding.

A DNS server implementation must provide data origin artifacts for internal name/address resolution queries.

Finding ID
SRG-APP-000420-DNS-000053
Rule ID
SV-69113r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000420-DNS-000053
CCI
CCI-002463
Target Key
(None)
Documentable
No
Discussion

The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. This requirement enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS to map between host/service names and network addresses must provide other means to assure the authenticity and integrity of response data. In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.

Fix Text

Configure the DNS server to provide data origin artifacts for internal name/address resolution queries.

Check Content

Review the DNS server implementation configuration to determine if the DNS server provides data origin artifacts for internal name/address resolution queries. If the DNS server does not provide these data origin artifacts, this is a finding.

A DNS server implementation must provide data integrity protection artifacts for internal name/address resolution queries.

Finding ID
SRG-APP-000421-DNS-000054
Rule ID
SV-69115r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000421-DNS-000054
CCI
CCI-002464
Target Key
(None)
Documentable
No
Discussion

The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. This requirement enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS to map between host/service names and network addresses must provide other means to assure the authenticity and integrity of response data. In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.

Fix Text

Configure the DNS server to provide data integrity protection artifacts for internal name/address resolution queries.

Check Content

Review the DNS server implementation configuration to determine if the DNS server provides data integrity protection artifacts for internal name/address resolution queries. If the DNS server does not provide these artifacts, this is a finding.

A DNS server implementation must provide additional integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries.

Finding ID
SRG-APP-000422-DNS-000055
Rule ID
SV-69117r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000422-DNS-000055
CCI
CCI-002462
Target Key
(None)
Documentable
No
Discussion

The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. This requirement enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS to map between host/service names and network addresses must provide other means to assure the authenticity and integrity of response data. In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.

Fix Text

Configure the DNS server to provide additional integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries.

Check Content

Review the DNS server implementation configuration to determine if the DNS server provides additional integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries. If the DNS server does not provide such integrity artifacts, this is a finding.

A DNS server implementation must request data origin authentication verification on the name/address resolution responses the system receives from authoritative sources.

Finding ID
SRG-APP-000423-DNS-000056
Rule ID
SV-69119r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000423-DNS-000056
CCI
CCI-002465
Target Key
(None)
Documentable
No
Discussion

If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.

Fix Text

Configure the DNS server to request data origin authentication verification on the name/address resolution responses the system receives from authoritative sources.

Check Content

Review the DNS server implementation configuration to determine if the DNS server requests data origin authentication verification on the name/address resolution responses the system receives from authoritative sources. If the DNS server does not request data origin authentication verification on the responses, this is a finding.

A DNS server implementation must request data integrity verification on the name/address resolution responses the system receives from authoritative sources.

Finding ID
SRG-APP-000424-DNS-000057
Rule ID
SV-69121r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000424-DNS-000057
CCI
CCI-002466
Target Key
(None)
Documentable
No
Discussion

If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.

Fix Text

Configure the DNS server to request data integrity verification on the name/address resolution responses the system receives from authoritative sources.

Check Content

Review the DNS server implementation configuration to determine if the DNS server requests data integrity verification on the name/address resolution responses the system receives from authoritative sources. If the DNS server does not request data integrity verification on the responses, this is a finding.

A DNS server implementation must perform data integrity verification on the name/address resolution responses the system receives from authoritative sources.

Finding ID
SRG-APP-000425-DNS-000058
Rule ID
SV-69123r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000425-DNS-000058
CCI
CCI-002467
Target Key
(None)
Documentable
No
Discussion

If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.

Fix Text

Configure the DNS server to perform data integrity verification on the name/address resolution responses the system receives from authoritative sources.

Check Content

Review the DNS server implementation configuration to determine if the DNS server performs data integrity verification on the name/address resolution responses the system receives from authoritative sources. If the DNS server does not perform data integrity verification on the responses, this is a finding.

A DNS server implementation must perform data origin verification authentication on the name/address resolution responses the system receives from authoritative sources.

Finding ID
SRG-APP-000426-DNS-000059
Rule ID
SV-69131r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000426-DNS-000059
CCI
CCI-002468
Target Key
(None)
Documentable
No
Discussion

If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed which would result in query failure or denial of service. Data origin authentication verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.

Fix Text

Configure the DNS server to perform data origin verification authentication on the name/address resolution responses the system receives from authoritative sources.

Check Content

Review the DNS server implementation configuration to determine if the DNS server performs data origin verification authentication on the name/address resolution responses the system receives from authoritative sources. If the DNS server does not perform data origin verification authentication on the responses, this is a finding.

If the DNS server is using SIG(0), the DNS server implementation must only allow the use of DoD PKI-established certificate authorities for verification of the establishment of protected transactions.

Finding ID
SRG-APP-000427-DNS-000060
Rule ID
SV-69133r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000427-DNS-000060
CCI
CCI-002470
Target Key
(None)
Documentable
No
Discussion

Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. SIG(0) relies on PKI-based authentication, so if SIG(0) is being used, this requirement is applicable.

Fix Text

Configure the DNS server to only allow the use of DoD PKI-established certificate authorities for verification of the establishment of protected transactions.

Check Content

If the DNS server is using SIG(0), review the DNS server implementation configuration to determine if the DNS server only allows the use of DoD PKI-established certificate authorities for verification of the establishment of protected transactions. If the DNS server allows the use of other certificate authorities, this is a finding.

The DNS server implementation must utilize cryptographic mechanisms to prevent unauthorized disclosure of non-DNS data stored on the DNS server.

Finding ID
SRG-APP-000429-DNS-000062
Rule ID
SV-69135r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000429-DNS-000062
CCI
CCI-002476
Target Key
(None)
Documentable
No
Discussion

Applications handling data requiring "data-at-rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. Selection of a cryptographic mechanism is based on the need to protect the confidentiality of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). The DNS server must protect the confidentiality of keys (for TSIG/SIG(0) and DNSSEC). There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.

Fix Text

Configure the DNS server to utilize cryptographic mechanisms to prevent unauthorized disclosure of non-DNS data while stored on the DNS server.

Check Content

Review the DNS server implementation configuration to determine if the DNS server utilizes cryptographic mechanisms to prevent unauthorized disclosure of non-DNS data while stored on the DNS server. If the DNS server does not utilize cryptographic mechanisms to prevent unauthorized disclosure, this is a finding.

The DNS server implementation must protect the integrity of transmitted information.

Finding ID
SRG-APP-000439-DNS-000063
Rule ID
SV-69137r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000439-DNS-000063
CCI
CCI-002418
Target Key
(None)
Documentable
No
Discussion

Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.

Fix Text

Configure the DNS server to protect the integrity of transmitted information.

Check Content

Review the DNS implementation configuration to determine if the DNS server protects the integrity of transmitted information. If the DNS server does not protect the integrity of transmitted information, this is a finding.

The DNS server implementation must implement cryptographic mechanisms to detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS).

Finding ID
SRG-APP-000440-DNS-000065
Rule ID
SV-69141r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000440-DNS-000065
CCI
CCI-002421
Target Key
(None)
Documentable
No
Discussion

Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.

Fix Text

Configure the DNS server to detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution Systems (PDS).

Check Content

Review the DNS server implementation configuration to determine if the DNS server implements cryptographic mechanisms to detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS). If the DNS server does not implement such cryptographic mechanisms, this is a finding.

The DNS server implementation must maintain the integrity of information during preparation for transmission.

Finding ID
SRG-APP-000441-DNS-000066
Rule ID
SV-69143r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000441-DNS-000066
CCI
CCI-002420
Target Key
(None)
Documentable
No
Discussion

Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. Confidentiality is not an objective of DNS, but integrity is. DNS is responsible for maintaining the integrity of DNS information while it is being prepared for transmission.

Fix Text

Configure the DNS server to maintain the integrity of information during preparation for transmission.

Check Content

Review the DNS server implementation configuration to determine if the DNS server maintains the integrity of information during preparation for transmission. If the DNS server does not maintain the integrity during preparation for transmission, this is a finding.

The DNS server implementation must maintain the integrity of information during reception.

Finding ID
SRG-APP-000442-DNS-000067
Rule ID
SV-69145r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000442-DNS-000067
CCI
CCI-002422
Target Key
(None)
Documentable
No
Discussion

Information can be either unintentionally or maliciously disclosed or modified during reception, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. Confidentiality is not an objective of DNS, but integrity is. DNS is responsible for maintaining the integrity of DNS information while it is being received.

Fix Text

Configure the DNS server to maintain the integrity of information during reception.

Check Content

Review the DNS server implementation configuration to determine if the DNS server maintains the integrity of information during reception. If the DNS server does not maintain integrity during reception, this is a finding.

The DNS server implementation must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

Finding ID
SRG-APP-000447-DNS-000068
Rule ID
SV-69147r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000447-DNS-000068
CCI
CCI-002754
Target Key
(None)
Documentable
No
Discussion

A common vulnerability of applications is unpredictable behavior when invalid inputs are received. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state. The behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input. Attacks may be generated by entering invalid data into DNS transactions, in the hopes that the data will not be handled correctly and will allow a vulnerable condition to be exploited. To safeguard against this, all untrusted data entered in DNS transactions (e.g., DNS queries) should be checked for validity before being processed further.

Fix Text

Configure the DNS server to behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

Check Content

Review the DNS server implementation configuration to determine if the DNS server behaves in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received. If the DNS server does not behave in such a manner, this is a finding.

The DNS server implementation must follow procedures to re-role a secondary name server as the master name server should the master name server permanently lose functionality.

Finding ID
SRG-APP-000451-DNS-000069
Rule ID
SV-69149r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000451-DNS-000069
CCI
CCI-002775
Target Key
(None)
Documentable
No
Discussion

Failing to an unsecure condition negatively impacts application security and can lead to system compromise. Failure conditions include, for example, loss of communications among critical system components or between system components and operational facilities. Fail-safe procedures include, for example, alerting operator personnel and providing specific instructions on subsequent steps to take (e.g., do nothing, reestablish system settings, shut down processes, restart the system, or contact designated organizational personnel). If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.

Fix Text

Develop internal procedures to ensure a secondary name server to the master in the event the master DNS name server permanently loses functionality.

Check Content

Review the DNS server implementation operating documentation to determine if procedures exist to promote a secondary name server to the master in the event the master DNS name server permanently loses functionality. If procedures do not exist to promote a secondary name server to the master in the event the master DNS name server permanently loses functionality, this is a finding.

The DNS server implementation must perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.

Finding ID
SRG-APP-000473-DNS-000072
Rule ID
SV-69151r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000473-DNS-000072
CCI
CCI-002699
Target Key
(None)
Documentable
No
Discussion

Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Without verification, security functions may not operate correctly and this failure may go unnoticed. Notifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights. The DNS server should perform self-tests, such as at server start-up, to confirm that its security functions are working properly.

Fix Text

Configure the DNS server to perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.

Check Content

Review the DNS server implementation configuration to determine if the DNS server performs verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days. If the DNS server does not perform this verification when needed, this is a finding.

The DNS server implementation must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.

Finding ID
SRG-APP-000474-DNS-000073
Rule ID
SV-69153r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000474-DNS-000073
CCI
CCI-002702
Target Key
(None)
Documentable
No
Discussion

Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. If anomalies are not acted upon, security functions may fail to secure the system. The DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered, and the OS/NDM can then trigger notification messages to the system administrator based on the presence of those audit records.

Fix Text

Configure the DNS server to log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.

Check Content

Review the DNS server implementation configuration to determine if the DNS server logs the event and notifies the system administrator when anomalies in the operation of the signed zone transfers are discovered. If the DNS server implementation does not log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered, this is a finding.

The DNS implementation must generate audit records for the success and failure of start and stop of the name server service or daemon.

Finding ID
SRG-APP-000504-DNS-000074
Rule ID
SV-69155r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000504-DNS-000074
CCI
CCI-000172
Target Key
(None)
Documentable
No
Discussion

Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, to recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.

Fix Text

Configure the DNS system to log success and failure of the start and stop of the name service or daemon.

Check Content

Review the DNS system to determine if it is configured to log success and failure of the start and stop of the name server service or daemon. If the DNS system is not configured to log these events, this is a finding.

The DNS implementation must generate audit records for the success and failure of all name server events.

Finding ID
SRG-APP-000504-DNS-000082
Rule ID
SV-69157r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000504-DNS-000082
CCI
CCI-000172
Target Key
(None)
Documentable
No
Discussion

Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.

Fix Text

Configure the DNS system to log success and failure of zone transfers, zone update notifications, dynamic updates, and start and stop of the name server service or daemon.

Check Content

Review the DNS system to determine if it is configured to log, at a minimum, success and failure of zone transfers dynamic updates, and start and stop of the name server service or daemon. If the DNS is not configured to log success and failure of zone transfers, zone update notifications, dynamic updates, and start and stop of the name server service or daemon, this is a finding.

The DNS server must implement NIST FIPS-validated cryptography for provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information requiring confidentiality.

Finding ID
SRG-APP-000514-DNS-000075
Rule ID
SV-69161r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000514-DNS-000075
CCI
CCI-002450
Target Key
(None)
Documentable
No
Discussion

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Fix Text

Configure the DNS implementation to use NIST FIPS-validated cryptography for provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information requiring confidentiality.

Check Content

Review the DNS implementation and configuration files to ensure FIPS-validated cryptography is being used when provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information that requires confidentiality. If the DNS configuration does not use FIPS-validated cryptography, this is a finding.

The salt value for zones signed using NSEC3 RRs must be changed every time the zone is completely re-signed.

Finding ID
SRG-APP-000516-DNS-000077
Rule ID
SV-69163r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000077
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

NSEC3 RRs contain other options than just the (hashed) next name and RRType bitmap. There are also 2 values associated with the NSEC3 RR: the iterations (number of times each name is hashed) and the salt (string appended to each name before hashing). These values are configurable during signing and are used to increase the work necessary by an attacker. Both values should be changed on a regular basis to maintain protection against zone enumeration. The salt value should be changed every time the entire zone is re-signed. The salt value should be a random string with a length small enough to ensure that appending the salt value to the domain name does not result in a FQDN considered too long for the DNS protocol (a single label in the DNS protocol can be 256 octets). A value between 1 - 15 octets would be acceptable for the majority of cases. Note that zones that are dynamically re-signed as needed may not be able to change the salt for NSEC3 RRs as an automatic process. In these cases, the salt rollover procedure is similar to the key algorithm rollover procedure in that the NSEC3 RR chain with the new salt is generated first (ending with the NSEC3PARAM RR) before removing the old (outgoing) NSEC3 chain.

Fix Text

Include instructions in the DNS operational procedures to change the salt value every time RRs signed by NSEC3 have been re-signed.

Check Content

Check the DNS configuration files and operational documentation. If the zone's RRs have been signed with NSEC3, the operational procedures should stipulate to change the salt value every time the zone is completely re-signed. If the operational procedures do not specify to change the salt value for RRs signed with NSEC3 every time the zone is completely re-signed, this is a finding.

The validity period for the RRSIGs covering a zones DNSKEY RRSet must be no less than two days and no more than one week.

Finding ID
SRG-APP-000516-DNS-000078
Rule ID
SV-69165r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000078
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. To minimize the impact of a compromised ZSK, a zone administrator should set a signature validity period of 1 week for RRSIGs covering the DNSKEY RRSet in the zone (the RRSet that contains the ZSK and KSK for the zone). The DNSKEY RRSet can be re-signed without performing a ZSK rollover, but scheduled ZSK rollover should still be performed at regular intervals.

Fix Text

Configure RRSIGs covering each zone's DNSKEY RRSet to be greater than two days and less than one week.

Check Content

Review the DNS configuration files. Ensure the validity period for RRSIGs has been explicitly configured and is configured for a range of no less than two days and no more than one week. If the validity period for the RRSIGs covering a zone's DNSKEY RRSet is less than two days or greater than one week, this is a finding.

NSEC3 must be used for all internal DNS zones.

Finding ID
SRG-APP-000516-DNS-000084
Rule ID
SV-69167r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000084
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

To ensure that RRs associated with a query are really missing in a zone file and have not been removed in transit, the DNSSEC mechanism provides a means for authenticating the nonexistence of an RR. It generates a special RR called an NSEC (or NSEC3) RR that lists the RRTypes associated with an owner name as well as the next name in the zone file. It sends this special RR, along with its signatures, to the resolving name server. By verifying the signature, a DNSSEC-aware resolving name server can determine which authoritative owner name exists in a zone and which authoritative RRTypes exist at those owner names. IETF's design criteria consider DNS data to be public. Confidentiality is not one of the security goals of DNSSEC. DNSSEC is not designed to directly protect against denial-of-service threats but does so indirectly by providing message integrity and source authentication. An artifact of how DNSSEC performs negative responses allows a client to map all the names in a zone (zone walking). A zone which contains zone data that the administrator does not want to be made public should use the NSEC3 RR option for providing authenticated denial of existence. If DNSSEC is enabled for a server, the ability to verify a particular server which may attempt to update the DNS server actually exists. This is done through the use of NSEC3 records to provide an "authenticated denial of existence" for specific systems whose addresses indicate that they lie within a particular zone.

Fix Text

Configure all internal zones to use the NSEC3 RR option for authenticated denial of existence.

Check Content

Review the zone file's configuration for internal zones and confirm the NSEC3 RR option is used to provide authenticated denial of existence. If the NSEC3 RR option is not used for internal zones, this is a finding.

The DNS implementation must ensure each NS record in a zone file points to an active name server authoritative for the domain specified in that record.

Finding ID
SRG-APP-000516-DNS-000085
Rule ID
SV-69169r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000085
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary's name server from a valid authoritative name server, one that need not be compromised for this attack to be successful. The list of slave servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of slaves. If a slave server has been retired or is not operational but remains on the list, then an adversary might have a greater opportunity to impersonate that slave without detection, rather than if the slave were actually online. For example, the adversary may be able to spoof the retired slave's IP address without an IP address conflict, which would not be likely to occur if the true slave were active.

Fix Text

Remove any NS record in a zone file that does not point to an active name server authoritative for the domain specified in that record.

Check Content

Review the zone file's configuration and confirm that each NS record points to an active name server authoritative for the domain. If this is not the case, this is a finding.

The two files generated by the dnssec-keygen program must be made accessible only to the server administrator account, or deleted, after they have been copied to the key file in the name server.

Finding ID
SRG-APP-000516-DNS-000086
Rule ID
SV-69171r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000086
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. ATSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.

Fix Text

Configure permissions on the key files to only give access to the server administrator, or delete the key files altogether. Destroy all paper copies of the key files.

Check Content

Review the DNS implementation and documentation and confirm the permissions on the key files, which were generated by the dnssec-keygen program and copied to the name server, are only accessible to the server administrator or have been deleted. Verify all paper copies of the key files have been destroyed. If the key files have been deleted and all paper copies have been destroyed, this is not a finding. If the key files have been deleted but the paper copies have not been destroyed, this is a finding. If the key files still exist, and the permissions on the key files have not been configured to only allow the server administrator account access, this is a finding.

All authoritative name servers for a zone must be located on different network segments.

Finding ID
SRG-APP-000516-DNS-000087
Rule ID
SV-69173r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000087
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative name servers for an enterprise be located on different network segments. This dispersion ensures the availability of an authoritative name server not only in situations in which a particular router or switch fails but also during events involving an attack on an entire network segment. A network administrator may choose to use a "hidden" master authoritative server and only have secondary servers visible on the network. A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the master authoritative name server is "hidden", a secondary authoritative name server may reside on the same network as the hidden master.

Fix Text

Locate all visible (non-hidden) name servers to be on different network segments.

Check Content

Review the DNS configuration files to determine all of the NS records for each zone. Based upon the NS records for each zone, determine location of each of the name servers. Verify all authoritative name servers are located on different network segments. If two authoritative name servers are found on the same network segment, and one of those two is hidden, this is not a finding. If any authoritative name servers are located on the same network segment as another authoritative name server, this is a finding.

All authoritative name servers for a zone must have the same version of zone information.

Finding ID
SRG-APP-000516-DNS-000088
Rule ID
SV-69175r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000088
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The only protection approach for content control of DNS zone file is the use of a zone file integrity checker. The effectiveness of integrity checking using a zone file integrity checker depends upon the database of constraints built into the checker. The deployment process consists of developing these constraints with the right logic, and the only determinant of the truth value of these logical predicates is the parameter values for certain key fields in the format of various RRTypes. The serial number in the SOA RDATA is used to indicate to secondary name servers that a change to the zone has occurred and a zone transfer should be performed. It should always be increased whenever a change is made to the zone data. DNS NOTIFY must be enabled on the master authoritative name server.

Fix Text

Troubleshoot and fix any problems with zone transfers completing successfully between the primary name server and all secondary name servers.

Check Content

Review the DNS configuration for each zone hosted by the authoritative name server. Determine all authoritative name servers for each zone. Review the serial number in the SOA RDATA, on each authoritative name server for each zone, and ensure the serial number is the same on each secondary name server as on the primary name server. If any secondary name server for a zone has a serial number in the SOA RDATA that is different from the primary name server, this is a finding.

An authoritative name server must be configured to enable DNSSEC Resource Records.

Finding ID
SRG-APP-000516-DNS-000089
Rule ID
SV-69177r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000089
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. DNSSEC mechanisms involve two main processes: sign and serve, and verify signature. Before a DNSSEC-signed zone can be deployed, a name server must be configured to enable DNSSEC processing.

Fix Text

Configure the name server with DNSSEC enabled.

Check Content

Check the DNS configuration to ensure DNSSEC Resource Records has been enabled. If the name server is not configured with DNSSEC enabled, this is a finding.

For zones split between the external and internal sides of a network, the RRs for the external hosts must be separate from the RRs for the internal hosts.

Finding ID
SRG-APP-000516-DNS-000091
Rule ID
SV-69179r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000091
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. External clients need to receive RRs that pertain only to public services (public Web server, mail server, etc.) Internal clients need to receive RRs pertaining to public services as well as internal hosts. The zone information that serves the RRs on both the inside and the outside of a firewall should be split into different physical files for these two types of clients (one file for external clients and one file for internal clients).

Fix Text

Remove any RRs listed in the internal name server configuration which resolve for external hosts and remove any RRs listed in the external name server configuration which resolve to internal hosts. For hosts intended to be accessed by both internal and external clients, configure unique IP addresses in each of the internal and external name servers, respective to their location. The perimeter firewall, or other routing device, should handle the Network Address Translation to the true IP address of the destination.

Check Content

Review the Resource Records (RRs) of each zone which is split between external and internal networks. For those internal hosts which are intended to be accessed by both internal and external users, a different RR should be listed on each of the internal and external name servers, with IP addresses reflective of the external or internal network. Traffic destined for those internal hosts will resolve to the IP address in the external name server and then should be NAT'd through the perimeter firewall. Verify the RRs in the internal name server are not also listed in the external name server. If there are RRs in the internal name server for hosts also listed in the external name server, and the IP to which it resolves is on the external network, this is a finding. Verify the RRs in the external name server are not also listed in the internal name server. If there are RRs in the external name server for hosts also listed in the internal name server, and the IP to which it resolves is on the internal network, this is a finding.

In a split DNS configuration, where separate name servers are used between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.

Finding ID
SRG-APP-000516-DNS-000092
Rule ID
SV-69181r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000092
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) The other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.

Fix Text

Configure the DNS configuration on internal name servers to only accept queries from internal resolvers. Configure DNS configuration on external name servers to only accept queries from external resolvers. Configure network perimeter devices to block query resolution traffic from external resolvers to internal name servers and from internal resolvers to external name servers.

Check Content

Review the DNS implementation and ensure the external DNS name servers are not reachable by internal resolvers. If the external DNS name servers can be reached by internal resolvers, this is a finding.

In a split DNS configuration, where separate name servers are used between the external and internal networks, the internal name server must be configured to not be reachable from outside resolvers.

Finding ID
SRG-APP-000516-DNS-000093
Rule ID
SV-69183r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000093
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) The other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.

Fix Text

Configure the DNS configuration on internal name servers to only accept queries from internal resolvers. Configure DNS configuration on external name servers to only accept queries from external resolvers. Configure network perimeter devices to block query resolution traffic from external resolvers to internal name servers and from internal resolvers to external name servers.

Check Content

Review the DNS implementation and ensure internal DNS name servers are not reachable by external resolvers. If the internal DNS name servers can be reached by external resolvers, this is a finding.

Primary authoritative name servers must be configured to only receive zone transfer requests from specified secondary name servers.

Finding ID
SRG-APP-000516-DNS-000095
Rule ID
SV-69185r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000095
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Authoritative name servers (especially primary name servers) should be configured with an allow-transfer access control substatement designating the list of hosts from which zone transfer requests can be accepted. These restrictions address the denial-of-service threat and potential exploits from unrestricted dissemination of information about internal resources. Based on the need-to-know, the only name servers that need to refresh their zone files periodically are the secondary name servers. Zone transfer from primary name servers should be restricted to secondary name servers. The zone transfer should be completely disabled in the secondary name servers. The address match list argument for the allow-transfer substatement should consist of IP addresses of secondary name servers and stealth secondary name servers.

Fix Text

Configure the authoritative name server to specify which secondary name servers from which it will receive zone transfer requests.

Check Content

Review the DNS configuration files. Verify a configuration is in place to limit the secondary name servers from which an authoritative name server receives zone transfer requests. If a configuration is not in place to limit the secondary name servers from which an authoritative name server receives zone transfer requests, this is a finding.

The DNS implementation must be conformant to the IETF DNS specification.

Finding ID
SRG-APP-000516-DNS-000097
Rule ID
SV-69187r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000097
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Any DNS implementation must be designed to be able to conform to the Internet Engineering Task Force (IETF) specification. DoD utilizes many different DNS servers, and it is essential that core capabilities of all are compatible. DNS servers that do not provide services compliant to the DNS RFCs may cause denial of service issues. The server must be compliant to the IETF standard so as to provide the right balance between performance and integrity of the DNS system.

Fix Text

Configure the DNS implementation to be compliant to the IETF specifications for DNS. Protect DNS transactions, such as update of DNS name resolution data and data replication that involve DNS nodes within an enterprise's control. The transactions should be protected using hash-based message authentication codes based on shared secrets, as outlined in Internet Engineering Task Force's (IETF) Transaction Signature (TSIG) specification. Protect the ubiquitous DNS query/response transaction that could involve any DNS node in the global Internet using digital signatures based on asymmetric cryptography, as outlined in IETF's Domain Name System Security Extension (DNSSEC) specification.

Check Content

Review DNS implementation documentation to determine whether the DNS system has capabilities compliant to IETF RFC-1034 (Domain Names-Concepts and Facilities), RFC-1035 (Domain Names-Implementation and Specification), and subsequent RFCs. Systems using DNSSEC (DNS Security Extensions) should be compliant to RFC-4033 (DNS Security Introduction and Requirements), RFC-4024 (Resource Records for the DNS Security Extensions), RFC-4035 (Protocol Modifications for the DNS security Extensions), RFC-5155 (DNS Security (DNSSEC) Hashed Authenticated Denial of Existence) and related RFCs. A DNS implementation may also be found non-compliant by empirical analysis, i.e., by experimentally querying and examine the answer. For example, a DNS implementation may not answer a query for the 'NS' resource record type with a CNAME reply. If the implementation does not comply to the IETF DNS RFCs, this is a finding.

The DNS implementation must enforce a Discretionary Access Control (DAC) policy that limits propagation of access rights.

Finding ID
SRG-APP-000516-DNS-000099
Rule ID
SV-69189r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000099
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly. The primary objective of DNS authentication and access control is the integrity of DNS records; only authorized personnel must be able to create and modify resource records, and name servers should only accept updates from authoritative master servers for the relevant zones. Integrity is best assured through authentication and access control features within the name server software and the file system the name server resides on. In order to protect the zone files and configuration data, which should only be accessed by the name service or an administrator, access controls need to be implemented on files, and rights should not be easily propagated to other users. Lack of a stringent access control policy places the DNS infrastructure at risk to malicious persons and attackers, in addition to potential denial of service to network resources. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. DAC models have the potential for the access controls to propagate without limit, resulting in unauthorized access to said objects. When applications provide a DAC mechanism, the DNS implementation must be able to limit the propagation of those access rights.

Fix Text

Configure the DNS implementation to eliminate access rights propagation.

Check Content

Review the DNS configuration and access control structure to determine if DACs are in place to limit the propagation of rights as determined by the organization. Access control lists for user permissions, as well as zone transfers and updates, must be present. If they are not present, this is a finding.

The DNS implementation must implement internal/external role separation.

Finding ID
SRG-APP-000516-DNS-000101
Rule ID
SV-69191r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000101
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

DNS servers with an internal role only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks, including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization using address ranges, explicit access control lists, etc. In order to protect internal DNS resource information, it is important to isolate the requests to internal DNS servers. Separating internal and external roles in DNS prevents address space that is private (e.g., 10.0.0.0/24) or is otherwise concealed by some form of Network Address Translation from leaking into the public DNS system.

Fix Text

Configure the DNS server to separate internal and external roles to protect private address space.

Check Content

Review the zone configuration with the DNS administrator and verify whether the zone has records on both the internal and external networks. If the zone is split, verify there is a separate external name server to handle the host records for external address space and an internal name server to handle the host records for internal address space. If there are split zones and there are not internal and external roles to protect private address space, this is a finding.

The DNS must utilize valid root name servers in the local root zone file.

Finding ID
SRG-APP-000516-DNS-000102
Rule ID
SV-69193r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000102
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

All caching name servers must be authoritative for the root zone because, without this starting point, they would have no knowledge of the DNS infrastructure and thus would be unable to respond to any queries. The security risk is that an adversary could change the root hints and direct the caching name server to a bogus root server. At that point, every query response from that name server is suspect, which would give the adversary substantial control over the network communication of the name servers' clients. When authoritative servers are sent queries for zones that they are not authoritative for, and they are configured as a non-caching server (as recommended), they can either be configured to return a referral to the root servers or they can be configured to refuse to answer the query. The recommendation is to configure authoritative servers to refuse to answer queries for any zones for which they are not authoritative. This is more efficient for the server and allows it to spend more of its resources doing what its intended purpose is, answering authoritatively for its zone.

Fix Text

Configure the DNS implementation to use valid root name servers.

Check Content

Review the entries within the root hints file and validate that the entries are correct. G and H root servers are required on the NIPRNet, as a minimum. All default settings on servers must be verified and corrected if necessary. If valid root name servers are not configured, this is a finding.

The DNS name server software must be at the latest version.

Finding ID
SRG-APP-000516-DNS-000103
Rule ID
SV-69195r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000103
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Each newer version of the name server software, especially the BIND software, generally is devoid of vulnerabilities found in earlier versions because it has design changes incorporated to take care of those vulnerabilities. These vulnerabilities have been exploited (i.e., some form of attack was launched), and sufficient information has been generated with respect to the nature of those exploits. It makes good business sense to run the latest version of name server software because theoretically it is the safest version. Even if the software is the latest version, it is not safe to run it in default mode. The security administrator should always configure the software to run in the recommended secure mode of operation after becoming familiar with the new security settings for the latest version.

Fix Text

Update the installed name server software with the latest production version.

Check Content

Review the DNS implementation to determine the name server software version. If the installed name server software version is not the latest production version, this is a finding.

The DNS Name Server software must run with restricted privileges.

Finding ID
SRG-APP-000516-DNS-000105
Rule ID
SV-69197r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000105
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall security of the system. When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications. Logical access restrictions include, for example, controls that restrict access to workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). If the name server software is run as a privileged user (e.g., root in Unix systems), any break-in into the software can have disastrous consequences in terms of resources resident in the name server platform. Specifically, a hacker who breaks into the software acquires unrestricted access and therefore can execute any commands or modify or delete any files. It is necessary to run the name server software as a non-privileged user with access restricted to specified directories to contain damages resulting from break-in.

Fix Text

Configured the permissions of the account being used to run the DNS software so that it has the least privileges required under which to run the DNS software.

Check Content

Review the account under which the DNS software is running and determine the permissions that account has been assigned. If the account under which the DNS software is running has not been restricted to the least privileged permissions required for the purpose of running the software, this is a finding.

The IP address for hidden master authoritative name servers must not appear in the name servers set in the zone database.

Finding ID
SRG-APP-000516-DNS-000108
Rule ID
SV-69199r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000108
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. All of the name servers that do appear in the zone database as designated name servers get their zone data from the hidden master via a zone transfer request. In effect, all visible name servers are actually secondary slave servers. This prevents potential attackers from targeting the master name server because its IP address may not appear in the zone database.

Fix Text

Remove, from all zones' configuration files, any NS RRs for hidden name servers.

Check Content

Check the DNS documentation to determine if a hidden master authoritative name server is being used. If a hidden master authoritative name server is being used, check the NS records for all zones for which that hidden name server is authoritative and confirm there is not any NS record for that hidden name server. If any zone for which a hidden name server is authoritative has an NS record for that hidden name server, this is a finding. If the DNS implementation does not include any hidden name servers, this is not applicable.

The platform on which the name server software is hosted must be configured to respond to DNS traffic only.

Finding ID
SRG-APP-000516-DNS-000109
Rule ID
SV-69201r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000109
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

OS configuration practices as issued by the US Computer Emergency Response Team (US CERT) and the National Institute of Standards and Technology's (NIST's) National Vulnerability Database (NVD), based on identified vulnerabilities that pertain to the application profile into which the name server software fits, should be always followed. In particular, hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. In other words, the only allowed incoming ports/protocols to these hosts should be 53/udp and 53/tcp. Outgoing DNS messages should be sent from a random port to minimize the risk of an attacker's guessing the outgoing message port and sending forged replies.

Fix Text

Configure the DNS name server to only respond to incoming 53/udp and 53/tcp and any other ports and protocols required for the underlying platform to function normally, as specified by the related OS STIG.

Check Content

Review the name server configuration. Verify the server is configured to only respond to incoming 53/udp and 53/tcp and any other ports and protocols required for the underlying platform to function normally, as specified by the related OS STIG. If the DNS server is not configured to only respond to incoming 53/udp and 53/tcp and any other ports and protocols required for the underlying platform to function normally, as specified by the related OS STIG, this is a finding.

The platform on which the name server software is hosted must be configured to send outgoing DNS messages from a random port.

Finding ID
SRG-APP-000516-DNS-000110
Rule ID
SV-69203r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000110
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

OS configuration practices as issued by the US Computer Emergency Response Team (US CERT) and the National Institute of Standards and Technology's (NIST's) National Vulnerability Database (NVD), based on identified vulnerabilities that pertain to the application profile into which the name server software fits, should be always followed. In particular, hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. In other words, the only allowed incoming ports/protocols to these hosts should be 53/udp and 53/tcp. Outgoing DNS messages should be sent from a random port to minimize the risk of an attacker guessing the outgoing message port and sending forged replies.

Fix Text

Configure the DNS server to use a random port for outgoing DNS messages.

Check Content

Review the DNS configuration. Determine if a static port is being used to send outgoing DNS messages or whether it is configured to use a random port. If the DNS configuration specifies a static port to be used for outgoing DNS messages rather than a random port, this is a finding.

The private key corresponding to the ZSK, stored on name servers accepting dynamic updates, must have appropriate directory/file-level access control list-based or cryptography-based protections.

Finding ID
SRG-APP-000516-DNS-000111
Rule ID
SV-69205r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000111
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.

Fix Text

Apply permissions to the private key corresponding to the ZSK alone with read/modify permissions for the account under which the name server software is run.

Check Content

Review the DNS name server and documentation to determine whether it accepts dynamic updates. If dynamic updates are accepted, ensure the private key corresponding to the ZSK alone is protected with directory/file-level access control list-based or cryptography-based protections. If the private key corresponding to the ZSK alone is not protected with directory/file-level access control list-based or cryptography-based protections, this is a finding.

The private keys corresponding to both the ZSK and the KSK must not be kept on the DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates.

Finding ID
SRG-APP-000516-DNS-000112
Rule ID
SV-69207r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000112
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.

Fix Text

Store the private keys of the ZSK and KSK off-line in an encrypted file system.

Check Content

Review the DNS name server and documentation to determine whether it accepts dynamic updates. If dynamic updates are not accepted, verify the private keys corresponding to both the ZSK (Zone Signing Key) and KSK (Key Signing Key) are not located on the name server. If the private keys to the ZSK and/or the KSK are located on the name server, this is a finding.

A zone file must not include resource records that resolve to a fully qualified domain name residing in another zone.

Finding ID
SRG-APP-000516-DNS-000113
Rule ID
SV-69209r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000113
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that server's zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone. The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated.

Fix Text

Remove any resource records in a zone file if the resource record resolves to a fully qualified domain name residing in another zone.

Check Content

Review the zone files and confirm with the DNS administrator that the hosts defined in the zone files do not resolve to hosts in another zone with its fully qualified domain name. The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated. If resource records are maintained that resolve to a fully qualified domain name in another zone, and the usage is not for resource records resolving to hosts that are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with a documented and approved mission need, this is a finding.

CNAME records must not point to a zone with lesser security for more than six months.

Finding ID
SRG-APP-000516-DNS-000114
Rule ID
SV-69211r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000114
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The use of CNAME records for exercises, tests, or zone-spanning aliases should be temporary (e.g., to facilitate a migration). When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.

Fix Text

Remove any zone-spanning CNAME records that have been active for more than six months.

Check Content

Review the DNS server's hosted zones and respective records. Within the zone statement will be a file option that will display the name of the zone file. The record type column will display CNAME. This is usually the third or fourth field in a record depending on whether the TTL value is utilized. Without a TTL value, the CNAME type will be in the third field; otherwise, it will display as the fourth field. Review the zone files and the DNS zone record documentation to confirm that there are no CNAME records older than 6 months. The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement). If there are zone-spanning CNAME records older than 6 months and the CNAME records resolves to anything other than fully qualified domain name for glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with a AO-approved and documented mission need, this is a finding.

All authoritative name servers for a zone must be geographically disbursed.

Finding ID
SRG-APP-000218-DNS-000027
Rule ID
SV-69213r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000218-DNS-000027
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

In addition to network-based dispersion, authoritative name servers should be dispersed geographically as well. In other words, in addition to being located on different network segments, the authoritative name servers should not all be located within the same building. One approach that some organizations follow is to locate some authoritative name servers in their own premises and others in their ISPs' data centers or in partnering organizations. A network administrator may choose to use a "hidden" master authoritative server and only have secondary servers visible on the network. A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the master authoritative name server is "hidden", a secondary authoritative name server may reside in the same building as the hidden master.

Fix Text

Physically move name servers so that they are geographically at different locations. If moving a name server is not feasible, one of the co-located name servers could be reconfigured to be hidden.

Check Content

Review the NS records for each zone hosted and confirm that each authoritative name server is located at a different physical location than the remaining name servers. If the master, or primary, authoritative name server is configured to be "hidden", it will not have an NS record. One other name server may be at the same physical location as the hidden name server. If all name servers, for which NS records are listed, are not physically at different locations, this is a finding.

The DNS server implementation must, when a component failure is detected, activate a notification to the system administrator.

Finding ID
SRG-APP-000268-DNS-000039
Rule ID
SV-69215r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000268-DNS-000039
CCI
CCI-001328
Target Key
(None)
Documentable
No
Discussion

Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining systems security fail to function, the system could continue operating in an insecure state. The organization must be prepared and the application must support requirements that specify if the application must alarm for such conditions and/or automatically shut down the application or the system. This can include conducting a graceful application shutdown to avoid losing information. Automatic or manual transfer of components from standby to active mode can occur, for example, upon detection of component failures. If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.

Fix Text

Configure the DNS server so that when a component failure is detected, the server activates a notification to the system administrator.

Check Content

Review the DNS server implementation configuration to determine if the DNS server activates a notification to the system administrator when a component failure is detected. If the DNS server does not activate a notification to the system administrator when a failure is detected, this is a finding.

The DNS server implementation must strongly bind the identity of the DNS server with the DNS information.

Finding ID
SRG-APP-000347-DNS-000041
Rule ID
SV-69217r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000347-DNS-000041
CCI
CCI-001901
Target Key
(None)
Documentable
No
Discussion

Weakly bound credentials can be modified without invalidating the credential; therefore, non-repudiation can be violated. This requirement supports audit requirements that provide organizational personnel with the means to identify who produced specific information in the event of an information transfer. Organizations and/or data owners determine and approve the strength of the binding between the information producer and the information based on the security category of the information and relevant risk factors. DNSSEC and TSIG/SIG(0) both use digital signatures to establish the identity of the producer of particular pieces of information.

Fix Text

Configure the DNS server to strongly bind the identity of the DNS server with the DNS information.

Check Content

Review the DNS server implementation configuration to determine if the DNS server strongly binds the identity of the DNS server with the DNS information. Examples include enabling DNSSEC and enabling TSIG or SIG(0). If the DNS server does not strongly bind the identity of the DNS server with the DNS information, this is a finding.

The DNS server implementation must provide the means for authorized individuals to determine the identity of the source of the DNS server-provided information.

Finding ID
SRG-APP-000348-DNS-000042
Rule ID
SV-69219r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000348-DNS-000042
CCI
CCI-001902
Target Key
(None)
Documentable
No
Discussion

Without a means for identifying the individual that produced the information, the information cannot be relied upon. Identifying the validity of information may be delayed or deterred. This requirement provides organizational personnel with the means to identify who produced specific information in the event of an information transfer. DNSSEC and TSIG/SIG(0) both use digital signatures to establish the identity of the producer of particular pieces of information. These signatures can be examined and verified to determine the identity of the producer of the information.

Fix Text

Configure the DNS server to provide the means for authorized individuals to determine the identity of the source of the DNS server-provided information.

Check Content

Review the DNS server implementation configuration to determine if the DNS server provides the means for authorized individuals to determine the identity of the source of the DNS server-provided information. If the DNS server does not provide such means, this is a finding.

The DNS server implementation must validate the binding of the other DNS servers identity to the DNS information for a server-to-server transaction (e.g., zone transfer).

Finding ID
SRG-APP-000349-DNS-000043
Rule ID
SV-69221r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000349-DNS-000043
CCI
CCI-001904
Target Key
(None)
Documentable
No
Discussion

Validation of the binding of the information prevents the modification of information between production and review. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. Validations must be performed automatically. DNSSEC and TSIG/SIG(0) technologies are not effective unless the digital signatures they generate are validated to ensure that the information has not been tampered with and that the producer's identity is legitimate.

Fix Text

Configure the DNS server to validate the binding of the other DNS server's identity to the DNS information for a server-to-server transaction (e.g., zone transfer).

Check Content

Review the DNS server implementation configuration to determine if the DNS server validates the binding of the other DNS server's identity to the DNS information for a server-to-server transaction (e.g., zone transfer). If the DNS server does not validate the binding of the other DNS server's identity to the DNS information, this is a finding.

In the event of an error when validating the binding of another DNS servers identity to the DNS information, the DNS server implementation must log the event and send notification to the DNS administrator.

Finding ID
SRG-APP-000350-DNS-000044
Rule ID
SV-69223r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000350-DNS-000044
CCI
CCI-001906
Target Key
(None)
Documentable
No
Discussion

Failing to act on the validation errors may result in the use of invalid, corrupted, or compromised information. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. Validations must be performed automatically. At a minimum, the application must log the validation error. However, more stringent actions can be taken based on the security posture and value of the information. The organization should consider the system's environment and impact of the errors when defining the actions. Additional examples of actions include automated notification to administrators, halting system process, or halting the specific operation. The DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG/SIG(0). The actual auditing is performed by the OS/NDM but the configuration to trigger the auditing is controlled by the DNS server.

Fix Text

Configure the DNS server to log the event and send notification to the DNS administrator in the event an error occurs when validating the binding of another DNS server's identity to the DNS information.

Check Content

Review the DNS server implementation configuration to determine if the DNS server, when it encounters an event or an error when validating the binding of another DNS server's identity to the DNS information, is configured to log the event and send notification to the DNS administrator. If the DNS server does not log the event and send notification to the DNS administrator in the event of such a validation error, this is a finding.

Digital signature algorithm used for DNSSEC-enabled zones must be FIPS-compatible.

Finding ID
SRG-APP-000516-DNS-000090
Rule ID
SV-69225r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000090
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: * Digital Signature Algorithm (DSA) * RSA * Elliptic Curve DSA (ECDSA). Of these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. Hence, RSA is the recommended algorithm as far as this guideline is concerned. RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm. NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in NIST's DSS[FIPS186]. It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.

Fix Text

Regenerate signatures for all DNSSEC-enabled zones with FIPS-compatible algorithms.

Check Content

Review the DNS implementation and documentation. Confirm the signature algorithm used for DNSSEC-enabled zones is FIPS-compatible. If the signature algorithm used for DNSSEC-enabled zones is not FIPS-compatible, this is a finding.

The DNS server implementation must produce audit records containing information to establish when (date and time) the events occurred.

Finding ID
SRG-APP-000096-DNS-000007
Rule ID
SV-69471r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000096-DNS-000007
CCI
CCI-000131
Target Key
(None)
Documentable
No
Discussion

Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. Associating event types with detected events in the application and audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know when events occurred (date and time).

Fix Text

Configure the DNS server to produce log records that contain information that establishes when (date and time) events have occurred on the system. Additionally, configure the audit facility of the DNS system to provide information when events have occurred.

Check Content

Review the DNS system configuration to determine if it is configured to produce, capture, and store log records that contain information to establish when (date and time) events have occurred on the system. If the logging function is not configured to produce log records with information regarding when the event took place, this is a finding.

The DNS server implementation must utilize cryptographic mechanisms to prevent unauthorized modification of DNS zone data.

Finding ID
SRG-APP-000428-DNS-000061
Rule ID
SV-69473r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000428-DNS-000061
CCI
CCI-002475
Target Key
(None)
Documentable
No
Discussion

Applications handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). The DNS server must protect the integrity of keys (for TSIG/SIG(0) and DNSSEC) and DNS information.

Fix Text

Configure the DNS server to utilize cryptographic mechanisms to prevent unauthorized modification of zone data.

Check Content

Review the DNS server implementation configuration to determine if the DNS server utilizes cryptographic mechanisms to prevent unauthorized modification of zone data. If the DNS server does not utilize cryptographic mechanisms to prevent unauthorized modification, this is a finding.

The DNS server implementation must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.

Finding ID
SRG-APP-000516-DNS-000500
Rule ID
SV-69475r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000500
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the application, including the parameters required to satisfy other security control requirements. Configuring the DNS server implementation to follow organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements.

Fix Text

Configure the DNS server to be in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.

Check Content

Review the DNS server implementation configuration to determine if the DNS server is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If the DNS server is not configured in accordance with these settings, this is a finding.