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

Quick-reference card

What this control requires

SC-21 requires your recursive and caching domain name system (DNS) resolvers to validate the authenticity and integrity of every name resolution response before trusting it. Without this validation, your systems accept DNS answers at face value, which means an attacker who poisons a cache or spoofs a response can redirect traffic to malicious infrastructure without triggering a single alert.

In practice, you need your DNS client resolvers to either perform domain name system security extensions (DNSSEC) signature validation directly or connect through authenticated channels to recursive resolvers that handle validation on their behalf. The goal is data origin authentication and data integrity verification for every resolution response your systems consume. If your environment uses protocols other than DNS for name-to-address mapping, those protocols must provide equivalent assurance that responses haven’t been tampered with.

This requirement exists because DNS is foundational infrastructure. Every application, service, and user session depends on accurate name resolution. When that layer is compromised, the downstream consequences cascade across your entire environment, from credential harvesting and data exfiltration to service disruption and supply chain compromise.

Why it matters

Most organizations treat DNS as a utility that “just works,” and that assumption is exactly what creates risk. Recursive and caching resolvers sit at a chokepoint in your network architecture. If an attacker can manipulate the answers those resolvers return, they can silently redirect users and services to infrastructure they control.

Failure to maintain SC-21 introduces direct audit risk. Assessors evaluating your System and Communications Protection controls will look for evidence that your resolvers validate DNSSEC signatures or use authenticated channels to resolvers that do. If that evidence is missing, the control is marked as not satisfied, which can result in certification delays, conditional authorization to operate (ATO), or findings that escalate during continuous monitoring reviews.

The consequences extend beyond audit. Without data origin authentication on DNS responses, your organization lacks the ability to distinguish a legitimate answer from a forged one. Every system that relies on those poisoned answers inherits the compromise.

What attackers exploit

• Cache poisoning attacks inject forged DNS records into a caching resolver’s store, redirecting all downstream queries to attacker-controlled infrastructure until the poisoned cache entry expires
• DNS spoofing involves sending fabricated responses that arrive before the legitimate authoritative answer, causing the resolver to accept and cache the spoofed record
• Person-in-the-middle interception targets unencrypted DNS traffic between stub resolvers and recursive resolvers, modifying responses in transit
• Recursive resolver hijacking exploits misconfigured or publicly accessible resolvers to serve manipulated answers at scale, affecting every client that depends on the compromised resolver

How to implement

The core challenge with SC-21 is that many environments run recursive resolvers inherited from initial network builds, with no DNSSEC validation enabled and no authenticated transport between clients and resolvers. Retrofitting validation requires changes to resolver configuration, client settings, and monitoring infrastructure.

For your organization

Step 1 — Enable DNSSEC validation on recursive resolvers

Configure your recursive DNS resolvers to perform full DNSSEC signature validation. The specific configuration depends on your resolver software, but the core requirement is the same: the resolver must check the chain of trust from the root zone down to the queried domain, validating digital signatures at each delegation. Maintain up-to-date root trust anchors through automated rollover mechanisms such as RFC 5011.

Step 2 — Secure the channel between clients and resolvers

Your stub resolvers, which are the DNS clients on endpoints and servers, need authenticated channels to your validating recursive resolvers. Deploy DNS over TLS (DoT) or DNS over HTTPS (DoH) between clients and internal resolvers. Where encrypted transport isn’t feasible, restrict resolver access to trusted network segments through firewall rules and access control lists.

Step 3 — Restrict and harden resolver access

Limit which systems can query your recursive resolvers. Disable open recursion on all resolvers so they only serve authorized clients. Apply response rate limiting to mitigate amplification attacks and reduce the window for cache poisoning attempts.

Step 4 — Monitor and log resolution activity

Enable query and response logging on your recursive resolvers. Feed those logs into your security information and event management (SIEM) platform. Create detection rules for anomalies such as DNSSEC validation failures, unexpected resolution patterns, and queries to newly observed domains.

Step 5 — Test validation regularly

Periodically verify that DNSSEC validation is functioning by querying known signed domains and confirming that your resolvers correctly reject invalid signatures. Include DNS resolution integrity checks in your vulnerability scanning and penetration testing programs.

