What changed in Domain Name System (DNS) Security Requirements Guide V4R3V4R3 changes

Check text

Review the DNS server configuration and ensure a limit has been defined for the number of outbound zone transfers toand onlythat betransfers allowedare restricted to the specified secondary name servers. If the DNS server configuration does not explicitly specify whichthe target hosts tofor which it sends zone transfers, this is a finding.

Fix text

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

Discussion

Limiting the number of concurrent sessions reduces the risk of Denialdenial of Serviceservice (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 serviceDoS, 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.

CCIs

CCI-00100954

V-205157 in V4R3

CCIs

CCI-00100954

V-205158 in V4R3

Title

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

Check text

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.

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.

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

V-205160 in V4R3

Title

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

Check text

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

Fix text

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

Discussion

Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoDDoW systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoDDoW-approved CA, trust of this CA has not been established. The DoDDoW will only accept PKI certificates obtained from a DoDDoW-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.

V-205213 in V4R3

Title

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

Check text

Review the DNS server implementation configuration to determine if the DNS server is configured in accordance with the security configuration settings based on DoDDoW 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.

Fix text

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

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 DoDDoW that reflects the most restrictive security posture consistent with operational requirements.

V-205253 in V4R3

Discussion

Any DNS implementation must be designed to be able to conform to the Internet Engineering Task Force (IETF) specification. DoDDoW 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.

V-279958 in V4R3

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 DoDDoW, 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.

V-279965 in V4R3