SC-22 name and address resolution: requirements and evidence

What SC-22 asks for and why an assessor starts with the DNS architecture

SC-22 requires the systems that together provide name and address resolution for your organization to be fault tolerant and to separate internal and external roles. It applies in the low, moderate and high security control baselines of SP 800-53B, so an audit, contract or authorization that uses any of those baselines will expect you to show how your DNS is designed, not only that a resolver is running. In Release 5.2.0 the control has no organization-defined parameters and no control enhancements, so the wording you are tested against is short, and the difficulty lies in proving that your particular design meets it. The risk has two sides. A single resolver or a single upstream path that fails can take down every service that depends on names, which is an availability problem. A split-horizon mistake, where an internal zone is answered to outside clients or an external resolver can see private hostnames and addresses, is a confidentiality problem that often goes unnoticed until someone queries the wrong server from the internet. Both failures usually trace back to the architecture rather than to a single misconfiguration.

DNS is hard to evidence because it is often inherited. Teams frequently receive resolution from a cloud provider's default resolver, a managed DNS service or an old appliance whose configuration was set up years ago with no written design. Before you plan any work, confirm which servers answer for internal names, which answer for public zones, which forward to which, and who owns each one. Ask for the vendor's documentation on redundancy and zone separation, and check it against your own configuration settings. Where no design document exists, the first deliverable is a current diagram of resolver roles, owners and failover paths, because an assessor will request it under the *system design documentation* examine method and compare it with the running configuration.

Which DNS systems, zones and teams fall under SC-22

SC-22 applies to the systems that together provide name and address resolution for the organization, so the first job is deciding which resolvers, zones and hosting arrangements sit inside the authorization boundary. Each decision below changes who owns the evidence and how much of the assessment is inherited rather than produced by the organization.

Authoritative and recursive servers in the boundary

Start by listing every server that answers queries for your zones and every server that resolves queries for internal clients. Authoritative servers for public zones and recursive resolvers for internal users are different roles, and SC-22 asks that the systems providing name resolution be fault tolerant and that internal and external roles be separated. If a resolver serves both roles on one host, the boundary is harder to defend and the separation has to be designed and documented explicitly. Confirm the list against live DNS records and network configuration, not only the CMDB.

Cloud-managed DNS as inherited or in scope

Managed DNS services from a cloud provider may be inherited from that provider's own authorization, or they may remain your responsibility for zone content, record changes and access. Whether they are inherited depends on the provider's documentation and the shared responsibility split you can evidence. Ask the provider for its assessment package for the service and check which SC-22 determination statements it covers. Anything it does not cover, such as who may edit records, stays with your team.

Internal and public zone hosting

Public zones are usually served from authoritative infrastructure reachable from the internet, while internal zones such as private domains and service discovery records should stay on resolvers reachable only from internal networks. Where a single zone name is split between the two views, split-horizon configuration becomes a central piece of the evidence. Document which zone is hosted where, which servers answer each view, and how a change to one view is prevented from leaking into the other.

Platform team ownership of resolvers

Resolver hosts often sit with the platform or infrastructure team, while zone content is edited by application owners and DNS records for security services may be managed by the security team. Assign each resolver, each zone and each record class to one accountable owner in writing. Assessors will ask who can change configuration, who approves changes and who reviews the redundancy design, so ownership gaps show up quickly as findings.

Redundancy design and failover scope

Fault tolerance under SC-22 means the resolution service keeps working when one server, site or provider fails, so the scope must include every secondary, anycast node and failover path that carries production queries. Record the number of name servers per zone, their locations and how zone transfers or replication are protected. Include the monitoring that detects a failed server, since redundancy that nobody notices is missing is hard to defend.

How an assessor tests SC-22 across its three determination statements

This table walks through how an assessor works the three SC-22 determination statements in SP 800-53A Release 5.2.0, showing the method used, the evidence requested and the finding that appears most often. Check each row against the matching statement in SP 800-53A, which holds the authoritative wording. The main takeaway is that a design diagram alone does not pass; each design claim must match configuration, test results and logs.

