STIG VIEWER

Infoblox 8.x DNS Security Technical Implementation Guide

Overview

Version Date Finding Count (74) Downloads
1 2021-01-11 CAT I (High): 7 CAT II (Medium): 67 CAT III (Low): 0 Excel JSON XML
Stig Description
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
Classified Public Sensitive  
I - Mission Critical Classified I - Mission Critical Public I - Mission Critical Sensitive II - Mission Critical Classified II - Mission Critical Public II - Mission Critical Sensitive III - Mission Critical Classified III - Mission Critical Public III - Mission Critical Sensitive

Findings - All

Finding ID Severity Title Description
V-233906 High The Infoblox DNS server 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 cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
V-233904 High The Infoblox Grid Master must be configured as a stealth (hidden) domain name server 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 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...
V-233903 High The Infoblox Grid Master must be configured as a stealth (hidden) domain name server in order to protect the Key Signing Key (KSK) residing on it. 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 stored offline (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...
V-233883 High 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-233882 High 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 the entire Grid. The Grid Master must communicate to Grid Members using their Management port connected to an OOB network that clients cannot access.
V-233879 High 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 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 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...
V-233867 High 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) (FIPS 186) 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...
V-233928 Medium The Infoblox DNS server 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 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.,...
V-233927 Medium 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 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.,...
V-233926 Medium The Infoblox DNS server 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 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...
V-233925 Medium The Infoblox DNS server 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 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...
V-233924 Medium The Infoblox DNS server 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 information integrity include, for example, cryptographic hash functions that have common application in digital signatures, checksums, and message authentication codes. Confidentiality is not an objective of DNS, but integrity is. DNSSEC digitally signs DNS...
V-233923 Medium The Infoblox DNS server must protect the integrity of transmitted information. 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...
V-233922 Medium 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 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...
V-233921 Medium The Infoblox system must restrict the ability of individuals to use the DNS server 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-233920 Medium 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 state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes.
V-233919 Medium Infoblox DNS servers 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 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...
V-233918 Medium Infoblox DNS servers must protect the authenticity of communications sessions for dynamic updates. DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. Communication sessions between different DNS clients and servers should employ protections such as DNSSEC or TSIG to validate the integrity of data being transmitted.
V-233917 Medium Infoblox DNS servers must protect the authenticity of communications sessions for zone transfers when communicating with external DNS servers. DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. Communication sessions between different DNS systems should employ protections such as DNSSEC or TSIG to validate the integrity of data being transmitted.
V-233916 Medium The Infoblox DNS server must perform data origin verification authentication 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 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...
V-233915 Medium The Infoblox DNS server must perform 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 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...
V-233914 Medium The Infoblox DNS server must request 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 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...
V-233913 Medium The Infoblox DNS server must request data origin authentication 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 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...
V-233912 Medium The Infoblox DNS server 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 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...
V-233911 Medium The Infoblox 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. 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...
V-233910 Medium 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 parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses....
V-233909 Medium The Infoblox DNS 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 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 Domain Name System...
V-233908 Medium The Infoblox DNS Server 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 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...
V-233907 Medium 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 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...
V-233905 Medium 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 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...
V-233902 Medium Infoblox systems that communicate with non-Grid name servers 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 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...
V-233901 Medium The Infoblox DNS server must authenticate another DNS server 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 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, which enforces mutual...
V-233900 Medium The Infoblox DNS server must authenticate to any external (non-Grid) DNS servers 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 solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific preauthorized devices can access the system. This requirement applies to server-to-server (zone transfer) transactions only...
V-233899 Medium When using non-Grid DNS servers for zone transfers, each name 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-server (zone transfer) transactions only and is provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server.
V-233898 Medium 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 reauthentication requirements associated with session locks, organizations may require reauthentication of devices, including but not limited to the following other situations: (i) When authenticators change; (ii) When roles change; (iii) When security...
V-233897 Medium 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 data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Infoblox systems provide DNS, Dynamic Host Configuration Protocol (DHCP), and IP Address Management (DDI)...
V-233896 Medium The Infoblox 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. 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...
V-233895 Medium 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 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...
V-233894 Medium The Infoblox DNS server 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 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...
V-233893 Medium The Infoblox DNS server 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 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...
V-233892 Medium The Infoblox system must send a notification in the event of an error when validating the binding of another DNS server’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 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...
V-233891 Medium The Infoblox system must validate the binding of the other DNS servers' 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 achieved, for example, by the use of cryptographic checksums. Validations must be performed automatically. DNSSEC is not effective unless the digital signatures they generate are validated to ensure...
V-233890 Medium The Infoblox system must provide the means for authorized individuals to determine the identity of the source of the DNS server-provided information. Without a means for identifying the individual who produced the information, the information cannot be relied on. 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 uses...
V-233889 Medium An Infoblox DNS server must strongly bind the identity of the DNS server with the DNS information using DNSSEC. 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...
V-233888 Medium 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 require these cipher suites for backward compatibility. Over time specific cipher suites may become unfavorable for a variety of reasons, including being replaced by stronger suites,...
V-233887 Medium 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-related parameters are 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...
V-233886 Medium 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 additional security markings.
V-233885 Medium 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 "Accept" button.
V-233884 Medium 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 the entire Grid. In the event of system failure, a configuration backup must be preserved. An Infoblox Grid member may also be configured as...
V-233881 Medium 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-related parameters are 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...
V-233880 Medium 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 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...
V-233878 Medium The Infoblox DNS server must send outgoing DNS messages from a random port. 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,...
V-233877 Medium 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 (NIST's) National Vulnerability Database (NVD), based on identified vulnerabilities that pertain to the application profile into which the name server software fits, should always be followed. In particular,...
V-233876 Medium 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 in which the 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...
V-233875 Medium 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 it has design changes incorporated to address those vulnerabilities. These vulnerabilities have been exploited (i.e., some form of attack was launched), and sufficient information has been generated with...
V-233874 Medium The Infoblox DNS server must use current and valid root name servers. 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. An adversary could change the root hints and direct the caching name server to a...
V-233873 Medium 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 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...
V-233872 Medium 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 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...
V-233871 Medium Primary authoritative name servers must be configured to only receive zone transfer requests from specified secondary name servers. Authoritative name servers (especially primary name servers) should be configured with an allow-transfer access control sub-statement 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,...
V-233870 Medium 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 authoritative name servers. One set, called external name servers, can be located within a DMZ; these would be the only name servers accessible to external clients and...
V-233869 Medium 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 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...
V-233868 Medium 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 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...
V-233866 Medium An authoritative name server 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) 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...
V-233865 Medium All authoritative name servers 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 using a zone file integrity checker depends on the database of constraints built into the checker. The deployment process consists of developing these constraints with...
V-233864 Medium 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 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...
V-233863 Medium The Infoblox DNS server must be configured so that each name server (NS) record in a zone file points to an active name server 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 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...
V-233862 Medium 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 mechanism provides a means for authenticating the nonexistence of an RR. It generates a special RR called an NSEC (or NSEC3) RR that lists...
V-233861 Medium 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 parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses....
V-233860 Medium Recursion must be disabled on Infoblox DNS servers that are configured as 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-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...
V-233859 Medium All authoritative name servers for a zone must be geographically disbursed. 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...
V-233858 Medium 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 separate media than the system being audited on a defined frequency helps to ensure that, in the event of a catastrophic system failure, the audit...
V-233857 Medium The Infoblox DNS server must not reveal sensitive information to an attacker. This includes HINFO, RP, LOC resource, and sensitive 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, or services. These include the Responsible Person (RP) record, the Host Information (HINFO) record, the Location (LOC) record, and the catch-all text string resource record...
V-233856 Medium 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 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...
V-233855 Medium Infoblox systems that perform zone transfers to non-Grid DNS servers 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 in a Grid do not use zone transfers. Data is replicated using an encrypted management connection. However, when a zone contains both Infoblox Grid DNS servers and non-Grid DNS servers,...