Secure Name/Address Resolution Service (Recursive or Caching Resolver)

To meet the Secure Name/Address Resolution Service (Recursive or Caching Resolver) requirement, you must ensure your systems request and verify both the authenticity and integrity of DNS resolution responses received from authoritative sources, typically by enforcing DNSSEC validation on recursive/caching resolvers. Operationalize this by configuring validating resolvers, controlling forwarding paths, monitoring validation failures, and retaining configuration and test evidence. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Configure recursive/caching resolvers to perform DNSSEC validation and reject bogus responses from authoritative sources. (NIST Special Publication 800-53 Revision 5)
• Control and document resolver architecture (internal resolvers, forwarders, and any third-party DNS) so validation is not bypassed. (NIST Special Publication 800-53 Revision 5)
• Keep evidence: resolver configs, change records, DNSSEC validation tests, and monitoring showing resolver health and failures. (NIST Special Publication 800-53 Revision 5)

SC-21 is a DNS trust requirement: if your environment relies on recursive or caching DNS resolution, you need protection against forged or altered DNS responses that can redirect users and systems to attacker-controlled endpoints. In practice, auditors look for one thing: are your resolvers validating the origin and integrity of responses from authoritative DNS sources, and can you prove it with configurations, tests, and logs. (NIST Special Publication 800-53 Revision 5)

This requirement is easy to “half-implement” in a way that still fails an assessment. Common failure modes include using a third-party recursive resolver that does not validate DNSSEC, forwarding internal DNS queries to an upstream that strips DNSSEC data, allowing endpoints to use arbitrary public resolvers, or enabling validation but not monitoring failures. Your goal is a DNS resolution architecture where validation happens deterministically, bypass paths are controlled, and operations teams have clear runbooks for failures. (NIST Special Publication 800-53 Revision 5)

This page translates SC-21 into concrete implementation steps, audit-ready evidence, and an execution plan you can hand to network, platform, and security teams.

Regulatory text

Requirement (SC-21): “Request and perform data origin authentication and data integrity verification on the name and address resolution responses the system receives from authoritative sources.” (NIST Special Publication 800-53 Revision 5)

What the operator must do: Configure and operate DNS resolution (recursive/caching resolvers and any forwarders) so the system can validate that DNS answers came from the legitimate authoritative source and were not modified in transit. For most organizations, this maps to DNSSEC validation on recursive resolvers plus architectural controls that prevent bypassing that validation path. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation

You must prevent DNS spoofing/poisoning from quietly redirecting traffic. If a system asks “what IP is this name,” you need technical controls that verify the response is authentic and intact, not just “whatever answer arrived first.” (NIST Special Publication 800-53 Revision 5)

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers and Federal Agencies operating under FedRAMP Moderate expectations aligned to SC-21. (NIST Special Publication 800-53 Revision 5)

Operationally, it applies wherever DNS recursion/caching occurs, including:

• Enterprise or cloud-hosted recursive resolvers (central DNS resolvers used by servers, containers, and endpoints).
• VPC/VNet DNS forwarding architectures (on-prem to cloud, cloud to on-prem).
• Managed DNS resolver services and any third-party recursive DNS service you rely on.
• Split-horizon DNS setups (internal zones plus public recursion).

Systems most affected:

• Identity and SSO endpoints, patch/update services, API gateways, CI/CD, and any egress-restricted workloads that depend on DNS to reach approved domains. If DNS can be forged, many downstream controls can be bypassed.

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

1) Inventory and pin down your “DNS resolution path”

Build a simple resolver dataflow that answers:

• What resolvers do workloads and endpoints query by default?
• Do you run a recursive/caching resolver, or do you forward to a third party?
• Where does validation occur (if anywhere)?
• What are the bypass paths (hardcoded resolvers, DHCP overrides, container configs, developer workstations, break-glass networks)?

Deliverable: a one-page diagram and a resolver inventory (hostname/IP, environment, owner, purpose).

2) Choose an implementation pattern that guarantees validation

Pick one of these patterns and standardize it:

Pattern A: Internal validating resolvers (preferred for control)

• Run recursive resolvers you manage (on-prem or in cloud).
• Enable DNSSEC validation.
• Allow clients to query only these resolvers.

