SC-21: Secure Name/Address Resolution Service (Recursive or Caching Resolver)

SC-21 requires your recursive or caching DNS resolver to request and verify DNS response authenticity and integrity from authoritative sources, typically by validating signed DNS data rather than trusting unsigned cacheable answers. To operationalize it, you must enable DNSSEC validation (or an equivalent authenticated mechanism), enforce secure resolver configuration, and retain evidence that validation is active and monitored. ¹

Key takeaways:

• Turn on DNS response origin and integrity verification at the resolver (commonly DNSSEC validation), not just at endpoints. ¹
• Prove it with configs, test outputs, monitoring, and change records that show validation stays enabled over time. ¹
• Scope matters: cover enterprise resolvers, cloud DNS forwarders, and any “hidden” resolvers in appliances and platforms.

The sc-21: secure name/address resolution service (recursive or caching resolver) requirement is about preventing DNS manipulation from becoming an easy path into your environment. If a resolver accepts forged or altered DNS responses, attackers can redirect users and systems to malicious infrastructure, bypassing other controls by exploiting trust in name resolution. SC-21 narrows the expectation to a specific, testable behavior: the system should request and perform data origin authentication and data integrity verification on DNS responses received from authoritative sources. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize SC-21 is to treat it as a resolver control with clear ownership (Network/Security Engineering), defined technical settings (validation enabled, safe forwarding paths, logging), and recurring evidence (config snapshots, validation tests, monitoring alerts, and change management records). This page gives requirement-level implementation guidance so you can (1) scope where recursive/caching resolution happens, (2) enforce authenticated/integrity-checked DNS answers, and (3) show auditors repeatable proof that the control works as designed.

Regulatory text

Requirement excerpt: “Request and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.” ¹

Operator interpretation (what you must do)

You must configure your recursive or caching DNS resolver so it does not blindly trust DNS responses. The resolver needs a mechanism to authenticate the origin of DNS data and verify the integrity of the response received from authoritative sources. In practice, most enterprises meet this by enabling DNSSEC validation on recursive resolvers (or using a DNS resolution service that performs validation and returns only validated answers), then enforcing and monitoring that posture.

The audit-standard reading: the resolver should validate, not just “support,” origin and integrity checks. Evidence must show the checks are active in production and remain active after changes.

Plain-English interpretation of the requirement

SC-21 expects you to stop DNS spoofing/cache poisoning from rewriting where your users and systems connect. If your resolver caches forged answers, everything downstream inherits that bad routing decision.

Think in outcomes:

• Origin authentication: you can confirm the DNS data came from the rightful authoritative chain, not an attacker-in-the-middle. ¹
• Integrity verification: you can confirm the DNS response was not altered in transit. ¹

Who it applies to (entity and operational context)

SC-21 applies to:

• Federal information systems and
• Contractor systems handling federal data (including many regulated contractor environments aligned to NIST SP 800-53). ¹

Operationally, it applies anywhere your environment performs recursive or caching DNS resolution, including:

• Central enterprise resolvers (on-prem).
• DNS forwarders in cloud networks (VPC/VNet DNS forwarders, resolver endpoints, managed DNS forwarding tiers).
• Security stacks that “help” with DNS (secure web gateways, DNS filtering products) if they perform recursion/caching on your behalf.
• Local resolver components inside platforms/appliances that can bypass your enterprise resolvers if misconfigured.

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

Step 1: Assign ownership and define scope

1. Name a control owner: usually Network Engineering or Security Engineering; GRC owns tracking and evidence.
2. Inventory resolvers and forwarders:
   • Corporate recursive resolvers and their IPs.
   • Cloud resolver endpoints and forwarding rules.
   • Third-party DNS security services that act as recursive resolvers.
3. Define “in scope” systems: any system that receives DNS responses from authoritative sources directly or indirectly through a caching/recursive function. SC-21 is about the resolver behavior, not only the client.

Deliverable: a scoped resolver architecture diagram and resolver asset list.

Step 2: Choose the verification mechanism (implementation decision)

