STIGViewer Support

The BIND 9.x server implementation must implement internal/external role separation.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-272399BIND-9X-001430SV-272399r1124058_ruleCCI-000366medium
Description
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 access an authoritative DNS server in a particular role is specified by the organization using address ranges, explicit access control lists, etc. To protect internal DNS resource information, it is important to isolate the requests to internal DNS servers. Failure to separate internal and external roles in DNS may lead to address space that is private (e.g., 10.0.0.0/24) or is otherwise concealed by some form of Network Address Translation from leaking into the public DNS system. Allowing private IP space to leak into the public DNS system may provide a person with malicious intent the ability to footprint the network and identify potential attack targets residing on the private network.
STIGDate
BIND 9.x Security Technical Implementation Guide2026-02-25

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (8) 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.

CFG-01Configuration Management Program
1.00
END-01Endpoint Device Management (EDM)
1.00
END-04Malicious Code Protection (Anti-Malware)
1.00
END-06Endpoint File Integrity Monitoring (FIM)
1.00
MON-01Continuous Monitoring
1.00
MON-01.7File Integrity Monitoring (FIM)
1.00
CFG-02Secure Baseline Configurations
0.50
CFG-02.7Approved Configuration Deviations
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (100) 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.

AC-12Session Termination
1.00
AC-16(1)Dynamic Attribute Association
1.00
AC-17(1)Monitoring and Control
1.00
AC-2Account Management
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(11)Usage Conditions
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-24(1)Transmit Access Authorization Information
1.00
AC-25Reference Monitor
1.00

+90 more (top 10 by confidence shown)

NIST 800-1710 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.

3.4.1
1.00
3.4.2
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (5) 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.PSPlatform Security
0.50

Who does this work

10 NICE work roles and 9 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-272399r1124058_chk)

Severity override guidance: If the internal and external views are on separate network segments, this finding may be downgraded to a CAT II. If the BIND 9.x name server is not configured for split DNS, this is not applicable. Verify that the BIND 9.x server is configured to use separate views and address space for internal and external DNS operations when operating in a split configuration. Inspect the "named.conf" file for the following: view "internal" { match-clients { <ip_address> | <address_match_list> }; zone "example.com" { type Primary; file "internals.example.com"; }; }; view "external" { match-clients { <ip_address> | <address_match_list> }; zone "example.com" { type Primary; file "externals.db.example.com"; allow-transfer { Secondarys; }; }; }; If an external view is listed before an internal view, this is a finding. If the internal and external views are on the same network segment, this is a finding. Note: BIND 9.x reads the "named.conf" file from top to bottom. If a less stringent "match-clients" statement is processed before a more stringent "match-clients" statement, the more stringent statement will be ignored. With this in mind, all internal view statements must be listed before any external view statement in the "named.conf" file.

Fix Text (F-76356r1123509_fix)

Edit the "named.conf" file. Configure the internal and external view statements to use separate network segments. Configure all internal view statements to be listed before any external view statement. Restart the BIND 9.x process.