Pattern B: Managed recursive resolver with DNSSEC validation

• Use a cloud/third-party recursive DNS service only if it supports DNSSEC validation and you can show it is enabled.
• Treat the provider as a third party in your risk process: contract language, shared responsibility notes, and configuration evidence.

Non-goal: “Some clients validate sometimes.” Auditors will expect a consistent architecture. (NIST Special Publication 800-53 Revision 5)

3) Configure DNSSEC validation on recursive/caching resolvers

Your resolver(s) should:

• Perform DNSSEC validation for signed zones.
• Treat validation failures as security events (SERVFAIL/bogus) rather than silently accepting forged data.
• Maintain an up-to-date trust anchor set (commonly the root trust anchor) using an operationally supported mechanism.

Evidence tip: screenshots aren’t enough on their own; export configuration snippets or CLI output that proves validation is enabled and shows relevant settings.

4) Prevent bypass: enforce resolver use at the network and endpoint layers

Validation only helps if clients actually use the validating resolver.

Implement controls such as:

• Egress controls: block outbound DNS (TCP/UDP 53, and where applicable DNS over TLS/HTTPS destinations) from client networks except from approved resolver IPs.
• DHCP and image baselines: set resolvers via DHCP, endpoint management, golden images, and cloud-init.
• Kubernetes/container guardrails: standardize cluster DNS settings; prevent pods from using arbitrary resolvers through network policies where feasible.
• Exception handling: define when direct external DNS is allowed (rare), how it’s approved, and how it’s monitored.

5) Handle “DNSSEC-unfriendly” realities without breaking compliance intent

Real environments hit edge cases:

• Some domains are unsigned (DNSSEC doesn’t apply). Your resolver still provides service; validation simply isn’t performed for those zones.
• Misconfigured DNSSEC on external domains can cause failures. You need a troubleshooting path that does not devolve into “turn validation off.”

Create a runbook:

• How to confirm a failure is DNSSEC-related (resolver logs/metrics).
• Temporary mitigations that keep validation intact (for example, using alternate authoritative paths is rarely in your control; more often you wait for domain owners to fix).
• Who approves any emergency exception and how it is time-bounded and reviewed.

6) Monitoring, alerting, and operational checks

Auditors commonly ask: “How would you know this stopped working?”

Minimum monitoring set:

• Resolver health and latency.
• DNSSEC validation failure counts and top failing domains.
• Configuration drift detection on resolver settings.
• Change monitoring on forwarder targets and route tables that could bypass validation.

7) Document shared responsibility and third-party dependencies

If any part of recursion/validation is provided by a third party:

• Document what the provider guarantees vs. what you configure.
• Keep proof that DNSSEC validation is enabled (tenant settings, configuration exports).
• Track the dependency in your third-party inventory and due diligence workflow.

Practical note: Daydream can help here by mapping SC-21 to specific resolver components, collecting evidence from infrastructure owners, and keeping an audit-ready record of DNS third-party dependencies and control ownership without chasing screenshots across tickets.

Required evidence and artifacts to retain

Keep artifacts that prove design, configuration, operation, and oversight:

1. Architecture

• Resolver dataflow diagram (clients → resolvers → forwarders → authoritative).
• List of approved resolvers, networks, and environments.

2. Configuration evidence

• Resolver configuration exports showing DNSSEC validation enabled.
• Forwarder configurations and constraints (approved upstreams only).
• Network controls blocking unauthorized DNS egress (firewall rules, security groups, policies).

3. Operational evidence

• Sample logs/metrics showing DNSSEC validation activity and failures.
• Alert definitions and on-call/runbook references.
• Change records for resolver configuration and trust anchor updates.

4. Governance

• DNS exception process and approvals.
• Third-party documentation showing how managed DNS validation is provided/configured.

Common exam/audit questions and hangups

Auditors and 3PAOs often focus on:

• “Where exactly does validation occur?” If you forward to an upstream resolver, they will test whether your upstream validates. (NIST Special Publication 800-53 Revision 5)
• “Can endpoints bypass it?” Expect questions about outbound DNS blocking and the handling of DoH/DoT.
• “Show me proof.” They may ask for config outputs, not narratives.
• “What happens on failure?” If the answer is “we turn it off,” expect a finding or at least a significant risk discussion.

