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

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Low, Moderate, High	System	None

Related controls: SC-20, SC-22

Control statement

Request and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.

NIST discussion

Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Systems that provide name and address resolution services for local clients include recursive resolving or caching domain name system (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Systems that use technologies other than the DNS to map between host and service names and network addresses provide some other means to enable clients to verify the authenticity and integrity of response data.

Withdrawn enhancements: SC-21(1).

Assessment objectives (SP 800-53A)

Objectives and methods for SC-21

Determine if:

• SC-21[01] data origin authentication is requested for the name/address resolution responses that the system receives from authoritative sources;
• SC-21[02] data origin authentication is performed on the name/address resolution responses that the system receives from authoritative sources;
• SC-21[03] data integrity verification is requested for the name/address resolution responses that the system receives from authoritative sources;
• SC-21[04] data integrity verification is performed on the name/address resolution responses that the system receives from authoritative sources.

Examine: System and communications protection policy; procedures addressing secure name/address resolution services (recursive or caching resolver); system design documentation; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; organizational personnel with responsibilities for managing DNS.

Test: Mechanisms supporting and/or implementing data origin authentication and data integrity verification for name/address resolution services.

Policy statement

• The System owner shall ensure the system requests and performs data origin authentication and data integrity verification on the name and address resolution responses it receives from authoritative sources. (SC-21)

From the System and Communications Protection Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SC-21 is the other half of SC-20: the resolvers your system uses must ask for and check the signatures on the DNS answers they get, so a forged or altered answer is rejected rather than used. NIST’s discussion allows two ways for each client: validate DNSSEC signatures itself, or use an authenticated channel to a recursive resolver that validates for it. Most clients take the second way, because most stub resolvers in operating systems cannot validate. SC-21 is in the Low, Moderate and High baselines.

Common implementations. DNSSEC validation turned on at the organization’s recursive resolvers, or a resolver service, such as a cloud provider’s resolver or a protective DNS service, that validates. NIST SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide (March 2026), covers the details:

• Validation needs two settings: validation turned on, and trust anchors configured; NIST says the internet root key should be the trust anchor (section 4.2.5).
• Automated trust anchor rollover turned on, with logs watched, since administrators may get no advance notice of a key rollover and manual updates are risky (section 4.2.6).
• A primary and backup time source reached securely, because validation depends on the correct time (section 4.3.1).
• Recursive resolvers accept queries only from internal hosts, and are not reachable from the internet (section 4.3).
• The link from clients to the validating resolver protected: on the organization’s network that can be an internal path, and for mobile and remote devices a secure tunnel back or an approved encrypted DNS service (sections 5.2 and 5.3). Encrypted DNS (DNS over TLS, HTTPS or QUIC) gives that link confidentiality and lets clients authenticate the resolver (section 4.2.1).
• Outbound DNS to the internet blocked except from the authorized resolvers, so clients cannot bypass validation and logging by using another resolver (sections 4.2.2 and 5.1).

Send resolver query logs and validation failures to monitoring; the system monitoring standard lists DNS among its network log sources. Section 5.2 notes that validation failures show up in the validator’s logs, not at the client, which only sees a general error.

Organization-defined parameters. SC-21 has no parameters. In the System and Communications Protection policy, the system owner ensures the system requests and performs data origin authentication and data integrity verification on the name and address resolution responses it receives from authoritative sources.

Evidence assessors ask for.

• The resolver configuration showing DNSSEC validation on and the trust anchor setting, or the provider’s documentation that its resolver validates
• A test: a query for a deliberately broken test domain fails, and a query for a correctly signed domain succeeds with the authenticated data flag set
• The DNS settings that endpoints and servers receive (DHCP or device management), pointing only to the approved resolvers
• Firewall rules that block outbound DNS, DNS over TLS and DNS over QUIC except from the resolvers
• Resolver logs reaching the monitoring service

Inheritance. The organization’s resolvers or protective DNS service are usually a common control; a cloud resolver’s validation is inherited from the provider, recorded in the system security plan from its customer responsibility matrix. The system owns its components’ DNS settings: that they use the approved resolvers and nothing else, including applications and containers that bring their own resolver settings.

Common findings.

• Validation turned off at the resolver, often after an outage blamed on DNSSEC and never turned back on.
• Servers or applications set to a public resolver, bypassing the organization’s validating resolvers and its logging.
• Remote devices using whatever resolver the local network offers, with no validation or encrypted channel.
• Trust anchors updated by hand, or not at all.

Enhancements in the Moderate baseline. SC-21 has no enhancements. SC-21(1) is withdrawn.

Federal systems (as of October 2026). OMB M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles (January 26, 2022), Section III.C, requires agencies to resolve DNS queries using encrypted DNS wherever it is technically supported. Agency resolvers must support DNS over HTTPS or DNS over TLS and use them upstream; endpoints must turn encrypted DNS on in applications and operating systems where available; and custom-developed software that makes DNS requests must support it. The memorandum notes that DNSSEC does not encrypt DNS data in transit; SP 800-81 Rev. 3 section 3.8 adds that encrypted DNS protects only the transaction and does not authenticate the data in responses, so an agency needs both encrypted DNS and the validation SC-21 requires.

Artifacts

• System and Communications Protection Decision Worksheet
• System and Communications Protection Policy