Pick an approach that satisfies “request and perform” origin and integrity checks. ¹

Common patterns:

• Enterprise recursive resolvers with DNSSEC validation enabled.
• Managed recursive DNS that performs validation, where you can prove validation is enabled and enforced by policy/config and monitored.

Decision notes for GRC:

• If you outsource recursion to a third party, SC-21 becomes a third-party due diligence and configuration assurance problem. You still need evidence that validation is occurring, plus contractual and operational hooks to ensure it stays enabled.

Step 3: Implement secure resolver configuration (technical minimums)

Work with engineering to implement and document:

1. Enable validation on recursive resolvers (e.g., DNSSEC validation mode enabled).
2. Define the trust anchor / validation chain behavior consistent with your resolver platform.
3. Fail-safe behavior:
   • Determine and document what happens on validation failure (blocked, SERVFAIL, or policy-defined handling).
   • Make that behavior consistent across locations.
4. Harden forwarding paths:
   • Restrict who can query the resolver (network ACLs, firewall rules).
   • Prevent clients from bypassing controlled resolvers (egress controls for direct external DNS where feasible).
5. Logging and monitoring:
   • Log validation failures and anomalies in a way your SOC can detect patterns.
   • Alert on configuration drift (validation toggled off, forwarders changed).

Your goal is a resolver that validates answers, limits who can use it, and produces evidence.

Step 4: Prove it works (verification tests you can run on demand)

Auditors will ask, “How do you know it’s validating?” Build a repeatable test script and keep outputs:

• Query a known signed domain and show the resolver reports validation success (tooling depends on platform).
• Query a deliberately broken DNSSEC test domain and show failure consistent with your policy (blocked / SERVFAIL).
• Demonstrate caching behavior does not serve altered/unsigned data when validation is expected.

Keep tests simple and repeatable; run them after major DNS changes and during control testing cycles.

Step 5: Operationalize change control and recurring assurance

1. Configuration-as-evidence: keep versioned resolver configs (or screenshots/exports if a managed console).
2. Change tickets: every resolver change references SC-21 impact, approver, and rollback plan.
3. Recurring reviews:
   • Review resolver settings and forwarding targets.
   • Review a sample of validation failure logs for investigation/false positives.
4. Third-party oversight (if applicable):
   • Contract language: DNSSEC validation enabled; notification before material DNS platform changes.
   • Obtain periodic attestations or configuration exports from the third party.

Step 6: Map the requirement to your control library and evidence calendar

You want SC-21 to be “assignable” and “testable”:

• One control statement that matches the SC-21 excerpt. ¹
• One owner.
• A list of artifacts that can be produced in an audit without scrambling.

Daydream can help here by mapping SC-21 to an owner, implementation procedure, and recurring evidence artifacts so the requirement doesn’t die in a spreadsheet. ¹

Required evidence and artifacts to retain

Maintain evidence that is both design (how it’s configured) and operating effectiveness (proof it stayed that way).

Core artifacts

• Resolver inventory (systems/services, IPs/endpoints, environments).
• Resolver configuration exports showing validation enabled.
• Architecture diagram showing resolution flow (clients → resolver → authoritative sources/forwarders).
• Test records:
  • Validation success case output.
  • Validation failure case output (expected behavior).
• Logging/monitoring evidence:
  • Sample logs of validation events/failures.
  • Alert rules and recent alert samples (even if benign).
• Change management:
  • Recent change tickets for DNS/resolver changes.
  • Approval and implementation notes referencing validation impact.
• Third-party documents (if recursion is outsourced):
  • Contract/SOW clauses tied to resolver validation behavior.
  • Third-party configuration attestations or admin console exports.

Common exam/audit questions and hangups

“Where does recursion happen in your environment?”
Hangup: teams forget cloud resolver endpoints, SD-WAN appliances, or security products that do DNS on-device.

“Show me that origin authentication and integrity checks are performed.”
Hangup: “We support DNSSEC” is not the same as “validation is enabled and enforced.” SC-21 expects performance of verification. ¹

