SC-21 Secure name/address resolution: requirements and evidence

SC-21 secure name resolution: what a recursive resolver must prove about DNS answers

When an agency, a FedRAMP sponsor or an enterprise asks whether its internal resolvers validate DNSSEC, it wants evidence, not a statement that the setting is on. SC-21 asks that recursive or caching resolvers request and perform data origin authentication and data integrity verification on the responses they receive from authoritative sources. In plain terms, the resolver must be able to show that an answer really came from the zone owner and was not altered in transit. Without that check, a forged or poisoned answer can send users and services to the wrong address while every log looks normal. The control is the counterpart of SC-20, which covers the authoritative side where zone data is signed. SC-21 sits at the other end of the chain: it is the resolver's job to check the signatures that SC-20 makes possible.

SC-21 is a base control in the low, moderate and high baselines in SP 800-53B, and FedRAMP requires it in the annual independent assessment at Classes B, C and D. Its difficulty is less about the technology than about where the configuration lives. Validation settings are often spread across several resolver hosts, forwarders, appliances and cloud DNS services, and some are set by a different team than the one that owns the network. Teams tend to assume validation is on because a default was never changed. An assessor will ask the resolver itself. Before any assessment, confirm with your platform team which resolver products and forwarders answer internal queries, and which of them are expected to validate.

A useful first step is to inventory every resolver in the scope boundary and record, for each one, how validation is set and where that setting is stored. Then test it: query a name that is known to be signed with bad signatures from a test zone you control, and confirm that the resolver returns a failure rather than the answer. Keep the output, the configuration file or policy export, and the change record that shows when validation was enabled. Those three items usually satisfy an examine and test request for SC-21, and they should sit alongside the system design documentation the assessment procedure expects. Confirm the exact test method with your assessor before you run it, since the procedure wording governs what counts as sufficient evidence.

Which resolvers and DNS paths does SC-21 cover?

SC-21 applies to every recursive or caching resolver that answers queries for the system. Scoping starts by listing each resolver, each client path to it and each outside DNS service that sits between the system and the internet, then confirming which of them belong inside the authorization boundary.

Resolvers that serve the system

List every recursive or caching resolver that answers queries for systems in scope, including resolvers on hosts, in containers and on network appliances. Each one needs its validation setting confirmed, because a resolver that does not validate DNSSEC signatures on responses from authoritative servers leaves SC-21 unmet regardless of how well the rest of the DNS design is run. Ask the resolver owner for the exact validation configuration and where it is recorded.

Forced resolution for internal clients

Check whether internal clients can only reach external names through the in-scope resolvers. Clients that query public resolvers directly, through hard-coded addresses or DNS-over-HTTPS settings in applications, bypass the validating resolver and leave the assessor without evidence for those queries. Egress rules and endpoint configuration should show that the approved resolver is the only path.

Cloud-provided versus self-hosted resolvers

Cloud-provided resolvers are often the default for virtual networks, but the organization still needs to know whether they validate DNSSEC, what settings the customer can change and what logs they provide. Self-hosted resolvers give direct control over validation and logging, at the cost of patching and monitoring them. Document which option applies to each environment and attach the provider's documented behavior to the system security plan.

Third-party DNS services in the path

Filtering, threat intelligence and protective DNS services that resolve queries on the organization's behalf sit in the resolution path and must be assessed as part of the system or as an external service. Confirm whether the service validates DNSSEC, whether it is a sub-processor for DNS query data, and how its service agreement describes responsibility for validation failures.

Boundary and authorization evidence

SC-21 is implemented by the system, so the validating resolver must be inside the authorization boundary or formally documented as an inherited service. Record each resolver in the system inventory, mark its boundary status and tie it to the system security plan. An assessor will check that the inventory matches the resolvers actually observed in network configuration and logs.

Related controls in the same path

SC-21 is the resolver-side counterpart of SC-20, which covers the authoritative zones the organization publishes, and it works alongside SC-22 for resolver architecture and provisioning. Review these controls together for the same resolver so that the signing side, the validating side and the redundancy design do not drift apart across assessments.

How an assessor tests SC-21 under SP 800-53A

This table walks through how an assessor applies the SP 800-53A procedure for SC-21, which method is used for each part of the evidence, and where resolver deployments commonly fall short. Read it as a checklist of what to prepare before the assessment starts, not as a list of pass conditions.

