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

SC-22 requires you to design and run your organization’s name/address resolution service (typically DNS, plus any internal resolution tiers) so it remains available during component failures and enforces role separation between internal and external resolution functions. Operationalize it by mapping all resolver/authoritative components, building fault tolerance, separating roles and admin paths, then retaining testable evidence. ¹

Key takeaways:

• Inventory “the systems that collectively provide” name/address resolution, not just your primary DNS servers. ¹
• Prove fault tolerance with architecture artifacts and recurring failure/restore test evidence. ¹
• Enforce internal vs. external role separation through network boundaries, access control, and operational procedures you can show an assessor. ¹

SC-22 is easy to misunderstand because DNS is often “just working” until it doesn’t. Assessors look for two things: (1) can your organization still resolve names when a component fails, and (2) have you separated internal and external resolution roles so that compromise, misconfiguration, or operational mistakes in one plane do not cascade into the other. The control text is explicit that you must consider the full set of systems that collectively provide name/address resolution, which commonly spans authoritative DNS, recursive resolvers, forwarders, conditional forwarders, cloud DNS services, split-horizon configurations, and management systems. ¹

For a CCO or GRC lead, the fastest path is to treat SC-22 as a small architecture-and-operations package: assign a control owner, define “internal” and “external” DNS roles for your environment, implement fault tolerance patterns that match your risk profile, then run repeatable tests and keep the artifacts. If you do this well, SC-22 becomes measurable and auditable rather than a narrative. ¹

Regulatory text

Excerpt (requirement): “Ensure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.” ¹

Operator interpretation (what you must do):

1. Define scope: Identify every system involved in name-to-address and address-to-name resolution that your organization depends on (common examples: internal recursive resolvers, authoritative DNS for public domains, cloud DNS zones, on-prem forwarders, and admin consoles). The phrase “systems that collectively provide” is your cue that partial inventories fail the control. ¹
2. Build fault tolerance: Design the service so a single host, zone service, network segment, or provider outage does not stop resolution for critical business services. ¹
3. Separate internal vs. external roles: Implement technical and procedural separation between internal DNS functions (enterprise/private resolution) and external DNS functions (internet-facing authoritative DNS and related management). Separation must show up in network placement, access control, and administration workflows. ¹

Plain-English interpretation of the requirement

SC-22 expects your DNS (and DNS-like resolution tiers) to be resilient by design and segmented by purpose. Resilient means you can lose a resolver, a site, or a managed DNS endpoint and still resolve names for priority systems. Segmented means external authoritative DNS operations should not share the same admin paths, credentials, or change workflows as internal resolution. ¹

If you operate split-horizon DNS, SC-22 is where assessors test whether the split is real: separate views, separate management permissions, and a boundary that prevents external-facing changes from being made through internal-only channels (and vice versa). ¹

Who it applies to (entity and operational context)

SC-22 commonly applies to:

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data (for example, environments aligned to NIST SP 800-53 in ATO/FedRAMP-like control sets, as applicable to your contract). ¹

Operational contexts where SC-22 becomes high-impact:

• You host public domains used for email, customer apps, or SSO entry points.
• You run internal service discovery (Kubernetes, AD-integrated DNS, internal zones) that business apps depend on.
• You rely on third-party managed DNS (registrar + DNS provider) and must show how you maintain resilience and separation across that dependency chain.

What you actually need to do (step-by-step)

1) Assign ownership and define scope boundaries

• Name a control owner (usually Network/Platform Engineering) and a GRC owner responsible for evidence packaging.
• Write a one-page SC-22 scope statement: what counts as name/address resolution in your environment (DNS, internal forwarders, cloud resolver endpoints, reverse DNS where relevant), and what is explicitly out-of-scope with justification.
• Produce a component inventory: authoritative, recursive, forwarding, and management-plane components; include third-party services.

Done looks like: a scoped diagram plus an inventory list that an assessor can trace from “app needs name resolution” to “which resolvers answer” to “who can administer.” ¹

2) Implement fault-tolerant architecture for resolution

Use a pattern set that matches your architecture:

• Redundant resolvers: run multiple recursive resolvers across failure domains (separate hosts, clusters, or sites). Configure clients (DHCP, MDM, golden images) with multiple resolvers.
• Redundant authoritative service: host authoritative zones with redundancy that avoids single-provider and single-region failure modes, where feasible. If you use a third party, document their redundancy and your own contingency actions (for example, secondary DNS or emergency provider cutover playbook).
• Configuration resiliency: store zone/config as code, versioned, with rollback steps and tested restores.
• Operational monitoring: monitor resolver health, query failure rates, SERVFAIL spikes, and zone transfer failures; alert to on-call with defined severity mapping.

Evidence focus: assessors want proof you designed and operate for failure, not a statement that “DNS is redundant.” ¹

3) Implement internal and external role separation (technical + procedural)

This is the most audited part of SC-22.

Define “internal” vs “external” for your org:

• Internal: private zones, AD-integrated DNS, internal resolvers, internal conditional forwarding.
• External: public authoritative DNS zones, registrar operations, DNSSEC key management (if applicable), internet-facing authoritative management consoles.

Implement separation controls:

• Network segmentation: place internal resolvers and internal authoritative infrastructure on internal networks; restrict inbound/outbound management access; prohibit public internet management paths where possible.
• Identity and access management separation: separate admin roles/groups for internal vs external DNS; enforce MFA; restrict privileged actions (zone edits, delegation changes, registrar changes).
• Change workflow separation: separate change tickets/approvals for internal and external DNS; require peer review for external zone changes; log approvals.
• Credential separation: no shared accounts across internal and external DNS platforms; no shared API tokens between internal automation and public DNS automation.
• Logging separation: ensure admin actions for both planes are logged and retained; centralize to SIEM if available.

