Quick-reference card
| Field | Value |
|---|---|
| Control ID | SC-20 |
| Control name | Secure Name/Address Resolution Service (Authoritative Source) |
| Framework | NIST SP 800-53, Revision 5 |
| Control family | System and Communications Protection (SC) |
| Baselines | LOW MODERATE HIGH |
| Implementation level | System (First Party and Third Party) |
| Risk severity | Medium |
What this control requires
SC-20 requires your organization to provide data origin authentication and integrity verification artifacts alongside every authoritative name resolution response returned to external queries. In practice, this control means your domain name system (DNS) infrastructure must prove that the answers it gives haven’t been tampered with in transit.
The control has two distinct obligations. First, authoritative DNS servers must attach cryptographic proof to the resource records they serve so that resolvers can verify authenticity. Second, when your zones sit within a hierarchical namespace, you must indicate the security status of child zones and support verification of a chain of trust between parent and child domains. For most organizations, this translates to deploying DNS Security Extensions (DNSSEC) across all externally facing authoritative zones.
These requirements exist because DNS was designed without built-in authentication. Without origin verification, any response a resolver receives could be forged, redirecting users to attacker-controlled infrastructure. SC-20 closes that gap at the authoritative source, ensuring the data leaving your DNS servers carries the cryptographic signatures needed for downstream validation.
Why it matters
DNS is one of the most heavily targeted layers of internet infrastructure, yet many organizations treat authoritative zone security as an afterthought. When your authoritative DNS servers lack data origin authentication, every external client trusting those responses inherits your exposure.
The compliance risk is direct. SC-20 appears in all three NIST baselines (LOW, MODERATE, and HIGH), meaning auditors expect evidence of authoritative-source protections regardless of your system’s impact level. Failing to demonstrate DNSSEC digital signatures and delegation signer resource records during an assessment creates a documented finding that can delay or block an authorization to operate.
In practice, the absence of these protections leaves your organization’s DNS responses indistinguishable from forged ones. Attackers don’t need to compromise your servers when they can inject fraudulent answers that resolvers have no way to reject.
What attackers exploit
- Cache poisoning and DNS spoofing: Without DNSSEC signatures on authoritative responses, attackers inject forged resource records into resolver caches, redirecting traffic to malicious hosts.
- Zone delegation manipulation: Unsigned delegations let attackers intercept the parent-to-child trust chain, enabling them to serve fraudulent records for subdomains.
- On-path interception: Attackers positioned between authoritative servers and resolvers modify responses in transit when no integrity verification artifacts exist.
- Domain hijacking: Weak registrar controls combined with unsigned zones allow attackers to re-delegate authoritative name servers entirely, taking over DNS resolution for a domain.
How to implement
The most common implementation failure isn’t choosing the wrong cryptographic algorithm. It’s treating DNSSEC deployment as a one-time project rather than an ongoing operational commitment that requires key management, monitoring, and incident response procedures.
For your organization
Start by inventorying every authoritative DNS zone your organization controls, including production domains, staging environments, and any zones delegated to third-party hosting providers. You can’t sign what you haven’t cataloged.
Deploy DNSSEC signing on all externally facing authoritative zones. Configure your DNS server software or managed DNS provider to generate zone-signing keys (ZSKs) and key-signing keys (KSKs) for each zone. Publish the corresponding DNSKEY resource records and sign all zone data with RRSIG records. Your DNSSEC deployment should follow the key management practices described in NIST SP 800-81 Rev. 3, which covers algorithm selection, key length, and rollover procedures.
Establish delegation signer (DS) records with your parent zone. For each signed zone, submit the DS record hash to the parent zone operator (typically your domain registrar). This record enables resolvers to verify the chain of trust from the root zone down to your authoritative servers.
Implement automated key rollover procedures. ZSKs should rotate on a regular schedule, while KSKs rotate less frequently. Follow the rollover timelines recommended in NIST SP 800-81 Rev. 3 for your chosen algorithm and key length. Automate these rollovers using your DNS platform’s built-in key management to avoid manual errors that can break resolution.
Monitor DNSSEC validation status continuously. Deploy monitoring that alerts when signatures approach expiration, when DS records fall out of sync with published keys, or when DNSSEC validation failures spike. Expired signatures are one of the most common causes of DNSSEC-related outages.
Document your DNSSEC architecture and key management procedures. Your system security plan should describe the signing infrastructure, key storage protections, rollover schedules, and incident response procedures for DNSSEC failures.
For your vendors
When your vendors operate authoritative DNS infrastructure on your behalf, or when you rely on their DNS resolution for critical services, you inherit their DNSSEC risk exposure.
Verify DNSSEC deployment on vendor-managed zones. Request evidence that all authoritative zones serving your data are signed with valid RRSIG records and that DS records are properly published in the parent zone. You can independently validate this information using tools such as DNSViz, Verisign’s DNSSEC Debugger, or command-line queries with dig +dnssec.
Assess key management maturity. Ask vendors to provide their key rollover schedule, describe their key storage protections (hardware security modules versus software keystores), and explain their incident response procedures for DNSSEC validation failures. A vendor that has signed zones but lacks documented rollover procedures presents a reliability risk.
Evaluate monitoring and alerting. Request evidence that vendors monitor DNSSEC signature expiration, DS record synchronization, and validation failure rates. Vendors should be able to demonstrate that they’ve caught and resolved DNSSEC issues before they caused outages.
Include DNSSEC requirements in contracts and SLAs. Specify that vendor-operated authoritative DNS zones must maintain valid DNSSEC signatures, that key rollovers must follow documented procedures, and that DNSSEC-related outages are covered under the SLA’s availability commitments.
Review the vendor’s external attack surface for DNS misconfigurations. Unsigned zones, expired signatures, and orphaned DS records are all observable indicators that a vendor’s DNS security posture has gaps.
Evidence examples
| Evidence type | Example artifact |
|---|---|
| System and communications protection policy | Policy document defining DNSSEC deployment requirements, approved signing algorithms, and key lifecycle management responsibilities |
| DNSSEC configuration documentation | System design records showing zone-signing key and key-signing key configurations, DNSKEY record publication, and RRSIG coverage for all authoritative zones |
| Delegation signer records | DS record submissions to parent zone operators confirming chain-of-trust establishment for each signed domain |
| Key management procedures | Documented ZSK and KSK rollover schedules, key storage protections, and emergency re-signing procedures |
| Validation monitoring evidence | Dashboard screenshots or log exports showing DNSSEC signature expiration monitoring, validation failure alerts, and DS record synchronization checks |
| System security plan | Relevant sections describing the DNSSEC architecture, signing infrastructure, and integration with the organization’s cryptographic key management program |
Cross-framework mapping
No cross-framework mappings are currently configured for this control.
Related controls
Review other controls in the System and Communications Protection family to understand how SC-20 fits into broader network and communications security requirements.
- AU-10 — Non-repudiation: Provides the broader non-repudiation framework that DNSSEC digital signatures support by ensuring DNS responses can be traced to their authoritative source.
- SC-08 — Transmission Confidentiality and Integrity: Protects data in transit at the transport layer, complementing the application-layer integrity that DNSSEC provides for DNS resolution data.
- SC-12 — Cryptographic Key Establishment and Management: Governs the key management lifecycle that underpins DNSSEC zone-signing keys and key-signing keys used by SC-20.
- SC-13 — Cryptographic Protection: Defines the approved cryptographic algorithms and mechanisms that SC-20 relies on for generating RRSIG records and DNSKEY material.
- SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver): Addresses the resolver side of DNSSEC validation, requiring that recursive resolvers verify the signatures and chain of trust that SC-20 mandates authoritative servers to produce.
- SC-22 — Architecture and Provisioning for Name/Address Resolution Service: Covers the fault tolerance and separation requirements for DNS infrastructure that SC-20’s authoritative servers must operate within.
Frequently asked questions
What is NIST SP 800-53 SC-20
SC-20 requires organizations to attach data origin authentication and integrity verification artifacts to every authoritative DNS response served to external queries. The control mandates DNSSEC digital signatures on resource records so that resolvers can confirm responses haven’t been forged or modified. It also requires authoritative servers to publish delegation signer resource records that enable chain-of-trust verification across parent and child zones in hierarchical namespaces.
What happens if SC-20 is not implemented
Without SC-20 controls in place, your authoritative DNS responses carry no cryptographic proof of authenticity, leaving resolvers unable to distinguish legitimate answers from forged ones. Attackers can exploit this gap through cache poisoning, on-path interception, and zone delegation manipulation to redirect traffic to malicious infrastructure. From a compliance standpoint, the absence of data origin authentication artifacts creates audit findings across all three NIST baselines, since SC-20 is required at LOW, MODERATE, and HIGH impact levels.
How do you audit SC-20
Auditors verify SC-20 by examining DNSSEC deployment across all externally facing authoritative zones, checking for valid RRSIG records, properly published DNSKEY material, and DS records registered with parent zones. The assessment confirms that a chain of trust exists from the root zone through each delegation point to your authoritative servers. Auditors also review key management documentation, including ZSK and KSK rollover schedules, and test whether DNSSEC validation monitoring is active and generating alerts for signature expiration or synchronization failures.
What is the difference between SC-20 and SC-21
SC-20 addresses the authoritative source side of DNS security, requiring servers that publish DNS data to sign it with DNSSEC digital signatures and maintain delegation signer records for child zones. SC-21 covers the opposite end, requiring recursive or caching resolvers to validate those signatures and verify the chain of trust before accepting responses. Together, these two controls create an end-to-end integrity model where authoritative servers produce cryptographic proof and resolvers consume and verify that proof before passing answers to clients.