SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver) asks your system to request and perform data origin authentication and data integrity verification on the name and address resolution responses it receives from authoritative sources.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from.
This is the client side of SC-20. SC-20 says authoritative servers should sign their answers. SC-21 says your resolvers should check those signatures. The guidance says each client either validates on its own or uses authenticated channels to trusted validation providers. Recursive resolving or caching DNS servers that serve local clients are the typical systems in scope. SC-21.1 adds data origin and integrity as an enhancement.
What it means in practice
Check what resolver your servers and laptops use. If it is your own recursive server, enable DNSSEC validation. If it is a public or cloud provider resolver, confirm it validates and that your clients reach it over an authenticated channel, such as DNS over TLS or HTTPS, so the answer cannot be tampered with between the resolver and the client.
The common objection is that DNSSEC validation breaks things. It can, when a domain is misconfigured, and that is the point. A failure means the resolver could not prove the answer was genuine. Plan for it by having a documented path for temporarily handling a broken zone, with approval and an expiry, rather than turning validation off globally.
Think about where resolution happens across your estate. Office networks use a resolver provided by the router or ISP. Laptops move between networks. Containers and virtual machines use whatever the cloud gives them. Each is a place where validation can be missing. A simple spreadsheet of environments, resolver in use, validation yes or no, and transport encrypted yes or no gives a reviewer exactly what they need.
Encrypted transport matters for the last hop. DNSSEC proves the answer came from the authoritative source, but the path between your client and a non validating resolver is still open to tampering. The guidance says clients either validate themselves or have authenticated channels to trusted validators, so make sure your evidence covers that branch.
Finally, log resolver failures. A spike in validation failures for a domain is worth a look because it can point to an attack or to a misconfigured partner.
Evidence to collect
- The list of recursive resolvers in use and who operates them.
- Resolver configuration showing DNSSEC validation enabled.
- A test showing a deliberately broken signed domain fails to resolve.
- Client or endpoint settings pointing to the approved resolvers.
- Provider documentation if validation is handled by a third party.
Common gaps
Validation is off by default on older resolver software. Laptops use the coffee shop resolver because nobody pins settings. Cloud workloads use the cloud provider default and nobody has recorded that it validates. Fallback to insecure resolvers happens silently on failure.
How to implement it
Pick approved resolvers and configure endpoints through device management. Turn on validation. Use encrypted transport between clients and resolvers. Then run a test against a known bad signature test domain and save the output with the date.
Add resolver changes to your change management process, because a casual switch can remove validation without anyone noticing.
Quick check
How do I prove validation works?
Resolve a domain with a deliberately invalid signature and show that your resolver refuses it. Save the output.
Is this only for companies that run DNS servers?
No. Even if you rely on a provider resolver, record which one and show that it validates.