Frequent implementation mistakes (and how to avoid them)

1. Assuming your ISP/cloud resolver validates DNSSEC

• Fix: verify and document; if you cannot prove validation is enabled, treat it as not compliant.

2. Forwarding that strips DNSSEC records

• Fix: validate the full path. Run a test from the client network and confirm the validating resolver is the one answering, with validation active.

3. Allowing “temporary” bypass that becomes permanent

• Fix: time-bound exceptions, require CISO/CCO-visible approval, and add monitoring for direct-to-internet DNS.

4. No monitoring for DNSSEC failures

• Fix: add alerts on spikes in validation failures and on resolver config drift.

5. Treating internal-only zones as the whole scope

• Fix: SC-21 concerns responses from authoritative sources; your public recursion path is usually in scope even if internal zones exist. (NIST Special Publication 800-53 Revision 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should anchor risk discussions to the control intent and assessment outcomes rather than specific penalties. Practically, SC-21 gaps create a straightforward attack path: DNS poisoning or spoofed answers can redirect authentication, updates, logging endpoints, and API calls. For FedRAMP work, recurring DNS findings also slow ATO timelines because they touch core network trust and are hard to explain away as “low impact.” (NIST Special Publication 800-53 Revision 5)

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

Use this as an operator’s rollout path; adjust sequencing to your change windows.

First 30 days (Immediate)

• Complete resolver inventory and resolution-path diagram.
• Decide standard pattern (internal validating resolvers vs managed validating resolver).
• Identify bypass paths (public resolvers, DoH/DoT, dev networks) and document them.
• Draft the DNS exception/runbook workflow and owners.

By 60 days (Near-term)

• Enable DNSSEC validation on designated resolvers (or confirm/enable on managed resolver).
• Implement network controls to force resolver usage (block direct DNS where feasible).
• Stand up monitoring: validation failures, resolver availability, and config drift.
• Capture initial evidence pack: configs, tests, and monitoring screenshots/exports.

By 90 days (Operationalized)

• Roll enforcement to all major environments (prod, staging, corporate, CI/CD runners) with exceptions tracked.
• Run tabletop for a DNSSEC failure scenario and update runbooks.
• Close documentation gaps: shared responsibility notes, third-party records, and audit narratives tied to artifacts.
• Move evidence collection into a recurring compliance workflow (ticketed changes and periodic validation tests).

Frequently Asked Questions

Does SC-21 require DNSSEC everywhere?

It requires requesting and performing origin authentication and integrity verification on responses from authoritative sources. In practice that means DNSSEC validation where DNSSEC is available, plus resolver architecture that prevents accepting forged responses. (NIST Special Publication 800-53 Revision 5)

If we use a third-party recursive DNS service, can we still meet the requirement?

Yes, if the service performs DNSSEC validation and you can prove it is enabled and not bypassed. Treat the provider as a third party dependency and retain configuration evidence and responsibility documentation. (NIST Special Publication 800-53 Revision 5)

What evidence will an assessor accept for “data origin authentication and integrity verification”?

Expect to provide resolver configuration outputs showing validation settings, test results demonstrating validation behavior, and logs/metrics showing ongoing operation and failure handling. Narratives without artifacts usually fail. (NIST Special Publication 800-53 Revision 5)

How do we handle domains that break with DNSSEC validation?

Use a runbook that diagnoses the issue and routes it for remediation without permanently disabling validation. If an exception is unavoidable, time-bound it, document compensating controls, and retain approval records. (NIST Special Publication 800-53 Revision 5)

Do endpoints using DNS over HTTPS (DoH) create a compliance problem?

They can, because DoH can bypass your validating resolver and your logging/monitoring. Address this with endpoint policy and network controls where possible, and document any approved exceptions with monitoring. (NIST Special Publication 800-53 Revision 5)

How should we scope this in cloud environments with multiple VPCs/VNets?

Scope to every place recursion/caching occurs and every workload that performs name resolution. Standardize on a small set of validating resolvers or a managed validating resolver service, then enforce resolver paths through routing and security controls. (NIST Special Publication 800-53 Revision 5)