Practical test: attempt to show that a user who can administer internal DNS cannot administer external DNS, and that the admin channels are distinct. ¹

4) Validate with recurring tests and document results

Create repeatable test cases:

• Failure test: take down a resolver node or block a path and verify clients still resolve critical names.
• Restore test: restore from backup/config repo and prove you can return to a known-good state.
• Role separation test: validate group membership and access paths; confirm least privilege.

Record outcomes, screenshots/exports, and follow-up tickets if gaps are found. ¹

5) Package the control for assessment readiness

The fastest way to reduce audit friction is to pre-assemble:

• a control narrative (1–2 pages),
• diagrams,
• access control exports,
• test evidence,
• change records.

Daydream can help you keep SC-22 mapped to an owner, an implementation procedure, and a recurring evidence set so you do not rebuild the package every audit cycle. ¹

Required evidence and artifacts to retain

Keep artifacts that let an assessor trace design, operation, and outcomes:

Architecture and scope

• Current DNS/resolution architecture diagram(s) showing internal vs external components and trust boundaries
• Component inventory (systems, services, third parties, zones)
• Data flow diagram or narrative for resolution paths (clients → resolvers → forwarders → authoritative)

Fault tolerance

• Configuration showing multiple resolvers and resolver discovery method (DHCP options, device profiles, etc.)
• Authoritative DNS redundancy configuration (secondary DNS, multi-region, or provider design)
• Monitoring dashboards/alerts for DNS health
• Incident tickets or postmortems tied to DNS outages (if any), with corrective actions

Role separation

• IAM role/group definitions for internal vs external DNS administration
• Privileged access reviews for DNS admin roles
• Change management records for external DNS changes (approvals + implementation logs)
• Admin audit logs from DNS platforms and registrar consoles

Testing

• Evidence of periodic failover/restore testing and results
• Evidence of access tests demonstrating separation

Common exam/audit questions and hangups

• “Show me all systems that provide name/address resolution.” If you only show “our DNS servers,” you miss forwarders, cloud resolver endpoints, managed DNS, and registrar control points. ¹
• “Where is the separation between internal and external DNS roles?” Auditors often reject answers that rely on “different zones” without admin and network separation. ¹
• “Prove fault tolerance.” Expect requests for evidence of failover design and test results, not an architecture claim. ¹
• “Who can change public DNS and who approves it?” They will ask for actual access lists and recent change records.

Frequent implementation mistakes and how to avoid them

1. Treating DNS as a single tool instead of a service chain. Fix: document the entire resolution path, including third-party hosted DNS and registrar accounts.
2. Role separation only on paper. Fix: enforce separate admin groups, separate tokens, separate management access paths, and show logs for both planes. ¹
3. Redundancy that fails under real conditions. Fix: run failure/restore tests and capture artifacts; validate client configurations actually point to multiple resolvers.
4. Shared privileged accounts. Fix: remove shared accounts; enforce named accounts and privileged access management patterns where available.
5. No evidence packaging. Fix: map SC-22 to an owner, a procedure, and a recurring evidence checklist in your GRC system (Daydream or equivalent). ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SC-22. ¹

Risk still matters operationally: DNS outages and unauthorized DNS changes can cause loss of availability, traffic interception, email disruption, and service misrouting. SC-22 reduces that exposure by forcing resilient design and limiting blast radius through separation. ¹

A practical execution plan

Use phases rather than calendar-day promises; execution speed depends on architecture complexity and third-party constraints.

Immediate (stabilize scope and ownership)

• Assign control owner and evidence owner.
• Produce a current-state diagram and component inventory (include third parties).
• Identify which parts are “internal” vs “external” and document role definitions. ¹

Near-term (close the largest gaps)

• Implement or validate redundancy for resolvers and authoritative zones.
• Separate admin roles for internal vs external DNS; rotate/remove shared credentials.
• Put external DNS changes under stricter change control and logging. ¹

Ongoing (prove operation and keep evidence fresh)

• Run periodic failover and restore tests; track remediation to closure.
• Perform recurring access reviews for DNS admin roles.
• Refresh diagrams and inventories when DNS architecture changes, and store evidence in a single audit-ready location (Daydream can structure recurring artifacts by control). ¹

Frequently Asked Questions

Does SC-22 only apply to DNS?

It applies to “name/address resolution service,” which usually means DNS plus any forwarding/recursive layers and management systems that collectively deliver resolution. Scope it explicitly and include cloud resolver endpoints and managed DNS if you depend on them. ¹

What counts as “internal and external role separation” in practice?

Separate network placement, admin roles, credentials/tokens, and change workflows for internal vs public DNS operations. Be ready to show access control exports and logs proving the separation works. ¹

We outsource public DNS to a third party. Are we still on the hook?

Yes for control outcomes: you must show the service is fault-tolerant and that roles are separated across your operating model. Contract terms, shared responsibility notes, and your contingency procedures become part of your evidence set. ¹

How do auditors typically test “fault tolerance” for SC-22?

They ask for architecture demonstrating redundancy and for records of failover/restore testing or incident evidence showing continuity during failures. A diagram without test or operational artifacts often fails. ¹

Can we satisfy SC-22 with multi-region cloud DNS alone?

Potentially, if you can evidence the redundancy characteristics and you maintain separation between internal and external administration. You still need documented scope, role separation controls, and testable operational evidence. ¹

What is the minimum evidence package to keep ready?

A scoped architecture diagram, an inventory of resolution components, IAM role/group exports for DNS administration, a sample of recent external DNS change records, and the latest failover/restore test results. Keep them updated as the “collective” service changes. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON