| V-207534 | | The platform on which the name server software is hosted must only run processes and services needed to support the BIND 9.x implementation. | Hosts that run the name server software should not provide any other services. Unnecessary services running on the DNS server can introduce additional... |
| V-207535 | | The BIND 9.x server software must run with restricted privileges. | Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall securi... |
| V-207536 | | The host running a BIND 9.X implementation must implement a set of firewall rules that restrict traffic on the DNS interface. | Configuring hosts that run a BIND 9.X implementation to only accept DNS traffic on a DNS interface allows a system firewall to be configured to limit ... |
| V-207537 | | The host running a BIND 9.x implementation must use a dedicated management interface in order to separate management traffic from DNS specific traffic. | Providing Out-Of-Band (OOB) management is the best first step in any management strategy. No production traffic resides on an out-of-band network. The... |
| V-207538 | | The host running a BIND 9.x implementation must use an interface that is configured to process only DNS traffic. | Configuring hosts that run a BIND 9.X implementation to only accept DNS traffic on a DNS interface allows a system to be configured to segregate DNS t... |
| V-207549 | | The BIND 9.x secondary name server must limit the number of zones requested from a single master name server. | Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.
Name servers do not have direct use... |
| V-207550 | | The BIND 9.x secondary name server must limit the total number of zones the name server can request at any one time. | Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.
Name servers do not have direct use... |
| V-207551 | | The BIND 9.x server implementation must limit the number of concurrent session client connections to the number of allowed dynamic update clients. | Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.
Name servers do not have direct us... |
| V-207552 | | The BIND 9.x server implementation must be configured to use only approved ports and protocols. | In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types... |
| V-207553 | | A BIND 9.x server implementation must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks. | 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... |
| V-207554 | | A BIND 9.x server implementation must prohibit recursion on authoritative name servers. | 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-... |
| V-207558 | | A BIND 9.x caching name server must implement DNSSEC validation to check all DNS queries for invalid input. | A common vulnerability of applications is unpredictable behavior when invalid inputs are received. This requirement guards against adverse or unintend... |
| V-207559 | | A BIND 9.x master name server must limit the number of concurrent zone transfers between authorized secondary name servers. | Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.
Name servers do not have direct use... |
| V-207560 | | A BIND 9.x implementation configured as a caching name server must restrict recursive queries to only the IP addresses and IP address ranges of known supported clients. | Any host that can query a resolving name server has the potential to poison the servers name cache or take advantage of other vulnerabilities that may... |
| V-207562 | | The BIND 9.x server implementation must utilize separate TSIG key-pairs when securing server-to-server transactions. | Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each ser... |
| V-207563 | | The TSIG keys used with the BIND 9.x implementation must be owned by a privileged account. | Incorrect ownership of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.... |
| V-207564 | | The TSIG keys used with the BIND 9.x implementation must be group owned by a privileged account. | Incorrect ownership of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.... |
| V-207565 | | The read and write access to a TSIG key file used by a BIND 9.x server must be restricted to only the account that runs the name server software. | Weak permissions of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.... |
| V-207566 | | The BIND 9.X implementation must not utilize a TSIG or DNSSEC key for more than one year. | Cryptographic keys are the backbone of securing DNS information over the wire, maintaining DNS data integrity, and the providing the ability to valida... |
| V-207568 | | The DNSSEC keys used with the BIND 9.x implementation must be owned by a privileged account. | Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. M... |
| V-207569 | | The DNSSEC keys used with the BIND 9.x implementation must be group owned by a privileged account. | Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. M... |
| V-207570 | | Permissions assigned to the DNSSEC keys used with the BIND 9.x implementation must enforce read-only access to the key owner and deny access to all other users. | Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. M... |
| V-207572 | | On the BIND 9.x server the private keys corresponding to both the ZSK and the KSK must not be kept on the BIND 9.x DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates. | 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 (wit... |
| V-207573 | | The two files generated by the BIND 9.x server dnssec-keygen program must be owned by the root account, or deleted, after they have been copied to the key file in the name server. | To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The... |
| V-207574 | | The two files generated by the BIND 9.x server dnssec-keygen program must be group owned by the server administrator account, or deleted, after they have been copied to the key file in the name server. | To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The... |
| V-207575 | | Permissions assigned to the dnssec-keygen keys used with the BIND 9.x implementation must enforce read-only access to the key owner and deny access to all other users. | To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The... |
| V-207578 | | A BIND 9.x server implementation must provide the means to indicate the security status of child zones. | If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the pres... |
| V-207579 | | The BIND 9.x server validity period for the RRSIGs covering the DS RR for zones delegated children must be no less than two days and no more than one week. | 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 p... |
| V-207580 | | The core BIND 9.x server files must be owned by the root or BIND 9.x process account. | Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should... |
| V-207581 | | The core BIND 9.x server files must be group owned by a group designated for DNS administration only. | Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should... |
| V-207582 | | The permissions assigned to the core BIND 9.x server files must be set to utilize the least privilege possible. | Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should... |
| V-207583 | | On a BIND 9.x server 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. | Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients.
External clients need to... |
| V-207584 | | On a BIND 9.x server 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. | Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authorit... |
| V-207585 | | On a BIND 9.x server 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. | Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authorit... |
| V-207587 | | On the BIND 9.x server the IP address for hidden master authoritative name servers must not appear in the name servers set in the zone database. | 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 nam... |
| V-207589 | | On the BIND 9.x server the private key corresponding to the ZSK, stored on name servers accepting dynamic updates, must be owned by root. | The private ZSK key must be protected from unauthorized access.
This strategy is not feasible in situations in which the DNSSEC-aware name server has... |
| V-207590 | | On the BIND 9.x server the private key corresponding to the ZSK, stored on name servers accepting dynamic updates, must be group owned by root. | The private ZSK key must be protected from unauthorized access.
This strategy is not feasible in situations in which the DNSSEC-aware name server has... |
| V-207591 | | A BIND 9.x server implementation must enforce approved authorizations for controlling the flow of information between authoritative name servers and specified secondary name servers based on DNSSEC policies. | A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is ... |
| V-207592 | | A BIND 9.x server validity period for the RRSIGs covering a zones DNSKEY RRSet must be no less than two days and no more than one week. | 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 p... |
| V-207593 | | A BIND 9.x server NSEC3 must be used for all internal DNS zones. | 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 mea... |
| V-207594 | | Every NS record in a zone file on a BIND 9.x server must point to an active name server and that name server must be authoritative for the domain specified in that record. | Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing author... |
| V-207595 | | On a BIND 9.x server all authoritative name servers for a zone must be located on different network segments. | Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative nam... |
| V-207596 | | On a BIND 9.x server all authoritative name servers for a zone must have the same version of zone information. | It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a chan... |
| V-207599 | | On the BIND 9.x server a zone file must not include resource records that resolve to a fully qualified domain name residing in another zone. | 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. I... |
| V-207601 | | The BIND 9.x server implementation must prohibit the forwarding of queries to servers controlled by organizations outside of the U.S. Government. | If remote servers to which DoD DNS servers send queries are controlled by entities outside of the U.S. Government the possibility of a DNS attack is i... |
| V-207532 | | A BIND 9.x server implementation must be running in a chroot(ed) directory structure. | With any network service, there is the potential that an attacker can exploit a vulnerability within the program that allows the attacker to gain cont... |
| V-207539 | | A BIND 9.x server implementation must be configured to allow DNS administrators to audit all DNS server components, based on selectable event criteria, and produce audit records within all DNS server components that contain information for failed security verification tests, information to establish the outcome and source of the events, any information necessary to determine cause of failure, and any information necessary to return to operations with least disruption to mission processes. | Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, o... |
| V-207540 | | The BIND 9.x server implementation must not be configured with a channel to send audit records to null. | DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. ... |
| V-207541 | | The BIND 9.x server logging configuration must be configured to generate audit records for all DoD-defined auditable events to a local file by enabling triggers for all events with a severity of info, notice, warning, error, and critical for all DNS components. | Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, o... |
| V-207542 | | In the event of an error when validating the binding of other DNS servers identity to the BIND 9.x information, when anomalies in the operation of the signed zone transfers are discovered, for the success and failure of start and stop of the name server service or daemon, and for the success and failure of all name server events, a BIND 9.x server implementation must generate a log entry. | Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the sy... |
| V-207543 | | The print-severity variable for the configuration of BIND 9.x server logs must be configured to produce audit records containing information to establish what type of events occurred. | Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the sy... |
| V-207544 | | The print-time variable for the configuration of BIND 9.x server logs must be configured to establish when (date and time) the events occurred. | Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident.
Associating... |
| V-207545 | | The print-category variable for the configuration of BIND 9.x server logs must be configured to record information indicating which process generated the events. | Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. Associating ... |
| V-207546 | | The BIND 9.x server implementation must be configured with a channel to send audit records to a remote syslog. | 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... |
| V-207547 | | The BIND 9.x server implementation must be configured with a channel to send audit records to a local file. | DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. ... |
| V-207548 | | The BIND 9.x server implementation must maintain at least 3 file versions of the local log file. | DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. ... |
| V-207555 | | The master servers in a BIND 9.x implementation must notify authorized secondary name servers when zone files are updated. | It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a chan... |
| V-207556 | | The secondary name servers in a BIND 9.x implementation must be configured to initiate zone update notifications to other authoritative zone name servers. | It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a chan... |
| V-207557 | | On the BIND 9.x server the platform on which the name server software is hosted must be configured to send outgoing DNS messages from a random port. | Hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. Outgo... |
| V-207597 | | On a BIND 9.x server all root name servers listed in the local root zone file hosted on a BIND 9.x authoritative name server must be valid for that zone. | All caching name servers must be authoritative for the root zone because, without this starting point, they would have no knowledge of the DNS infrast... |
| V-207598 | | On a BIND 9.x server all root name servers listed in the local root zone file hosted on a BIND 9.x authoritative name server must be empty or removed. | A potential vulnerability of DNS is that an attacker can poison a name servers cache by sending queries that will cause the server to obtain host-to-I... |
| V-207600 | | On the BIND 9.x server CNAME records must not point to a zone with lesser security for more than six months. | 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 ... |
| V-207533 | | A BIND 9.x server implementation must be operating on a Current-Stable version as defined by ISC. | The BIND STIG was written to incorporate capabilities and features provided in BIND version 9.9.x. However, it is recognized that security vulnerabili... |
| V-207561 | | The BIND 9.x server implementation must uniquely identify and authenticate the other DNS server before responding to a server-to-server transaction, zone transfer and/or dynamic update request using cryptographically based bidirectional authentication to protect the integrity of the information in transit. | Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each ser... |
| V-207567 | | A BIND 9.x server must implement NIST FIPS-validated cryptography for provisioning digital signatures and generating cryptographic hashes. | The use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryp... |
| V-207571 | | The BIND 9.x server private key corresponding to the ZSK pair must be the only DNSSEC key kept on a name server that supports dynamic updates. | The private key in the ZSK key pair must be protected from unauthorized access. If possible, the private key should be stored off-line (with respect t... |
| V-207576 | | The BIND 9.x server signature generation using the KSK must be done off-line, using the KSK-private key stored off-line. | The private key in the KSK key pair must be protected from unauthorized access. The private key should be stored off-line (with respect to the Interne... |
| V-207577 | | A BIND 9.x server implementation must maintain the integrity and confidentiality of DNS information while it is being prepared for transmission, in transmission, and in use and t must perform integrity verification and data origin verification for all DNS information. | DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through sig... |
| V-207586 | | A BIND 9.x server implementation must implement internal/external role separation. | DNS servers with an internal role only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers wit... |
| V-207588 | | A BIND 9.x implementation operating in a split DNS configuration must be approved by the organizations Authorizing Official. | BIND 9.x has implemented an option to use "view" statements to allow for split DNS architecture to be configured on a single name server.
If the spl... |
