| V-233867 | | The digital signature algorithm used for DNSSEC-enabled zones must be FIPS-compatible. | The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) (FI... |
| V-233879 | | The private keys corresponding to both the Zone Signing Key (ZSK) and the Key Signing Key (KSK) must not be kept on the DNSSEC-aware primary authoritative DNS service member when the DNS service member 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-233882 | | A secure out-of-band (OOB) network must be used for management of Infoblox Grid Members. | The Infoblox Grid Master is the central point of management within an Infoblox Grid. The Grid Master retains a full copy of the configuration used for... |
| V-233883 | | Infoblox systems must enforce current DoD password restrictions. | The Infoblox systems must be configured to meet current DoD password policy when using the Infoblox Local User Database as the authentication source.... |
| V-233903 | | The Infoblox Grid Master must be configured as a stealth (hidden) domain DNS service member to protect the Key Signing Key (KSK) residing on it. | The private keys in the KSK and Zone Signing Keys (ZSK) key pairs must be protected from unauthorized access. If possible, the private keys should be ... |
| V-233904 | | The Infoblox Grid Master must be configured as a stealth (hidden) domain DNS service member in order to protect the Zone Signing Key (ZSK) residing on it. | Security-relevant information is any information within information systems that can potentially impact the operation of security functions or the pro... |
| V-233906 | | The Infoblox DNS service member must implement NIST FIPS-validated cryptography for provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information requiring confidentiality. | Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The application must implement cryptographi... |
| V-233855 | | Infoblox systems that perform zone transfers to non-Grid DNS service members must limit the number of concurrent sessions for zone transfers. | Limiting the number of concurrent sessions reduces the risk of denial of service (DoS) to the DNS implementation.
Infoblox DNS servers configured i... |
| V-233856 | | The Infoblox system must limit the number of concurrent 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-233857 | | The Infoblox DNS service member must not reveal sensitive information to an attacker. This includes Host Information (HINFO), Responsible Person (RP), Location (LOC) resource, and sensitive text string resource (TXT) record data. | There are several types of resource records (RRs) in the DNS that are meant to convey information to humans and applications about the network, hosts,... |
| V-233858 | | The Infoblox system 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. | Protection of log data includes ensuring that log data is not accidentally lost or deleted. Backing up audit records to a different system or onto sep... |
| V-233859 | | All authoritative DNS service members for a zone must be geographically dispersed. | In addition to network-based dispersion, authoritative name servers must be also be dispersed geographically. In other words, in addition to being loc... |
| V-233860 | | Recursion must be disabled on Infoblox DNS service members that are configured as External Authoritative DNS service members. | External Authoritative DNS service members should *only* be providing External Authoritative and no other "DNS Service". Internal Authoritative server... |
| V-233861 | | The validity period for the Resource Record Signatures (RRSIGs) covering a zone's 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-233862 | | NSEC3 must be used for all DNSSEC signed zones. | To ensure that resource records (RRs) associated with a query are really missing in a zone file and have not been removed in transit, the DNSSEC mecha... |
| V-233863 | | The Infoblox DNS service member must be configured so that each DNS service member record in a zone file points to an active DNS service member 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-233864 | | All authoritative DNS service members 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-233865 | | All authoritative DNS service members for a zone must have the same version of zone information. | 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... |
| V-233866 | | An External authoritative DNS service member must be configured to enable DNSSEC resource records. | The specification for a digital signature mechanism in the context of the DNS infrastructure is in the Internet Engineering Task Force's (IETF's) DNSS... |
| V-233868 | | For zones split between the external and internal sides of a network, the resource records (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-233869 | | In a split DNS configuration, where separate DNS service members are used between the external and internal networks, the external DNS service member 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-233870 | | In a split DNS configuration, where separate DNS service members are used between the external and internal networks, the internal DNS service member 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-233871 | | Primary authoritative DNS service members must be configured to only receive zone transfer requests from specified secondary DNS service members. | Authoritative name servers (especially primary name servers) must be configured with an allow-transfer access control sub-statement designating the li... |
| V-233872 | | The Infoblox system must use a security policy that limits the propagation of access rights. | Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should... |
| V-233873 | | The DNS 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-233874 | | The Infoblox DNS service member must use current and valid root DNS service members. | 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-233875 | | The Infoblox NIOS version must be at the appropriate version. | Each newer version of the name server software, especially the BIND software, generally is devoid of vulnerabilities found in earlier versions because... |
| V-233876 | | The IP address for hidden master authoritative DNS service members must not appear in the DNS service members set in the zone database. | A hidden primary authoritative server is an authoritative DNS server in which the IP address does not appear in the name server set for a zone. All of... |
| V-233877 | | The Infoblox system must be configured to respond to DNS traffic only. | OS configuration practices as issued by the US Computer Emergency Response Team (US CERT) and the National Institute of Standards and Technology's (NI... |
| V-233878 | | The Infoblox DNS service member must 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-233880 | | 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-233881 | | The Infoblox system must use the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. | 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-233884 | | Infoblox Grid configuration must be backed up on a regular basis. | The Infoblox Grid Master is the central point of management within an Infoblox Grid. The Grid Master retains a full copy of the configuration used for... |
| V-233885 | | The Infoblox system must display the approved DoD notice and consent banner. | Configuration of the DoD notice and consent banner requires all administrators to acknowledge the current DoD notice and consent by clicking an "Accep... |
| V-233886 | | The Infoblox system must display the appropriate security classification information. | Configuration of the informational banner displays the security classification of the Infoblox system using both color and text. Text may be added for... |
| V-233887 | | The Infoblox system 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. | 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-233888 | | The Infoblox system must present only approved TLS and SSL cipher suites. | Infoblox systems ship with a wide range of cipher suites to support management in a variety of customer environments. Infoblox may have customers that... |
| V-233889 | | An Infoblox DNS service member must strongly bind the identity of the DNS service member with the DNS information using DNSSEC. | Weakly bound credentials can be modified without invalidating the credential; therefore, nonrepudiation can be violated.
This requirement supports au... |
| V-233890 | | The Infoblox system must provide the means for authorized individuals to determine the identity of the source of the DNS service member-provided information. | Without a means for identifying the individual who produced the information, the information cannot be relied on. Identifying the validity of informat... |
| V-233891 | | The Infoblox system must validate the binding of the other DNS service members' identity to the DNS information for a server-to-server transaction (e.g., zone transfer). | Validation of the binding of the information prevents the modification of information between production and review. The validation of bindings can be... |
| V-233892 | | The Infoblox system must send a notification in the event of an error when validating the binding of another DNS service member's identity to the DNS information. | Failing to act on validation errors may result in the use of invalid, corrupted, or compromised information. The validation of bindings can be achieve... |
| V-233893 | | The Infoblox DNS service member must provide data origin artifacts for internal name/address resolution queries. | 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 i... |
| V-233894 | | The Infoblox DNS service member must provide data integrity protection artifacts for internal name/address resolution queries. | 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 i... |
| V-233895 | | The Infoblox system must notify the system administrator when a component failure is detected. | Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining systems security fa... |
| V-233896 | | The Infoblox DNS service member implementation must follow procedures to promote a secondary DNS service member to the role of primary DNS service member in the event the current primary DNS service member permanently loses functionality. | Failing to an unsecure condition negatively impacts application security and can lead to system compromise. Failure conditions include, for example, l... |
| V-233897 | | The Infoblox system must prohibit or restrict unapproved services, 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-233898 | | The Infoblox system must require devices to reauthenticate for each zone transfer and dynamic update request connection attempt. | Without reauthenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.
In addition to the reau... |
| V-233899 | | When using third-party DNS servers for zone transfers, each DNS server must use TSIG to uniquely identify the other server. | Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-ser... |
| V-233900 | | The Infoblox DNS service member must authenticate to any external (non-Grid) DNS service members before responding to a server-to-server transaction. | Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Device authentication is a... |
| V-233901 | | The Infoblox DNS service member must authenticate another DNS service member before establishing a remote and/or network connection using bidirectional authentication that is cryptographically based. | Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authenticati... |
| V-233902 | | Infoblox systems that communicate with non-Grid DNS service members must use a unique Transaction Signature (TSIG). | 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-233905 | | The Infoblox system must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions. | If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing s... |
| V-233907 | | The Infoblox system must provide additional data origin artifacts along with the authoritative data the system returns in response to external name/address resolution queries. | 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... |
| V-233908 | | The Infoblox DNS service member must provide additional integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries. | 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 i... |
| V-233909 | | The Infoblox DNS service member 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-233910 | | The validity period for the Resource Record Signatures (RRSIGs) covering the Delegation Signer (DS) RR for a zone's 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-233911 | | The Infoblox DNS service member implementation must enforce approved authorizations for controlling the flow of information between DNS service members and between DNS service members and DNS clients based on TSIG 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-233912 | | The Infoblox DNS service member must enable verification of a chain of trust among parent and child domains (if the child supports secure resolution services). | If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the pres... |
| V-233913 | | The Infoblox DNS service member must request data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources. | If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poiso... |
| V-233917 | | Infoblox DNS service members must protect the authenticity of communications sessions for zone transfers when communicating with external DNS service members (i.e., DNS systems outside the Infoblox grid). | DNS is a fundamental network service prone to various attacks, such as cache poisoning and man-in-the middle attacks.
Communication sessions between... |
| V-233918 | | Infoblox DNS service members must protect the authenticity of communications sessions for dynamic updates. | DNS is a fundamental network service prone to various attacks, such as cache poisoning and man-in-the middle attacks.
Communication sessions between... |
| V-233919 | | Infoblox DNS service members must protect the authenticity of communications sessions for queries. | 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... |
| V-233920 | | In the event of a system failure, the Infoblox system must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes. | Failure to a known state can address safety or security in accordance with the mission/business needs of the organization.
Preserving application st... |
| V-233921 | | The Infoblox system must restrict the ability of individuals to use the DNS service member to launch denial-of-Service (DoS) attacks against other information systems. | The Infoblox system must restrict the ability of individuals to use the DNS server to launch DoS attacks against other information systems.... |
| V-233922 | | The Infoblox system 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-233923 | | The Infoblox DNS service member must protect the integrity of transmitted information. | Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepte... |
| V-233924 | | The Infoblox DNS service member 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). | Encrypting information for transmission protects it from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect inf... |
| V-233925 | | The Infoblox DNS service member implementation must maintain the integrity of information during preparation for transmission. | Information can be unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregatio... |
| V-233926 | | The Infoblox DNS service member implementation must maintain the integrity of information during reception. | Information can be unintentionally or maliciously disclosed or modified during reception, including, for example, during aggregation, at protocol tran... |
| V-233927 | | The Infoblox system must notify the ISSO and ISSM in the event of failed security verification tests. | Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy... |
| V-233928 | | The Infoblox DNS service member implementation must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered. | Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy... |