Common mistakes to avoid

• Enabling DNSSEC validation but failing to automate trust anchor updates, causing validation failures after key rollovers
• Running resolvers that accept queries from any source on the network
• Deploying encrypted DNS transport externally but leaving internal resolver-to-client traffic unprotected
• Treating DNS monitoring as a network operations concern rather than a security monitoring requirement

For your vendors

Questionnaire questions to include

Ask vendors whether their recursive DNS resolvers perform DNSSEC signature validation on all responses. Request confirmation that client connections to recursive resolvers use authenticated and encrypted transport. Ask how they monitor for DNS resolution anomalies and what their response process is when DNSSEC validation failures occur.

Evidence to request

Request resolver configuration documentation showing DNSSEC validation is enabled. Ask for network diagrams illustrating how DNS traffic flows between clients, recursive resolvers, and authoritative servers. Request logs or dashboards demonstrating that DNSSEC validation is active and monitored. Ask for their DNS security policy or the relevant sections of their system security plan that address name resolution integrity.

Red flags during assessment

Watch for vendors who cannot demonstrate DNSSEC validation is active on their resolvers. If a vendor’s resolver configuration shows open recursion enabled for all network segments, that indicates a broader DNS hardening gap. Inability to produce DNS query logs or monitoring dashboards suggests the vendor lacks visibility into resolution activity. Vendors who rely solely on network perimeter controls without validating DNS response authenticity are not satisfying the intent of SC-21.

Verification approach

Where possible, perform technical validation by querying the vendor’s resolver infrastructure with known DNSSEC-signed domains and confirming correct behavior. Review their most recent audit reports or assessment documentation for findings related to DNS security controls. Cross-reference their stated DNS architecture against the evidence they provide to identify inconsistencies.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for this control.

Related controls

• SC-20 — Secure Name/Address Resolution Service (Authoritative Source): SC-20 addresses the authoritative side of DNS security, requiring that authoritative name servers provide data origin authentication and integrity verification artifacts. SC-21 complements SC-20 by requiring that the recursive or caching resolvers consuming those responses validate them.
• SC-22 — Architecture and Provisioning for Name/Address Resolution Service: SC-22 focuses on the fault tolerance and geographic distribution of your DNS infrastructure. While SC-21 addresses the integrity of individual resolution responses, SC-22 ensures that the overall architecture supporting name resolution remains available and resilient.

Frequently asked questions

What is NIST SP 800-53 SC-21

SC-21 is the NIST SP 800-53 control that requires your recursive and caching DNS resolvers to validate the authenticity and integrity of name resolution responses through DNSSEC signature verification or authenticated channels. It applies across LOW, MODERATE, and HIGH baselines, making it a universal requirement for federal systems and any organization aligning to the framework. The control targets data origin authentication and data integrity verification, ensuring that forged or tampered DNS responses don’t propagate through your infrastructure.

What happens if SC-21 is not implemented

Without SC-21, your recursive resolvers accept DNS responses without verifying their origin or integrity, leaving your environment vulnerable to cache poisoning and DNS spoofing attacks. Attackers can redirect traffic to malicious infrastructure without detection, compromising every system that depends on accurate name resolution. From a compliance perspective, assessors will flag the absence of DNSSEC validation and authenticated resolver channels as a control failure, which can delay authorization decisions or trigger findings during continuous monitoring.

How do you audit SC-21

Auditing SC-21 starts with examining resolver configuration exports to confirm DNSSEC validation is enabled and trust anchors are current. Assessors verify that stub resolvers connect to recursive resolvers through authenticated channels such as DNS over TLS or DNS over HTTPS. They also review DNS query logs and monitoring dashboards for evidence that DNSSEC validation failures generate alerts, and they test the resolver’s behavior against known signed domains to confirm it correctly rejects invalid signatures.

What is the difference between SC-20 and SC-21

SC-20 governs the authoritative side of DNS security, requiring that authoritative name servers provide digital signatures and other artifacts that enable response validation. SC-21 governs the client side, requiring that recursive and caching resolvers perform that validation before trusting a response. Together, they form a complete chain of trust: SC-20 ensures authoritative servers produce verifiable answers, and SC-21 ensures consuming resolvers verify them.