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

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Low, Moderate, High	System	None

Related controls: SC-2, SC-20, SC-21, SC-24

Control statement

Ensure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.

NIST discussion

Systems that provide name and address resolution services include domain name system (DNS) servers. To eliminate single points of failure in systems and enhance redundancy, organizations employ at least two authoritative domain name system servers—one configured as the primary server and the other configured as the secondary server. Additionally, organizations typically deploy the servers in two geographically separated network subnetworks (i.e., not located in the same physical facility). For role separation, DNS servers with internal roles only process name and address resolution requests from within organizations (i.e., from internal clients). DNS servers with external roles only process name and address resolution information requests from clients external to organizations (i.e., on external networks, including the Internet). Organizations specify clients that can access authoritative DNS servers in certain roles (e.g., by address ranges and explicit lists).

Assessment objectives (SP 800-53A)

Objectives and methods for SC-22

Determine if:

• SC-22[01] the systems that collectively provide name/address resolution services for an organization are fault-tolerant;
• SC-22[02] the systems that collectively provide name/address resolution services for an organization implement internal role separation;
• SC-22[03] the systems that collectively provide name/address resolution services for an organization implement external role separation.

Examine: System and communications protection policy; procedures addressing architecture and provisioning for name/address resolution services; access control policy and procedures; system design documentation; assessment results from independent testing organizations; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; organizational personnel with responsibilities for managing DNS.

Test: Mechanisms supporting and/or implementing name/address resolution services for fault tolerance and role separation.

Policy statement

• The System owner shall ensure the systems that together provide name and address resolution service for the organization are fault-tolerant and implement internal and external role separation. (SC-22)

From the System and Communications Protection Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SC-22 asks that the DNS servers that together serve the organization have no single point of failure, and that servers answering internal clients are kept apart from servers answering the internet. NIST’s discussion gives the expected shape: at least two authoritative DNS servers, one primary and one secondary, typically in two geographically separated subnetworks, not in the same physical facility. For role separation, internal servers process requests only from internal clients, external servers only from external clients, and the organization specifies which clients may reach each role, for example by address ranges. SC-22 is in the Low, Moderate and High baselines.

Common implementations. NIST SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide (March 2026), sections 2.3.1 and 2.3.2, describes the usual design:

• Public zones on a managed DNS or cloud DNS service, which spreads them across many servers and sites. Where the organization hosts its own, it runs a hidden primary that does not appear in the zone’s NS records, with only secondaries visible, and at least two authoritative servers on different network segments and at different sites.
• Internet-facing name servers that are either authoritative or recursive, never both. External authoritative servers sit in a DMZ or a hosting service and serve only internet-facing records; internal servers are unreachable from outside and may combine authoritative and recursive roles, which NIST calls acceptable for purely internal servers.
• Internal names not published in external zones (sometimes called split-horizon DNS), and recursion turned off on authoritative servers.
• Dedicated, hardened DNS servers or a purpose-built DNS service, with DNS server software removed from hosts that are not name servers.
• Zone transfers limited to the named secondaries and protected with transaction signatures (TSIG), and zone transfers turned off on secondaries that do not serve others (sections 3.1 and 3.1.1).
• Clients given at least two recursive resolvers, or one anycast address in front of several (section 5.1).

The contingency plan should treat DNS as a dependency of every system: if name resolution fails, the system is unreachable even when it is running (CP-2).

Organization-defined parameters. SC-22 has no parameters. In the System and Communications Protection policy, the system owner ensures the systems that together provide name and address resolution service for the organization are fault-tolerant and implement internal and external role separation.

Evidence assessors ask for.

• The DNS architecture: a diagram or list of authoritative and recursive servers or services, their roles, network locations and sites
• The NS records for each public zone, showing at least two servers on separate networks (or the provider’s documentation of its distribution)
• Configuration showing recursion off on external authoritative servers, and access lists limiting internal servers and resolvers to internal clients
• Zone transfer settings: allowed secondaries and TSIG
• A check from outside the network that internal names do not resolve and internal servers do not answer

Inheritance. Public DNS on a managed or cloud service is largely inherited from the provider, and internal DNS is usually a common control run by the network or infrastructure team. Record both in the system security plan. A system owns SC-22 itself only when it runs its own name servers, such as a separate directory domain or a self-managed cloud environment.

Common findings.

• An internet-facing server that is both authoritative and an open recursive resolver.
• Both authoritative servers, or both domain controllers serving DNS, in the same data center or subnet.
• Internal host names published in the public zone, or internal servers answering queries from the internet.
• Zone transfers allowed to any host.

Enhancements in the Moderate baseline. SC-22 has no enhancements.

Artifacts

• System and Communications Protection Decision Worksheet
• System and Communications Protection Policy