Element	Assessment method	Evidence requested	Common finding
Determination statement 1: fault tolerance of resolution systems	Examine design documentation, then test by disabling one resolver in a non-production environment	Resolver inventory, failover design, failover test records	Single resolver for a name service, or failover that exists only in conversation
Determination statement 2: separation of internal and external roles	Examine configuration, then query internal zones from an external network position	Zone definitions, network diagram, external query test results	Internal zones answering public queries
Determination statement 3: implementation matches the documented design	Compare live configuration to design documentation and interview administrators on operation	Configuration exports, change records, administrator runbooks	Settings that drift from the design with no approved change record
Examine: assessment results from independent testing organizations	Review prior independent test reports covering the resolution architecture	Independent test reports with scope and dates	Reports that exclude the resolvers or predate the current design
Examine: system design documentation	Confirm diagrams and role descriptions identify every resolver and its purpose	Current architecture diagrams, resolver role descriptions	Diagrams omit secondary or cloud-hosted resolvers
Examine: system configuration settings and associated documentation	Read resolver settings and check each one against the stated internal and external roles	Exported resolver configurations with a documented meaning for each setting	Settings that contradict the documented role of a server
Examine: system audit records	Sample logs for resolver restarts, failover events and configuration changes	Logs showing failover events and changes, with retention settings	No resolver logs, so failover cannot be shown to have occurred
Interview: system and network administrators	Ask who operates each resolver and how the team responds to a resolver outage	Named owners, on-call procedures, outage runbooks	Staff cannot describe the failover path or who approves changes

What fault tolerance and role separation look like in a working DNS design

SC-22 asks for two things in the design of name and address resolution: the servers that provide it must tolerate the failure of one or more of them, and the roles of internal and external resolution must be kept apart. In practice, a single resolver that answers both private and public names is the design an assessor is most likely to question. Redundancy means more than a second server with the same IP address on a shared failure domain. Authoritative servers for public zones should be reachable through independent paths and hosted so one outage does not remove every answer. Recursive resolvers serving internal clients should have at least two instances that clients can reach without manual intervention. The organization should confirm, in its own environment, which hosts provide each role and what happens to name resolution when any one of them stops.

The split between internal and external resolution is a design decision that the organization must document and then enforce through configuration. The design should state which zones are private (for example, internal domains and hosts that should never be resolvable from the internet), which zones are public, and which resolvers answer each group. Clients inside the network should query internal resolvers, and public-facing authoritative servers should not also serve private zone data. Documentation alone does not satisfy the control. The configuration of each server, such as zone definitions, allowed query sources and forwarding rules, must match the written design. Each of these settings is a candidate for drift during routine changes, so it should be reviewed against the design on a schedule the organization sets.

An assessor distinguishes a paper design from a running one by asking for evidence from both sides. The design document shows intent, but the assessor will look for the live topology (which servers exist, where they run, and how clients are directed to them) and the configuration files or exported settings that show what each server actually does. Matching them is the test: if the diagram shows two resolvers but the clients point to one, or the external zone file contains internal host records, the design has not been implemented. Audit records and change history for the resolver configuration also help show that the running state has been maintained. Before any assessment, the organization should confirm that its topology and configuration exports can be produced on request and that they describe the same system. Related controls SC-20 and SC-21 cover DNSSEC for authoritative and recursive resolution, and SC-2 and SC-24 are listed alongside SC-22 in the catalog, so the DNS design should be reviewed with them in mind.

How to implement SC-22 in six steps and what each step produces

This sequence takes an organization from an unknown set of resolvers to a documented, fault-tolerant name resolution design with separated internal and external roles, tested failover and retained evidence an assessor can examine.

