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.
Overview
| Finding ID | Version | Rule ID | IA Controls | Severity |
| V-233922 | IDNS-8X-700017 | SV-233922r1082735_rule | CCI-001095 | medium |
| Description | ||||
| 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 the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time. A DoS attack against the DNS infrastructure has the potential to cause a DoS to all network users. As the DNS is a distributed backbone service of the internet, various forms of amplification attacks resulting in DoS, while using the DNS, are still prevalent on the internet today. Some potential DoS flooding attacks against the DNS include malformed packet flood, spoofed source addresses, and distributed DoS. Without the DNS, users and systems would not have the ability to perform simple name-to-IP resolution. Configuring the DNS implementation to defend against cache poisoning, employing increased capacity and bandwidth, building redundancy into the DNS architecture, using DNSSEC, and limiting and securing recursive services, DNS black holes, etc., may reduce the susceptibility to some flooding types of DoS attacks. | ||||
| STIG | Date | |||
| Infoblox 8.x DNS Security Technical Implementation Guide | 2026-06-03 | |||
Related Frameworks
1 mapping across 4 frameworks
Related Frameworks
SCF0 mappings
No source states a mapping between these directly.
Also reachable in 3 hops (2) derived by us, not asserted by any source
Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- SCF Secure Traceability Relationship Mapping (STRM)2026.2intersects
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- SCF Secure Traceability Relationship Mapping (STRM)2026.2intersects
NIST 800-530 mappings
No source states a mapping between these directly.
Also reachable in 2 hops (13) derived by us, not asserted by any source
Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)V1R1our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)V1R1intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)2our copyintersects(normalised)DISA STIG Benchmark (XCCDF)V2R9our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)2intersects(normalised)DISA STIG Benchmark (XCCDF)V2R9intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)V1R1our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)V1R1intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)V10R7our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)V10R7intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)V1R1our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)V1R1intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)V3R3our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)V3R3intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)1our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)1intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)1our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)1intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)V2R1our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)V2R1intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA STIG Benchmark (XCCDF)V10R7our copyintersects(normalised)
- DISA STIG Benchmark (XCCDF)V10R7intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
+3 more (top 10 by confidence shown)
CCI1 mapping
CCI-001095
1.00
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
NIST CSF 2.00 mappings
No source states a mapping between these directly.
Also reachable in 4 hops (1) derived by us, not asserted by any source
Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.
PR.IR-04
0.50
- DISA STIG Benchmark (XCCDF)V1R3intersects(normalised)
- DISA CCI List2025-01-23equal to(normalised)
- SCF Secure Traceability Relationship Mapping (STRM)2026.2intersects
- NIST OLIR Informative ReferenceOLIR 153 (2025-04-07)intersects(normalised)SCF Focal Document mapping (catalog)SCF 2026.2 focalintersects(normalised)
Details
Check Text (C-233922r1082735_chk)
Infoblox systems have a number of options that can be configured to reduce the ability to be exploited in a DoS attack. Use of rate limiting can reduce risk from cache poisoning attacks and DoS attacks.
1. Log on to the Infoblox system CLI and issue the following commands:
"show ip_rate_limit" and "show dns_rrl"
2. Review the output from these commands with the network architecture.
3. If the system uses the Advanced DNS Protection (ADP) (Threat Protection) feature, IP rate limiting is implemented using the DNS security rule-set available in the web GUI.
If the ADP feature set is implemented, use of the ip_rate_limit and dns_rrl CLI commands is not required, and this check is Not Applicable. Refer to the Infoblox Admin Guide for additional details if needed.
If rate limiting is not configured on the Infoblox system or within the network security architecture protecting the Infoblox system, this is a finding.
Fix Text (F-37072r1082734_fix)
Prior to implementation, review the Infoblox CLI Guide and verify all configuration options.
1. Log on to the Infoblox system using the CLI.
2. Use "set ip_rate_limit [OPTIONS}" to reduce risk of cache poisoning attacks by rate limiting udp/53 traffic.
3. Use "set dns_rrl [OPTIONS]" to enable DNS response rate limiting.
4. Upon completion, log out of the CLI.
Note: Gathering baseline statistics must be done before deciding on appropriate parameters. This helps ensure that the chosen settings are optimal for your specific environment and requirements.
This helps reduce the risk of DoS attacks by reducing the rate at which authoritative DNS service members respond to queries, such as a flood.