SC-22: Architecture and Provisioning for Name/Address Resolution Service

Quick-reference card

What this control requires

SC-22 requires organizations to design their domain name system (DNS) infrastructure for fault tolerance and to enforce strict role separation between internal and external name resolution services. Most security teams treat DNS as background plumbing, but a single misconfigured or unreachable name server can cascade into widespread outages, failed certificate validations, and broken authentication flows.

In practice, this control means deploying at least two authoritative DNS servers, with one acting as the primary and the other as the secondary. Those servers must sit in geographically separated network subnetworks so that a facility-level failure doesn’t take both offline at once. Beyond redundancy, you need to separate DNS roles so that servers handling internal name resolution requests only respond to internal clients, while servers designated for external queries only handle traffic from outside the organization. You can learn more about the broader risks that DNS misconfigurations create in this overview of DNS spoofing.

The control also requires you to define which clients can access authoritative DNS servers in each role. That means maintaining explicit access control lists or address range restrictions that prevent external clients from querying internal DNS infrastructure and vice versa. Without that boundary, an attacker who gains access to your external-facing DNS server could pivot into internal name resolution data, mapping out hostnames, service locations, and network topology.

Why it matters

DNS is one of the few services that every other system depends on, yet it rarely receives the architectural scrutiny it deserves during compliance assessments. When auditors review SC-22, they’re looking for documented evidence that your DNS design addresses both availability and logical segmentation. A gap in either area creates a finding that flags the organization’s overall communications protection posture as deficient.

Failure to implement SC-22 can result in audit findings across all three baselines, since this control applies to LOW, MODERATE, and HIGH environments alike. That broad applicability means there’s no risk-based argument for deferring it. Organizations that skip fault-tolerant DNS design also risk violating related controls in the System and Communications Protection family, compounding the remediation burden during assessment cycles.

From a governance perspective, the real cost of non-compliance isn’t a single finding but the downstream impact on authorization to operate (ATO) timelines. Assessors who identify DNS architecture gaps often expand their review scope, questioning whether the organization applied the same shortcuts to other infrastructure services. That expanded scrutiny can delay system authorizations by weeks or months.

What attackers exploit

• Single points of failure in DNS infrastructure allow denial-of-service conditions that take entire environments offline when one server becomes unavailable
• Lack of role separation between internal and external DNS gives attackers who compromise an external-facing server visibility into internal hostnames, service records, and network topology
• Unrestricted client access to authoritative servers enables unauthorized queries that map an organization’s internal architecture, supporting reconnaissance for lateral movement
• Geographically co-located DNS servers mean a single physical event or network partition eliminates all name resolution capability for the organization
• Absent or outdated access control lists on DNS servers let unauthorized queries reach sensitive zones, increasing the attack surface for cache poisoning and record manipulation

How to implement

The biggest implementation challenge with SC-22 isn’t the technology itself but producing the documentation and evidence that prove your DNS architecture meets all three assessment objectives: fault tolerance, internal role separation, and external role separation. Many organizations have redundant DNS in practice but lack the system design documentation and access control artifacts that auditors expect.

For your organization

Step 1: Document your current DNS architecture. Create or update a network diagram that identifies every authoritative DNS server, its role (internal or external), its geographic location, and the network subnetwork it occupies. This diagram is a primary evidence artifact during assessments.

Step 2: Deploy fault-tolerant DNS. Configure at least two authoritative DNS servers, with one designated as primary and the other as secondary. Place them in physically separated facilities or availability zones. Verify that zone transfers between primary and secondary servers complete successfully and that failover works as expected by testing with the primary server offline.

Step 3: Enforce internal and external role separation. Designate specific DNS servers for internal queries and separate servers for external queries. Internal DNS servers should only accept requests from internal network ranges. External DNS servers should only respond to clients on external networks, including the internet. Never configure a single server to handle both roles.

Step 4: Implement access control lists. Define explicit client address ranges or access lists for each DNS server role. Internal DNS servers should reject queries from any source outside your internal network address space. External DNS servers should not respond to queries originating from internal addresses. Review and update these lists as your network evolves.

Step 5: Test and validate. Run periodic tests to confirm that fault tolerance works by simulating primary server failures. Verify that role separation holds by attempting cross-role queries and confirming they’re rejected. Document test results as evidence for your system and communications protection policy.