Inventory every name and address resolution system
Start by listing every component that answers name or address queries: internal recursive resolvers, authoritative servers for public and private zones, forwarders, DHCP-integrated DNS and any cloud-managed resolver endpoints. For each one, record the hostname, address, zones served, which clients use it, the operating system and DNS software version, and the owner. The output is a resolver inventory that your system owner signs off on. It is done when no client group depends on a resolver missing from the list.
Decide and document internal and external role separation
Decide which systems answer only internal clients, which answer only public queries for your external zones, and whether any system is allowed to do both. Write the decision as a design document that names each role, the zones it serves, the network it sits on and the reason for any combined role. Your security and network architects should approve it, and the document should be stored under configuration management. It is done when every zone has one owner role and any exception has a recorded justification.
Provision redundant instances in separate failure domains
Deploy at least two instances for each role, placed in separate failure domains such as separate hosts, racks, availability zones or sites, as your architecture allows. Confirm that a single host, network segment or hypervisor failure cannot remove all instances of a role. Your platform team builds the instances from hardened images and records where each one runs. The output is an architecture diagram and a host list showing the failure domain of each instance. It is done when the diagram shows no single point of failure for any role.
Configure and lock down each role
Apply the role-specific configuration: recursive resolvers accept queries only from approved client networks, authoritative servers answer only their zones and do not offer recursion, and zone transfers are restricted to named secondaries. Remove unneeded services, restrict administrative access and make the configuration reproducible from code. Export the running configuration and the boundary rules that allow DNS traffic, then store the exports with the design document. It is done when each exported configuration matches its documented role.
Test failover and role separation
Test two things. First, stop one instance of each role in turn and confirm that clients still resolve names within the tolerance your design states. Second, attempt queries that the design forbids, such as external clients querying an internal recursive resolver or recursion against an authoritative server, and confirm they fail. Record the test date, the tester, the steps, the observed results and any defects. This test record is the core evidence for the fault tolerance and separation requirements. It is done when every forbidden path is blocked and each failover test has a documented pass or a tracked remediation.
Set up retained evidence and ongoing monitoring
Configure monitoring that alerts when a resolver instance stops answering, when a role starts accepting queries it should not, or when a configuration drifts from its exported baseline. Keep resolver logs, configuration exports, change records and test records together in a location your assessor can reach, with a review cycle your organization sets. Confirm with your independent assessor which artifacts they will examine, because the evidence they accept is their decision. It is done when each control statement has at least one retained artifact linked to a named owner.

Which evidence artifacts pass an SC-22 assessment

SP 800-53A Release 5.2.0 directs an assessor to examine a small set of artifacts for SC-22: independent testing results, design documentation, configuration settings and audit records. The cards below map each of those objects to a practical artifact, with a way to keep it current between assessments. Whether a given assessor accepts a particular format is their decision, so confirm the format with them before you build the evidence set.

DNS architecture and design document

This document shows which systems provide name resolution, which of them serve internal clients, which serve external queries, and how requests move between them. For SC-22, it should state the redundancy design, the separation between internal and external resolver roles, and the failure domains each server sits in. Check that the diagram matches the live topology, not the topology from the last project. Re-issue it whenever a resolver is added, moved or retired, and review it each quarter against the running environment.

Resolver configuration exports

Export the running configuration for each resolver role, separately for internal recursive resolvers and external authoritative servers. An assessor looks for settings that keep the roles apart, such as internal resolvers that do not answer public queries and authoritative servers that do not perform recursion for clients. Store exports in version control with timestamps so you can show what was in force on a given date. Set a change-triggered export on every configuration commit, and run a scheduled comparison to catch drift.

Resolver inventory with redundancy details

The inventory lists every name and address resolution host, its role, its location, its software version, and its paired peers. For SC-22, record how each role fails over, including the number of servers that can answer for each zone and whether they sit on separate hosts, networks or sites. Ask the team to confirm that the inventory matches what monitoring sees. Reconcile it monthly against discovery results and after any infrastructure change.

Failover test records

Failover test records show that the redundant design works when a resolver is taken out of service. Each record should name the server stopped, the expected behavior, the observed result, the time to recover resolution, and the person who signed off. Run tests on a schedule the organization can defend, and rerun them after any change to resolver software or network paths. Keep failed tests and the remediation that followed, since assessors give more weight to a documented fix than to a clean history.

Audit logs of configuration and query activity

Audit records show who changed resolver configuration, when, and through which approved change, and they show query activity that supports the separation of roles. Confirm that logs from each resolver reach a central store that the resolver operators cannot edit. Review configuration-change entries against change tickets each month. Prometheus can collect resolver health metrics and Grafana Alerting can notify the team when a resolver stops answering, which supports the failover evidence without replacing the audit trail.

Independent testing results

Where an independent party has tested the DNS design, its report is the artifact that carries the most weight with an assessor. Examples include a penetration test or configuration review that covers resolver separation. Ask the testing organization to scope the test to the resolver roles and to state the date and version of the system tested. Record any findings, their remediation status, and the retest result, and keep the report alongside the design document it covers.

What meeting SC-22 costs in money and effort

This table breaks down the cost and effort components of meeting SC-22 in a self-hosted environment, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none were supplied; use the quote checklist at the end to compare written scopes on equal terms.

