Architecture and Provisioning for Name/Address Resolution Service

SC-22 looks small on paper, but it touches architecture, identity, operations, and third-party management. “Name and address resolution” usually means DNS (authoritative DNS, recursive resolvers, forwarders, and sometimes related components like DHCP or directory-backed naming in constrained environments). The requirement is about the collective service, not a single box. If a resolver fails, if an admin account is shared, or if a third party can change records without separation and oversight, you will struggle to defend compliance.

For FedRAMP Moderate operators, the practical goal is straightforward: prevent a single failure, a single misconfiguration, or a single actor from taking down or hijacking name resolution. DNS is a dependency for authentication flows, service discovery, logging destinations, patching, and security tooling. If it becomes unreliable or easily altered, availability and integrity risks propagate quickly across the environment.

This page translates SC-22 into an implementation checklist you can assign to engineering, track in GRC, and defend in assessment. It focuses on what to build, how to split roles, what evidence auditors request, and common failure modes that lead to findings.

Regulatory text

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

Operator meaning: You must (1) design DNS/name-resolution to keep working through component failures and (2) separate duties so the same person or organization is not able to unilaterally administer and provide the service without checks. This applies to both your internal administrative roles (who can change DNS) and external roles (what a third party can do vs what you control). ¹

Plain-English interpretation

SC-22 expects two outcomes:

1. Fault-tolerant name/address resolution: Users and systems can still resolve critical names even if a resolver, zone server, network segment, or hosting component fails. Fault tolerance must be engineered across the service path: clients → resolvers/forwarders → authoritative servers → zone storage/management plane.

2. Role separation (internal and external):

   • Internal role separation: No single admin role should control the full lifecycle without constraints. Separate “request/approve” from “implement,” and separate DNS platform administration from DNS record management where feasible.
   • External role separation: If a third party provides DNS hosting, managed resolvers, registrar services, or DDI tooling, structure responsibilities so that the third party cannot make sensitive changes without your authorization and oversight, and you cannot bypass governance by informal requests.

SC-22 does not mandate a specific technology. It does require you to show that your architecture and access model prevent single points of failure and single points of control. ¹

Who it applies to

Applies to:

• Cloud Service Providers and Federal Agencies operating systems under FedRAMP Moderate baselines. ¹

Operational context where SC-22 shows up:

• You run authoritative DNS for internal zones (private hosted zones) and/or external zones (public domains).
• You run recursive resolvers/forwarders for workloads, endpoints, or platform services.
• You use a third party for registrar, authoritative DNS hosting, DDI, or managed DNS security features.
• You operate multi-account/multi-VPC/multi-network environments where DNS resolution crosses boundaries.

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

1) Define the “name/address resolution service” boundary

Create a scoped inventory that includes:

• Recursive resolvers, forwarders, caching layers
• Authoritative DNS servers/zones (internal and external)
• Zone management plane (APIs, consoles, CI/CD pipelines)
• Registrar and domain ownership controls (for public DNS)
• Any DDI components that push changes (integrations, automation accounts)

Output: A named system/service boundary statement and component inventory tied to your authorization boundary. ¹

2) Design fault tolerance across each tier

Fault tolerance needs to be explicit at each dependency point:

Resolvers/forwarders

• Deploy redundant resolvers across failure domains (separate hosts/instances, separate subnets/availability zones where applicable).
• Configure clients (or DHCP options / platform defaults) to reference multiple resolvers, not one.

Authoritative DNS

• Ensure authoritative zones are served by redundant name servers.
• Avoid single-region or single-network authoritative dependencies for critical internal zones if your architecture depends on cross-region continuity.

Management plane

• Treat the DNS management interface as part of the system. If the control plane fails, you still need operational continuity (read access to current zone state, break-glass paths, and documented recovery procedures).

Testing

• Prove fault tolerance with controlled failover tests: resolver down, authoritative endpoint unreachable, and network path interruption. Record results and corrective actions. ¹

3) Implement internal role separation (people and permissions)

Build a minimum role model that auditors can understand:

Recommended internal roles

• DNS Platform Admin: manages resolver infrastructure, patching, base configuration, logging, and DNS security settings.
• DNS Zone/Record Manager: requests and implements record changes within approved zones.
• Approver/Reviewer: validates business justification and risk (especially for public DNS, mail records, federation endpoints, and security tool destinations).

Controls that make the separation real

• Separate IAM groups/roles for platform vs zone management.
• Enforce change management: ticket required, approval recorded, change linked to implementation.
• Use privileged access management patterns: time-bound elevation, break-glass accounts with monitoring.
• Ensure logging is immutable enough to support after-the-fact accountability (who changed what, when). ¹

4) Implement external role separation (third parties and boundary controls)

If a third party hosts DNS or manages records:

• Put responsibilities in writing: what they can do, what requires your approval, and what evidence they must provide.
• Restrict third-party access to least privilege: separate accounts, scoped API tokens, and role-limited portals.
• Require dual control for high-risk changes where possible (for example, approvals by your staff before third-party execution).
• Maintain your own independent ability to recover: retain domain ownership controls, keep escrow/export of zone files where supported, and document emergency procedures to regain control. ¹

5) Operationalize through change, monitoring, and recovery

To make SC-22 durable:

• Change controls: categorize DNS changes by risk (routine internal records vs public records vs authentication-related records). Require stronger approvals for higher-risk categories.
• Monitoring: alert on record changes, resolver config changes, and unusual query patterns relevant to availability/integrity.
• Backup and restore: back up zone configurations and resolver configurations; test restore in a non-production environment.
• Runbooks: publish incident runbooks for DNS outage, suspected DNS tampering, and registrar compromise scenarios. ¹

Required evidence and artifacts to retain

Keep artifacts that map directly to “fault-tolerant” and “role separation”:

Architecture

• Current DNS architecture diagram (resolver tier, authoritative tier, management plane, network boundaries)
• Dependency map showing failure domains and redundancy approach

Configuration evidence

• Resolver configuration excerpts (showing multiple upstreams/forwarders, redundancy settings)
• Authoritative DNS configuration or hosted-zone settings (showing multiple name servers, replication where applicable)

Access control

• IAM role definitions and group membership exports for DNS administration roles
• Access review records for privileged DNS roles
• Break-glass procedure and evidence of controlled storage/monitoring

Process

• Change management SOP for DNS changes (including approval workflow)
• Samples of DNS change tickets tied to approvals and implementation evidence

Resilience testing

• Failover test plan, results, and remediation tracking
• Incident postmortems where DNS contributed, with corrective actions mapped back to SC-22 ¹

Common exam/audit questions and hangups

Expect assessors to press on these points:

• “Show me fault tolerance.” They often want more than “it’s in the cloud.” Bring diagrams plus test evidence.
• “What’s included in the collective service?” If you omit registrar controls, hosted zone management access, or automation accounts, you create a gap.
• “Who can change records?” Shared admin accounts, undocumented exceptions, and informal approvals trigger findings.
• “How is external role separation enforced?” Contracts alone rarely satisfy. You need technical restrictions and oversight evidence. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails SC-22	Fix
Single resolver endpoint configured everywhere	Creates a single point of failure	Provide at least two resolvers in different failure domains; document client configuration
One “DNS Admin” role with full control	No internal role separation	Split platform admin vs record manager; add approval gates
Third party has full portal admin rights	No external role separation	Scope third-party roles; require your approval for sensitive actions
No evidence of failover testing	“Fault-tolerant” becomes an assertion	Run controlled failure tests and retain results
DNS changes made via ad-hoc chat requests	No accountable workflow	Require tickets, approvals, and logged implementation

Enforcement context and risk implications

No public enforcement cases were provided for SC-22 in the supplied sources, so you should treat this primarily as an assessment and authorization risk in FedRAMP audits rather than a “named case law” topic.

Practically, SC-22 findings tend to be high-friction because DNS failures and DNS record tampering can cascade into authentication outages, service discovery failures, and loss of control over external-facing endpoints. Assessors also view weak DNS role separation as a pathway to privilege abuse. Your mitigation story should connect architecture, IAM, and change control into one coherent control narrative. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and access)

• Define the name/address resolution service boundary and inventory components.
• Produce a current-state architecture diagram with failure domains.
• Enumerate who has DNS-related privileges (internal staff and third parties).
• Implement immediate guardrails: remove shared accounts, require MFA where supported, and establish a basic DNS change ticket workflow. ¹

By 60 days (build redundancy and prove separation)

• Implement resolver and authoritative redundancy where gaps exist.
• Split IAM roles into platform admin vs zone/record management; add approver role and document RACI.
• Update third-party access: least-privilege roles, separate accounts, written operating procedures for changes.
• Stand up logging and alerting for DNS changes and administration actions. ¹

By 90 days (test, document, and make it auditable)

• Execute failover tests and document results, lessons learned, and remediation.
• Finalize runbooks for DNS outage and suspected tampering, including registrar compromise response steps.
• Package evidence for assessment: diagrams, configs, role matrices, access reviews, change samples, and test reports.
• If you use Daydream for GRC workflow, map SC-22 to owner tasks, attach evidence artifacts, and schedule periodic access reviews and resilience test reminders so the control stays “alive” between audits. ¹

Frequently Asked Questions

Does SC-22 apply only to DNS, or also to DHCP and other naming systems?

SC-22 targets “name and address resolution service,” which commonly maps to DNS in most environments. If DHCP or a directory-backed naming component is part of how systems resolve names to addresses in your boundary, include it in scope and document why. ¹

What does “collectively provide” mean in practice?

Auditors will treat the end-to-end resolution path as the control scope: clients, resolvers/forwarders, authoritative zones, and the management plane used to administer them. Document the whole chain and show redundancy and role separation across it. ¹

How do I show “fault-tolerant” without quoting availability metrics?

Use architecture evidence and test evidence. A clear diagram of redundant components plus documented failover tests and outcomes usually carries more weight than an uptime assertion. ¹

If a third party hosts our authoritative DNS, do we still own SC-22?

Yes. You can delegate operations, but you still need to ensure fault tolerance and role separation through architecture choices, least-privilege access, contractual requirements, and oversight evidence. ¹

What’s the minimum role separation auditors expect for DNS changes?

Separate approval from implementation for higher-risk zones/records, and separate platform administration from routine record management where feasible. If you cannot fully separate due to staffing, document compensating controls like heightened logging, independent review, and time-bound privileged access. ¹

What evidence is most likely to prevent a FedRAMP finding for SC-22?

A current architecture diagram with redundancy called out, a role-to-permission matrix for DNS administration, samples of approved change records, and a documented failover test with results and remediation actions. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5