Common mistakes to avoid:

• Running a single DNS server that handles both internal and external resolution, creating a role separation violation
• Co-locating primary and secondary servers in the same data center, which fails the geographic separation requirement
• Relying on cloud provider defaults without documenting how those defaults satisfy SC-22 requirements
• Failing to restrict which clients can query each DNS server role, leaving access control lists undefined

For your vendors

When assessing vendor compliance with SC-22, you need evidence that goes beyond a general attestation. DNS architecture decisions are deeply embedded in infrastructure design, and vendors may not surface this detail unless you ask for it specifically.

Questionnaire questions to include:

• How many authoritative DNS servers does your organization operate, and are they configured in a primary/secondary relationship?
• Are your DNS servers geographically distributed across separate physical facilities or network subnetworks?
• Do you maintain separate DNS servers for internal and external name resolution?
• What access controls restrict which clients can query your internal and external DNS servers?
• How do you test DNS fault tolerance, and how frequently?

Evidence to request:

• Network architecture diagrams showing DNS server placement, roles, and geographic distribution
• DNS server configuration files demonstrating role separation (internal-only and external-only configurations)
• Access control list documentation or firewall rules restricting DNS query sources by role
• Test results from fault tolerance exercises, including failover timing and success rates
• The vendor’s system security plan sections addressing SC-22 or equivalent DNS architecture requirements

Red flags during vendor assessment:

• The vendor can’t identify which DNS servers handle internal versus external queries, suggesting no role separation exists
• All DNS infrastructure resides in a single geographic location or availability zone
• No documented access control lists restrict DNS query sources
• The vendor has no evidence of fault tolerance testing or hasn’t tested within the past 12 months

Verification approach: Request both documentation and technical evidence. Architecture diagrams show intent, but configuration exports and test results prove implementation. Cross-reference the vendor’s DNS architecture against their broader system security plan to confirm consistency. Where possible, ask for independent assessment results that cover DNS security controls specifically.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for this control.

Related controls

• SC-02 — Separation of System and User Functionality: defines broader segmentation principles that SC-22 applies specifically to DNS role separation between internal and external resolution services
• SC-20 — Secure Name/Address Resolution Service (Authoritative Source): addresses the integrity and authenticity of DNS data provided by authoritative servers, complementing SC-22’s focus on architecture and provisioning
• SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver): covers the validation requirements for recursive resolvers and caching servers that consume data from the authoritative sources SC-22 provisions
• SC-24 — Fail in Known State: establishes the principle that systems should fail predictably, directly supporting SC-22’s fault tolerance requirement for DNS infrastructure

Frequently asked questions

What is NIST SP 800-53 SC-22?

SC-22 requires organizations to build fault-tolerant DNS infrastructure with strict role separation between internal and external name resolution services. The control mandates at least two geographically separated authoritative DNS servers and explicit access controls that define which clients can query each server based on its designated role. It applies across LOW, MODERATE, and HIGH baselines, making it a universal requirement for federal information systems and organizations aligning to NIST SP 800-53.

What happens if SC-22 is not implemented?

Without SC-22 implementation, your organization faces audit findings related to DNS fault tolerance and role separation gaps that can delay or block system authorization. A single authoritative DNS server without a geographically separated secondary creates an availability risk that auditors flag as a material weakness. The absence of internal and external role separation also exposes your network topology to unauthorized discovery through DNS queries that should have been restricted.

How do you audit SC-22?

Auditing SC-22 starts with reviewing system design documentation to verify that authoritative DNS servers are deployed in a primary/secondary configuration across geographically separated subnetworks. Assessors then examine DNS server configurations and access control lists to confirm that internal servers only process requests from internal clients and external servers only handle external traffic. Independent test results demonstrating successful failover between primary and secondary servers provide the strongest evidence of fault tolerance compliance.

What is the difference between internal and external DNS role separation?

Internal DNS role separation means configuring dedicated servers that only resolve name and address requests from clients within your organization’s network boundaries. External role separation requires separate servers that exclusively handle queries from clients on external networks, including the internet. This separation prevents an attacker who compromises an external-facing DNS server from gaining visibility into internal hostnames and service records that map your organization’s internal architecture.