Cost component	Who is paid	One-time or recurring	What drives it up or down
DNS platform or licenses	Software vendor or cloud provider, or no fee for open-source resolvers	Recurring if licensed or managed; often none for self-hosted open source	Number of zones and resolver sites; cloud-managed versus self-hosted; confirm license terms with each vendor
Engineering time for design and provisioning	Internal staff or implementation partner, under a written scope	One-time, with later changes recurring	Count of primary and secondary servers, separation of internal and external roles, and how much existing redundancy can be reused
Failover and role-separation testing	Internal team or independent tester, per the agreed scope	One-time per design change, repeated after major changes	Number of resolver sites, failure scenarios tested, and whether tests are run in production-like environments
Evidence upkeep	Internal compliance or platform team	Recurring across the assessment cycle	Whether configuration is exported automatically, how often zones and resolver settings change, and how many systems sit in the boundary
Independent testing where used	Independent testing organization, if the organization engages one	Recurring if performed each cycle	Scope of DNS testing alongside other controls, and whether results can be reused for other assessments
Assessor sampling time	Independent assessor, under the assessment engagement	Recurring with each assessment	Quality of design documentation and configuration records, which shorten sampling; ask the assessor how they will sample resolver configurations
Configuration export and automation	Internal staff or implementation partner	One-time build, low recurring effort	Automated export of server and zone configuration reduces manual evidence collection; scripting effort rises with the number of zones

Which self-hosted open-source tools can support SC-22 evidence

SC-22 is tested largely through configuration, design documentation and audit records, so the useful tools are the ones that show how resolver roles are separated and how the resolver layer behaves over time. The cards below cover the supplied tools that can produce that evidence and one tool that does not apply to DNS.

OPNsense for traffic separation evidence

OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. For SC-22, rules and aliases can show that internal clients reach the internal resolvers while external queries are restricted to the external resolver role, and per-rule logging can show that those rules match in practice. Confirm with your network team which DNS ports, resolver addresses and forwarding paths are in scope, and whether the firewall is the enforcement point for both resolver roles or only one of them.

Prometheus for resolver health metrics

Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series on local storage. For SC-22, scraped metrics from each resolver can show that both primary and secondary servers are running, which supports a fault tolerance claim. Confirm that a DNS exporter or instrumentation exists for the resolver software you run, that scrape targets cover every redundant server, and how long your retention setting keeps history so an assessor can review past failover events.

Grafana Alerting for resolver failures

Grafana Alerting builds alert rules from queries across data sources and can alert on metrics and logs together from one view. For SC-22, alert rules on resolver availability, and on log messages from each resolver, can show that a failed server is detected and routed to a responder. Confirm that the data sources you query include resolver logs, and that alert history is retained. If you distribute Grafana itself, review the AGPL-3.0-only license terms with counsel before doing so.

Coraza is outside SC-22 evidence

Coraza is a web application firewall, compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, that defends against attacks such as SQL injection and cross-site scripting. It sits in front of web applications, so it does not enforce or record DNS resolver roles and should not be cited as SC-22 evidence. Use it for web application controls, and rely on the firewall, resolver configuration and monitoring tools above for name resolution.

Who owns SC-22: your team, an implementation partner and the auditor

Your organization owns SC-22 in full. Named owners must decide how many name resolution systems exist, which of them answer for internal names and which answer for external names, how failover works, and which residual risks leadership accepts. These are governance decisions, and no partner or auditor can make them for you. Your team also runs the resolvers after go-live, which includes patching, monitoring and responding when a server fails.

Architecture decisions: Decide the number of authoritative and recursive servers, where they sit, and how internal and external roles are kept apart.
Risk acceptance: Record any gap between the design and the control in the plan of action and milestones, with a named approver.
Daily operation: Own monitoring, patching, zone change approvals and access to resolver administration.
Evidence ownership: Keep configuration exports, failover test results and change records current so they can be produced on request.
Vendor and contract management: Hold the agreements under which any partner or hosting provider works.

Before engaging anyone, confirm internally who signs the control narrative and who answers assessor questions during fieldwork.

Common questions about SC-22 cost, effort and outside help

How much effort does SC-22 take for a small DNS estate versus a large one?