Assessment element	What the assessor does	Evidence to prepare	Common finding
Determination statements (4)	Confirms each of the four statements about recursive or caching resolvers requesting and verifying origin authentication and integrity on responses from authoritative sources	A written mapping from each statement to a configuration item, owner and test record	Statements answered by policy text alone, with no configuration behind them
Examine: system design documentation	Reads how resolvers sit in the architecture and whether validation is described for every resolver in scope	Architecture diagrams showing each recursive or caching resolver, its upstream paths and where validation is enforced	Design documents that omit a resolver tier added later
Examine: configuration settings and associated documentation	Checks that validation is enabled in each resolver's live or exported configuration and that the setting matches the documented standard	Exported resolver configuration per host, change history for validation settings, and the baseline it is measured against	Validation disabled on one resolver in a pool, often after a troubleshooting change that was not reverted
Examine: system audit records	Looks for records showing validation activity and failures, and checks whether they are retained and reviewed	Resolver logs or exported events that show validation failures, retention settings and a sample review record	No logs of validation failures, or logs written locally and never collected
Interview: resolver and network operators	Confirms who maintains resolver settings, how a failed validation is handled, and whether staff understand the upstream resolution path	Named owners, runbooks for validation failures and an on-call escalation path	Operators unable to say which resolvers forward queries to which upstreams
Interview: fallback and forwarding decisions	Asks whether any resolver falls back to an unvalidated upstream when the primary path fails, and who approved that behavior	Written approval for each forwarder or fallback, with the conditions under which it is used	Undocumented fallback resolvers that answer queries without validation
Test: deliberately broken signature	Places a known-bad signed response in a controlled test path and checks that the resolver rejects it instead of returning the data	Test plan, test domain or lab zone, expected result and the resolver output captured during the run	Resolver returns the forged answer because validation was not active on the path tested
Test: valid chain and log correlation	Confirms that a correctly signed response resolves and that the failed test produced a matching log entry	Paired test results showing successful resolution, the rejected case and the corresponding audit record	Validation works, but no record links the failed test to a log entry, so the evidence cannot be traced

Implementing SC-21 in six steps

This sequence moves a recursive or caching resolver from an unknown state to one where DNSSEC validation is enabled, documented, tested against known good and deliberately broken zones, logged, and checked on a recurring schedule. Each step closes with an artifact an assessor can examine.

Inventory resolvers and upstream paths
The organization's infrastructure team lists every recursive or caching resolver that serves the system, including forwarders, resolvers in cloud accounts, and any resolver embedded in appliances or containers. For each one, record the software and version, the host or service that runs it, the upstream servers or root path it queries, and whether it serves internal clients, external clients, or both. Note which authoritative zones the system depends on. This step is done when the inventory is reviewed and every resolver that can answer system queries appears in it, with an owner named for each. The inventory becomes the scope statement an assessor will check against.
Enable and verify DNSSEC validation
The resolver owner turns on DNSSEC validation in each resolver's configuration and confirms that the resolver requires valid signatures on responses from authoritative sources rather than only passing them through. The change is made through the platform's own configuration management, not by hand on a running host. Confirm the setting with a query against a known signed name that should validate and a query that should be refused when validation fails. Capture the configuration file, the command output and the change record. This step is done when each inventoried resolver shows validation enabled in its effective configuration.
Document the configuration baseline
Write the validated settings into a configuration baseline that names each resolver, its validation setting, its trust anchor management, its upstream paths and its logging destination. Store the baseline under version control so every later change produces a diff and an approval record. Map the baseline to the SC-21 determination statements in SP 800-53A so the assessor can see which document answers which statement. Confirm with the control owner that the baseline matches the running configuration. This step is done when the baseline is approved and a configuration check shows no drift from it.
Test with signed and broken zones
Test validation behavior in a non-production environment before relying on it. Query a correctly signed test zone and confirm the answer is returned with validation. Then query deliberately broken zones, such as a zone with an expired signature, a mismatched key, or a missing signature, and confirm the resolver refuses the answer and records a validation failure. Run the same tests after any resolver upgrade. Keep the zone definitions, query commands, expected results and actual results as test records. This step is done when every test produces the expected result and the records are filed with the baseline.
Route validation-failure logs to the audit store
Configure each resolver to send validation-failure events, query logs and configuration change events to the central audit store that the organization uses for its other security logs. Confirm that timestamps are synchronized with the organization's time source so failures can be correlated with other events. Check that the log pipeline is protected from modification and that retention meets the organization's audit requirements. Generate one deliberate validation failure and confirm it appears in the audit store with the expected fields. This step is done when a test failure is visible in the audit store and the log path is documented in the baseline.
Schedule recurring checks and reassessment
Set up automated checks that compare each resolver's running configuration to the baseline, confirm that validation remains enabled, and repeat a sample of the signed and broken zone tests. Route any drift or failed test to the owner for remediation and record the outcome. Review the inventory on the organization's normal change cycle so new resolvers are added to scope. For systems assessed annually, such as those under FedRAMP, preserve the check results for the assessor. Confirm the recurring schedule and the escalation path with the control owner. This step is done when the checks run on schedule and produce records that show the baseline still holds.

Evidence that passes an SC-21 assessment

An assessor testing SC-21 wants proof that the resolver validates DNSSEC signatures, that the design explains where validation happens, and that failures are caught and logged. The cards below cover the artifacts that show this, and the recurring checks that keep them current between annual FedRAMP assessments.

Resolver configuration exports

Export the resolver configuration from every recursive or caching instance and store the files with a capture date and host name. The assessor is looking for an explicit setting that enables DNSSEC validation, plus the trust anchor used, and the export must match what the running process reports. Check that forwarders, if used, do not bypass validation by stripping the signed data. Re-export after every change and after each scheduled review so the file in the evidence folder matches production.

System design documentation of the resolver

Document where the recursive or caching resolvers sit, which clients they serve, which authoritative sources they query, and how they relate to the authoritative servers covered by SC-20 and SC-22. Show the data flow from client query to validated answer, including any upstream forwarders. Assessors use the diagram to confirm that no path returns unvalidated answers to internal clients. Update the document whenever the resolver topology changes.

Validation test results

Keep test results showing that a correctly signed zone resolves and that a deliberately bogus response, such as a record with an invalid or missing signature in a lab zone, is rejected. Run these tests from a controlled test zone rather than production domains. Record the query, the expected result, the observed result and the tool version. Schedule the same test suite on a recurring basis so the results in the assessment package are recent, not a one-time demonstration.

Audit records of validation failures

Retain logs that record validation failures, including the query name, record type, time and reason the response was rejected. Assessors check that these records exist, cover the audit retention period and can be reviewed. Time stamps must be synchronized with the central time source so failures correlate with other security events. Review failure logs on a set cadence, record the reviewer and the disposition of unusual spikes, and feed repeated failures into the incident process.

Change records for resolver configuration

Keep change tickets for every edit to resolver settings, trust anchors and forwarder lists, with the requester, approver, reason and before and after values. Assessors compare change records against the configuration exports to confirm that validation was never disabled without authorization. Tie each change to a version-controlled configuration file where possible, so the diff is visible. Review changes during the annual assessment cycle to confirm the record is complete.

Recurring review of evidence

Assign an owner to each artifact and set a review calendar that runs between annual assessments. Each cycle, refresh the configuration export, rerun the validation tests, sample the failure logs and confirm that the design document still matches the running topology. Record the date of each review and the outcome. Confirm with your assessor which review frequency and sample sizes they expect before you set the schedule.

Why SC-21 depends on SC-20 and SC-22 to hold together

SC-21 only makes sense as part of a name service that the organization runs as a whole. SC-20 covers the authoritative side, where the organization signs its own zones with DNSSEC and supports chain-of-trust validation for external queries. SC-22 covers how the name service is architected and provisioned, including redundant servers and the separation of internal and external resolution roles. SC-21 covers the recursive or caching resolver that requests and verifies origin authentication and data integrity on responses from authoritative sources. If the signed zones (SC-20) are wrong or the resolver layout (SC-22) is unclear, a resolver that validates correctly still cannot show what it is validating against.

An assessor who tests SC-21 will usually read the evidence alongside SC-20 and SC-22. In practice, the resolver configuration, validation settings and audit records that support SC-21 often sit in the same systems and change records as the signing and redundancy evidence. Assign one owner for all three controls, keep a single control narrative, and cross-reference each control's implementation statement and evidence to the other two so an assessor can trace a question from one to the next. Confirm the scope boundaries with your assessor early, because the same resolver may serve both internal and external roles.

FedRAMP 20x lists SC-21 as a related SP 800-53 control for two Key Security Indicators, KSI-IAM-ELP (Ensuring Least Privilege) and KSI-SVC-SIN (Securing Information). Those links matter if your program is assessed against FedRAMP, but the indicators are not a substitute for the control. Confirm with your assessor and the current FedRAMP rules how each indicator applies to your own boundary, which of your resolver and administrative access records serve as evidence, and whether the indicators change your evidence set before you prepare the SC-21 package.

What meeting SC-21 costs in money and effort

This table breaks SC-21 cost into components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a written scope and to compare quotes on like-for-like terms. No prices or durations are given here because none are supplied, so ask each provider for its own figures.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Resolver platform licenses	Software vendor, if a commercial resolver is chosen; none for self-hosted open-source resolvers	Recurring if commercial; zero licence fee for open-source software	Choice of resolver software and support level, and whether support is bought
Engineering to configure and test DNSSEC validation	Internal staff or implementation partner, under a written scope	One-time, with retesting after major changes	Number of resolvers, validation settings, and how many upstream zones must be checked
Architecture documentation for the resolver role	Internal architects or implementation partner	One-time, updated when the design changes	Number of resolver instances, placement across cloud and on-premises networks, and how internal and external roles are split
Validation testing and recurring log review	Internal security operations or a managed service	Recurring, usually tied to the review cycle the organization sets	Volume of resolver logs, existing SIEM integration, and how many validation failures must be triaged
Hybrid cloud DNS integration	Internal cloud or network team, or implementation partner	One-time build, with recurring change control	Number of cloud accounts, on-premises links, and split-horizon DNS designs
Independent assessor sampling	Independent assessor, under its own engagement terms	Recurring for each assessment cycle, including FedRAMP annual assessments where they apply	Number of resolvers and zones sampled, quality of existing evidence, and whether configuration exports are ready
Existing logging and evidence collection	Internal platform team; may reduce other costs if already in place	One-time setup, recurring storage and retention	Whether resolver logs already reach a central store and how long records must be kept

Who owns SC-21, who prepares the evidence and who assesses it

The organization owns SC-21. It decides which resolvers are recursive or caching, which authoritative sources they may query, and whether DNSSEC validation is required on every resolver that serves its users or systems. Accountability sits with a named owner who approves the control design, accepts residual risk and signs the system security and privacy plan entry for SC-21. Ownership does not transfer when work is outsourced.

Control design: Decide which resolvers validate responses, which upstream sources they trust and what happens when validation fails.
Policy and procedure: Maintain the SC-1 policy that governs name resolution and the review frequency for resolver settings.
Risk acceptance: Document any resolver that cannot validate signatures and who approved the exception.
Operational ownership: Assign people to monitor validation failures and respond to them.
Contract control: Keep the implementation partner's deliverables, access and handover obligations written down.

Check that the owner can name the resolvers in scope, the settings that enforce validation and the person who reviews the evidence each cycle.

Where SC-21 usually fails and how to close each gap

SC-21 fails less often on the DNSSEC feature itself than on how it is deployed and proven. The gaps below cover resolver coverage, forwarding paths, testing, logging and ownership, because an assessor needs evidence that every resolver in scope validates and that the validation is documented and reviewed.

Validation enabled on some resolvers only

Organizations often turn on DNSSEC validation on one primary resolver while branch, cloud or container resolvers keep the default settings. SC-21 applies to every recursive or caching resolver in the system boundary, so an assessor who samples a secondary resolver can find it non-compliant. Inventory each resolver, record its validation setting from the configuration file, and confirm the setting survives image rebuilds and restarts.

Forwarders that strip signatures

A resolver that forwards queries to an upstream service may receive validated answers but return them without the DNSSEC records, or may set the flag that tells clients validation was already done. Downstream clients then trust data nobody verified. Test each forwarding path by querying a domain with a deliberately broken signature and confirming the answer is refused, and check that forwarders pass the DNSSEC records through when they should.

No test proving validation rejects bad data

A resolver showing a validation setting in a configuration file does not show that validation works. Assessors look for evidence that the resolver actually rejects data that fails verification. Use a DNSSEC test zone with an intentionally invalid signature, query it through each resolver, and save the failed response and the resolver log entry as the test record. Repeat the test after each resolver upgrade or configuration change.

Validation logs not retained

Validation failures are often logged at a verbose level that is turned off in production, or written to a local file that rotates within days. Without retained logs, the organization cannot show failed validations were detected, investigated or reviewed, and it cannot correlate them with suspected cache poisoning. Set a log level that records validation failures, forward those logs to a central store, and document the retention period your policy requires.

Undocumented resolver ownership

When no team is named for a resolver, its patches, validation settings and log reviews drift or lapse. Assessors ask who owns each resolver, who approved its configuration and who reviews its validation evidence, and a missing answer is a finding even when the technical setting is correct. Record the owner, the approver and the review cadence for every resolver in the system security plan and link each one to its configuration and test records.

SC-21 questions buyers ask before hiring help

How much effort does SC-21 take for a small environment?