“What happens when validation fails?”
Hangup: inconsistent behavior across sites or exceptions created for “problem domains” without risk acceptance.

“How do you prevent bypass?”
Hangup: endpoints configured with public DNS or hardcoded resolvers; split-tunnel VPN that sends DNS outside your controls.

“How is this controlled in third-party DNS?”
Hangup: no contractual assurance, no evidence exports, no monitoring visibility.

Frequent implementation mistakes and how to avoid them

1. Enabling validation on one resolver tier only
   Avoidance: confirm the actual recursive/caching layer validates. If you forward to a third party, validate there or validate before forwarding, then document the flow.

2. No evidence of ongoing operation
   Avoidance: schedule periodic config captures and keep test outputs tied to dates and change events.

3. Exceptions without governance
   Avoidance: require documented risk acceptance and expiry for any domain or segment that bypasses validation.

4. Assuming endpoints are covered
   Avoidance: enforce network controls so clients use approved resolvers, then validate at the resolver.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. From a risk standpoint, failure to meet SC-21 increases exposure to DNS spoofing, cache poisoning, and traffic redirection that can defeat user awareness and complicate incident response. The compliance risk is also practical: SC-21 is easy for assessors to test because resolver settings and validation behavior are observable.

Practical execution plan (30/60/90-day)

Time-boxing helps execution, but exact durations depend on environment complexity. Use these phases as an operating plan.

Next 30 days (stabilize scope and baseline)

• Confirm control owner and stakeholders (NetEng, SecEng, SOC, GRC).
• Inventory all recursive/caching resolvers and DNS forwarders (on-prem, cloud, third party).
• Capture current configs and decide where validation must be enabled to satisfy SC-21. ¹
• Draft the SC-21 control narrative and evidence list in your GRC system.

Days 31–60 (implement and prove)

• Enable validation on in-scope resolvers or confirm it is enabled in managed DNS.
• Implement logging and alerting for validation failures and config drift.
• Run and document validation tests (success and failure cases) for each resolver tier.
• Close bypass paths where feasible (network egress controls, endpoint DNS settings baselines).

Days 61–90 (operationalize and audit-ready)

• Put resolver config snapshots and test runs on a recurring evidence calendar.
• Add change-control requirements for DNS changes (pre-approval + post-change validation tests).
• For third parties: update contract language and collect initial attestation/config evidence.
• Run an internal mini-assessment: produce the full evidence pack as if an auditor asked today.

Frequently Asked Questions

Does SC-21 require DNSSEC specifically?

SC-21 requires data origin authentication and integrity verification for resolver responses, but it does not name a specific technology in the excerpt. DNSSEC validation is the most common way to meet the requirement because it directly supports origin and integrity checks at the resolver. ¹

If we use a third-party DNS filtering service, are we covered?

Only if the third party actually performs the verification and you can prove it with configuration evidence and monitoring or attestations. Treat it as third-party due diligence plus technical configuration assurance, not an automatic pass.

What evidence is strongest for auditors?

Config exports showing validation enabled plus dated test outputs demonstrating validated and failed-validation behavior are usually decisive. Add change tickets and monitoring artifacts to prove the control stays in place over time. ¹

How do we handle domains that fail validation but are “business critical”?

Create a documented exception with risk acceptance, defined compensating controls, and an expiry date tied to remediation actions. Keep the exception list short and reviewed by Security, not only Network.

Do endpoints need any changes to meet SC-21?

SC-21 is a resolver control, but endpoints can bypass it if they use unauthorized DNS servers. Enforce approved resolvers through network policy and endpoint configuration baselines so resolver-side validation actually protects traffic.

What’s the quickest way to make SC-21 audit-ready in a distributed environment?

Standardize on a small number of approved recursive resolver patterns (on-prem and cloud), publish a hardened configuration baseline, and collect recurring evidence automatically. Daydream can track the owner, procedure, and evidence calendar so audits don’t turn into ad hoc evidence hunts. ¹

Footnotes

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