Effort scales with the number of resolvers, zones, sites and resolution paths, not with the control text itself, which is short. A small estate with one authoritative pair and one caching pair usually needs a short design review, a configuration check and evidence capture. A large estate adds more resolver tiers, multiple data centers or cloud accounts, split-horizon zones, forwarders and change records for each node, so the inventory and testing work grow faster than the design work. Ask the assessor which components they will sample, because that sets how much evidence you must produce. No effort figure is given here because none has been researched for this control; confirm estimates against your own zone and resolver inventory.

Does cloud-managed DNS satisfy SC-22 without extra work?

Not automatically. A managed DNS service may provide redundancy across its own infrastructure, but SC-22 is assessed for the systems your organization uses to provide name resolution, so you still need evidence of how those services are configured, which roles are separated and how internal and external resolution are kept apart. The provider's SOC or similar report can support the assessment as independent testing evidence, but it does not replace your own design documentation, configuration settings and audit records. Confirm with the provider which redundancy and separation features are configurable in your account and which are fixed.

How long does SC-22 preparation usually take, and what drives that time?

The duration depends on how well the current DNS design is documented and how many systems carry name resolution roles. Time is usually driven by four things: finding every authoritative and recursive server, including ones added informally; agreeing the separation between internal and external roles; producing configuration exports and change history; and fixing gaps such as a single resolver, shared hosts for both roles or missing failover testing. Each gap that needs a hardware or network change adds lead time that is outside the documentation work. No duration is stated because none has been researched; ask your team and any partner to confirm it against the inventory.

What does SC-22 need from our internal team?

The control is owned by the organization, so internal staff must make and document the decisions. The main contributions are:

Network and DNS engineers who can export zone and resolver configurations and explain failover behavior.
A system owner who confirms which hosts provide internal and external resolution and who approves the design.
Security or compliance staff who map the design to the assessment objects and collect audit records.
Change management staff who can show how resolver configuration changes were approved and recorded.

Plan these hours before work starts, since they are often the constraint, not the tooling.

Can we do SC-22 readiness in-house without an outside partner?

Yes, if you have engineers who understand DNS architecture and the staff to produce documentation and evidence. An outside partner is most useful when the estate spans several environments, when the internal team lacks time to build the evidence set, or when an independent view of the design is needed before an assessor arrives. Remember that a partner can prepare systems and evidence, but only an independent assessor or auditor tests the control and reports on it. DeployOpen works on self-hosted open-source platforms inside a client's own infrastructure and prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications.

What should a written scope for SC-22 work include?

A written scope should make the boundary and deliverables explicit so that cost and timing can be compared across quotes. Ask for:

The list of DNS servers, zones and resolution paths in scope, with the environments they run in.
The baseline in scope (low, moderate or high) and any related controls included, such as SC-20 and SC-21.
The design review, configuration hardening and failover testing tasks, with the evidence each produces.
Which items the client must provide, and the approval points.
Exclusions, such as the assessor's fees or work on external managed services.
Handover documentation and whether ongoing support is a separate retainer.

Fixed-scope engagements agree these items in writing before work starts, so ask for them before signing.

How DeployOpen scopes and prepares SC-22 evidence

DeployOpen prepares the name resolution architecture and the evidence an assessor will review for SC-22, inside the client's own infrastructure. The organization owns the control and its risk decisions, and only an independent assessor or auditor issues findings or reports.

How we scope

Confirm which DNS servers, resolvers and address services fall inside the system boundary for SC-22 and which baseline applies.
Record which resolvers serve internal names, which serve external queries and where each role is hosted.
Agree the written scope, deliverables and timeline with the client before any configuration work starts, as engagements are fixed-scope.

How we build

Deploy redundant authoritative and recursive DNS servers across separate hosts or failure domains, with documented failover behavior.
Separate internal and external resolution roles so internal zones are not answered by publicly reachable servers.
Configure and test firewall rules, such as those in OPNsense, that restrict which hosts can reach each resolver role.

How we hand over

Document the resolver architecture, role separation, configuration settings and the failover test results for assessor review.
Export configuration files, rule sets and monitoring alert definitions, such as Prometheus and Grafana alerts for resolver health, as evidence.
Hand over the artifacts to the client, who decides what to submit to the independent assessor and how to track open findings.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Re-test resolver failover and role separation after changes to network design, DNS software or hosting locations.
Update the SC-22 evidence set when the client's SP 800-53 baseline, related controls or assessment procedures change.

SC-22 Architecture and provisioning for name/address resolution service