For a small environment, SC-21 is usually a bounded piece of work rather than a program: confirm which resolvers your systems actually use, confirm that those resolvers validate DNSSEC signatures on responses, and collect the configuration and logs that show it. The effort scales with how many resolvers you run, whether they are your own or a managed service, and how many internal zones need documented behavior. No NIST source sets an effort figure for this control, so ask any partner to show the effort breakdown in the written scope, including who verifies each resolver setting. The control itself is one of four determination statements in SP 800-53A, so the evidence set is small if the design is simple.

Can our own team implement SC-21 without outside help?

Often yes, if you already run DNS and have someone who can read resolver configuration and DNSSEC validation logs. The work is to decide which resolver role your systems use, enable and verify DNSSEC validation on that resolver, document the design, and retain the configuration and audit records an assessor will examine. Outside help is most useful where the resolver design is unclear, where the team has no one who has tested DNSSEC validation end to end, or where the assessment is tied to a contract deadline. Your organization owns the control either way. Only an independent assessor can test it and report on it.

What does SC-21 require from our staff?

SC-21 requires staff who understand three things: how your recursive or caching resolvers are deployed, how DNSSEC validation is enabled and checked on them, and how configuration changes are recorded. In practice you need a named owner for the resolver configuration, someone who can run validation tests against a signed and a deliberately broken test zone, and someone who can explain the audit records to an assessor. Assessors also interview staff, so the owner should be able to describe what the control protects and how a failure would show up in logs. Plan for that knowledge to be documented, not held by one person.

How long does it take to be ready for an SC-21 assessment?

NIST does not set a duration for readiness. NIST leaves implementation timelines to OMB Circular A-130 for federal systems, and its risk management FAQ says it does not estimate compliance costs. Readiness depends on scope: how many resolvers and zones are in the boundary, whether the current configuration is already documented, whether validation is already enabled, and how much evidence history exists. Ask any partner to state the timeline in writing, tied to the agreed scope and the assessment date, and to list the dependencies on your change windows and staff availability.

Can we inherit SC-21 from our cloud provider?

Partly, and only as far as the provider's documentation and your own configuration allow. A cloud provider may operate the resolver service, but your organization still has to show which resolver your systems use, that DNSSEC validation is enabled where you control the resolver, and that the inherited responsibility is documented in your system security plan. Review the provider's shared responsibility and compliance documentation, then confirm which parts are provider-operated and which parts you configure. Any inheritance should be written down and checked by your assessor, not assumed.

What does an implementation partner not do for SC-21?

An implementation partner does not own the control, issue an assessment report, or certify that SC-21 is met. At DeployOpen, the work covers preparing systems, configuration and evidence for an assessment, and the organization keeps ownership of its controls. Only an independent auditor, assessor or certification body issues reports or certificates. A partner also does not set your DNS architecture decisions for you, does not guarantee an assessment outcome, and does not maintain resolver operations after handover unless a support retainer is agreed in writing. Confirm these boundaries in the written scope before work starts.

Self-hosted tooling that produces SC-21 evidence

No single open-source tool proves that a recursive or caching resolver validates DNSSEC signatures on responses from authoritative servers. The evidence comes from the resolver's own configuration, plus surrounding records that show the resolver is the only path clients use for name resolution. Confirm the DNSSEC validation settings with the documentation of the resolver you choose (for example, the validation option in its configuration file), because the setting names and defaults differ between resolver products. Capture the effective configuration in version control, export it on a schedule, and keep the exported file as the artifact an assessor examines under the SC-21 configuration evidence.

OPNsense can document the traffic paths around the resolver. Its firewall rules pass, block or reject traffic by source, destination, port and protocol, and aliases group the resolver addresses so the rule set reads clearly. Enable logging on the rules that permit DNS traffic and review matches in the live log view. An assessor can then see whether clients reach only the approved resolvers and whether direct outbound DNS to external servers is blocked. Wazuh Security Configuration Assessment can check endpoint resolver settings against custom YAML policies, covering files, directories and running processes, and it recommends remediation for failed checks. Write a custom policy for the resolver configuration file your endpoints depend on, since the shipped policies are mostly based on CIS benchmarks and do not target a specific resolver.

Fleet policies ask devices yes or no questions as osquery queries, and the policies page shows which devices pass or fail each one. Use this to ask whether managed endpoints point only at the approved resolver addresses, which gives a per-device view that complements the server-side configuration export. Licenses differ by tool: Coraza is Apache-2.0, OPNsense is BSD-2-Clause, Wazuh is GPL-2.0-only and Fleet is MIT. Confirm the license terms with each project before you deploy, and confirm with your assessor which records they will accept as evidence, since no tool issues an SC-21 finding on its own.

SC-21 Secure name/address resolution service (recursive or caching resolver)