| V-272364 | | A BIND 9.x primary 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 us... |
| V-272365 | | The BIND 9.x secondary name server must limit the number of zones requested from a single primary 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 us... |
| V-272366 | | 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 us... |
| V-272367 | | The BIND 9.x server implementation must limit the number of concurrent session client connections. | 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-272368 | | 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-272369 | | 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-272370 | | 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-272371 | | 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-272372 | | The BIND 9.x server private key corresponding to the zone-signing key (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 offline (with respect to... |
| V-272373 | | The BIND 9.x server signature generation using the key signing key (KSK) must be done offline, using the KSK-private key stored offline. | The private key in the KSK key pair must be protected from unauthorized access. The private key must be stored offline (with respect to the internet-f... |
| V-272375 | | 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-272376 | | A unique TSIG key used by a BIND 9.x server must be generated for each pair of communicating hosts. | 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-272377 | | 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-272378 | | 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-272379 | | 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-272380 | | 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-272381 | | 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-272382 | | A BIND 9.x implementation operating in a split DNS configuration must be approved by the organization's authorizing official (AO). | 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... |
| V-272383 | | On the BIND 9.x server the IP address for hidden primary authoritative name servers must not appear in the name servers set in the zone database. | A hidden primary authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. All of the na... |
| V-272384 | | 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-272385 | | On the BIND 9.x server, the private keys corresponding to both the zone signing key (ZSK) and the key signing key (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 offline (with... |
| V-272386 | | The two files generated by the BIND 9.x server dnssec-keygen program must be owned by the administrator account or deleted once 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-272387 | | The two files generated by the BIND 9.x server dnssec-keygen program must be group owned by the server administrator account or deleted once 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-272388 | | 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-272389 | | 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-272390 | | On the BIND 9.x server, the private key corresponding to the zone signing key (ZSK), stored on name servers accepting dynamic updates, must be owned by named. | The private keys in the key signing key (KSK) and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be st... |
| V-272391 | | On the BIND 9.x server, the private key corresponding to the zone signing key (ZSK), stored on name servers accepting dynamic updates, must be group owned by named. | The private keys in the key signing key (KSK) and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be st... |
| V-272392 | | 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-272393 | | 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-272394 | | 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-272395 | | The primary 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-272396 | | 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-272397 | | 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 server's cache by sending queries that will cause the server to obtain host-to-... |
| V-272399 | | The 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-272400 | | 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-272401 | | 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-272402 | | 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. | OS configuration practices as issued by the U.S. Computer Emergency Response Team (US CERT) and the National Institute of Standards and Technology's (... |
| V-272403 | | 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, security vulnerabilities in BIND are ident... |
| V-272404 | | The host running a BIND 9.x implementation must use a dedicated management interface 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 OOB network. The biggest... |
| V-272405 | | 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-272406 | | 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 must not provide any other services. Unnecessary services running on the DNS server can introduce additional a... |
| V-272407 | | 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-272408 | | 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-272410 | | 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-272411 | | 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-272412 | | 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-272413 | | The BIND 9.x name 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-272414 | | The BIND 9.x implementation must not use a TSIG or DNSSEC key for more than one year. | Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-rel... |
| V-272415 | | The permissions assigned to the core BIND 9.x server files must be set to use 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-272416 | | 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-272418 | | 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-272419 | | The BIND 9.x server implementation must be configured to use only approved ports and protocols. | To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within d... |
| V-272421 | | The BIND 9.x server implementation must use separate TSIG key-pairs when securing server-to-server transactions. | Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-ser... |
| V-272422 | | 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-272423 | | 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 server's name cache or take advantage of other vulnerabilities that ma... |
| V-272424 | | 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-272425 | | A BIND 9.x server must provide secure delegation to all 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-272426 | | 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-272427 | | 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-272428 | | 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-272429 | | 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-272430 | | The BIND 9.x server implementation must maintain at least three 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-272431 | | 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-272433 | | 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-272436 | | A BIND 9.x server must implement NIST FIPS-validated cryptography for provisioning digital signatures and generating cryptographic hashes. | Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The application must implement cryptographi... |
| V-275935 | | The BIND 9.x server implementation must have QNAME minimization set to "strict". | QNAME minimization limits the amount of information sent in DNS queries to intermediate nameservers, improving privacy by reducing the potential for D... |
| V-275936 | | The BIND 9.x server implementation must have fetches-per-zone enabled. | The fetches-per-zone option in BIND 9.x is a configuration parameter that controls the maximum number of simultaneous iterative queries a recursive re... |
| V-275937 | | The BIND 9.x server implementation must have fetches-per-server enabled. | The fetches-per-server option in BIND 9.x configures a limit on the number of outstanding requests (fetches) allowed for a single DNS server. This rat... |
| V-275938 | | The host running a BIND 9.x implementation must have DNS cookies enabled. | DNS cookies can help prevent spoofing and cache poisoning attacks by verifying the identity of both the client and server. They do this by including a... |
| V-275939 | | The BIND 9.x server implementation must limit 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-272417 | | 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 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-272432 | | The BIND 9.x server implementation must be configured with a channel to send audit records to at least two remote syslogs. | 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-272435 | | 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... |
