SC-20: Secure Name/Address Resolution Service (Authoritative Source)

SC-20 requires your authoritative name/address resolution service (typically DNS) to return proof that the answer is authentic and unmodified when responding to external queries. Operationally, you implement origin authentication and integrity for authoritative responses (for example, DNSSEC signing and validation paths), then keep evidence that signing is enabled, keys are managed, and responses are verifiable. ¹

Key takeaways:

• Treat SC-20 as “authoritative answers must be cryptographically verifiable” for external resolvers/clients. ¹
• The hard part is operating key management, zone signing, and change control with audit-ready evidence.
• Scope is broader than public DNS; it includes any authoritative name/address service your system provides to external parties.

SC-20: secure name/address resolution service (authoritative source) requirement exists to prevent attackers from spoofing or tampering with authoritative name/address data returned to external requesters. In practice, most teams map this directly to authoritative DNS: if you run authoritative zones for your organization or for a system boundary, you need a way for external clients to verify that DNS responses originated from you and were not modified in transit or by a malicious intermediary.

This control is easy to misunderstand because many environments already encrypt transport (for example, TLS to an API gateway) and assume that covers name resolution. It does not. SC-20 is about the integrity and origin of the name/address resolution data itself returned from the authoritative source, not just the confidentiality of a session elsewhere. The expectation is “additional data origin authentication and integrity verification artifacts” returned with the authoritative answer, which is exactly how DNSSEC works: signatures and related records accompany the response so a requester can validate it. ¹

If you’re a CCO or GRC lead, your job is to translate that into: defined scope, a concrete technical standard (usually DNSSEC), documented procedures, and recurring evidence that proves it stays on.

Regulatory text

NIST excerpt (SC-20): “Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and” ¹

Operator interpretation (what you must do):

• When your system acts as an authoritative name/address resolution source and receives external queries, your responses must include artifacts that allow the requester to validate:
  1. the response came from the legitimate authoritative source (origin authentication), and
  2. the response was not altered (integrity).
     ¹

What counts as “artifacts” in real implementations:

• For authoritative DNS, this is typically DNSSEC data (RRSIG, DNSKEY, DS records, and an intact chain of trust from parent to child where applicable).
• For non-DNS name/address resolution systems (rare, but possible in specialized environments), you need an equivalent cryptographic mechanism that binds responses to the authoritative service and supports tamper detection.

Plain-English requirement meaning

If someone on the internet (or any external network) asks your authoritative service, “Where is service.example.gov?”, you cannot just answer with an IP address. You must also provide cryptographic proof that the answer is authentic and unmodified, so a validating resolver/client can detect spoofing, cache poisoning, or in-path tampering.

This requirement is about reducing the risk of redirection. Without it, an attacker who can influence DNS responses can route users to malicious hosts, intercept authentication flows, or degrade availability.

Who it applies to

SC-20 applies when both of these are true:

1. Your environment provides an authoritative name/address resolution service (you publish and answer for a zone/namespace), and
2. The service responds to external queries (outside your system boundary or outside a trusted administrative domain).
   ¹

Common in-scope entity contexts

• Federal information systems publishing authoritative DNS for system endpoints. ²
• Contractor systems handling federal data where authoritative DNS is part of the system boundary (common in FedRAMP-style SaaS and hosted environments). ²

Operational owners you will need

• Network/DNS engineering (implementation and operations)
• Security engineering (crypto standards, monitoring, incident response)
• Change management / release engineering (record updates, deployment controls)
• GRC (control definition, evidence, assessment coordination)
• Third party management if authoritative DNS is hosted by a DNS provider (contracts, SLAs, assurance)

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

Use this as a requirement-level runbook for implementing sc-20: secure name/address resolution service (authoritative source) requirement.

1) Define the authoritative scope (don’t start with tooling)

• Inventory authoritative zones/namespaces tied to the system boundary (public and private).
• Identify which zones answer queries from external networks (internet, partner networks, other agencies, third parties).
• Document exclusions explicitly (for example, internal-only split-horizon zones) and the rationale.

Deliverable: “Authoritative Name/Address Resolution Scope” one-pager (zones, environments, owners, external exposure).

2) Select the mechanism that provides origin authentication + integrity

For authoritative DNS, the normal control mapping is:

• Enable DNSSEC signing for authoritative zones.
• Publish and maintain the chain of trust (DS records in the parent zone, where applicable).
• Ensure responses include the necessary DNSSEC records so external validators can verify authenticity.
  ¹

If you rely on a managed DNS third party:

• Confirm they support DNSSEC for your zones.
• Confirm key management model (provider-managed keys vs customer-managed keys).
• Confirm operational processes for key rollover, incident handling, and audit evidence.

Decision point (practical):

• If your zone is externally reachable and you control the domain, DNSSEC is the most straightforward way to satisfy the “artifacts returned with authoritative data” expectation for DNS.

3) Establish key management and signing operations

SC-20 fails in audits when DNSSEC exists “on paper” but key management is ad hoc.

Minimum operational elements to document and implement:

• Key roles and access controls (who can enable signing, rotate keys, publish DS).
• Key storage/protection approach (HSM/service controls if used; otherwise documented provider controls).
• Rollover procedure (planned rotation, emergency rotation).
• Separation of duties for record changes vs signing/key operations where feasible.

Deliverable: “DNSSEC Operations Procedure” (enablement, record publishing, rollovers, emergency steps).

4) Put change control around DNS record integrity

You need the ability to show that authoritative record changes are controlled and traceable.

• Route DNS changes through ticketing with approvals.
• Log changes (who, what, when) and retain them.
• Validate that changes propagate and signatures remain valid.

Evidence-friendly practice: For each material DNS change, capture the ticket, the diff (records added/removed), and a post-change validation output that shows signatures resolve correctly.

5) Validate externally (prove it works from outside)

SC-20 is explicitly about external queries. Build validation that runs from outside your network boundary:

• Query authoritative records and confirm DNSSEC validation succeeds.
• Confirm the chain-of-trust is intact where applicable (DS present and correct).
• Confirm negative responses (NXDOMAIN) are properly signed if your implementation supports it.

Deliverable: “External DNSSEC Validation Test” (script output or monitoring report) stored on a recurring cadence.

6) Monitor and alert on integrity failures

Your control should detect when integrity assurances break.

• Monitor for DNSSEC validation failures, expired signatures, missing DS records, and unexpected key changes.
• Alert to on-call or security operations.
• Tie alerts to incident response runbooks.

Audit angle: Examiners often accept strong monitoring + incident response evidence as proof the control operates, not just that it was configured once.

7) Map control ownership and recurring evidence (make it assessable)

You need a named owner, a defined procedure, and evidence artifacts that appear reliably. This aligns with the practical guidance to map SC-20 to an owner, implementation procedure, and recurring evidence artifacts. ¹

If you track controls in a system like Daydream:

• Create a SC-20 control record with scope, responsible team, test method, evidence checklist, and review cadence.
• Automate evidence collection where possible (zone signing status exports, monitoring snapshots, change logs).

Required evidence and artifacts to retain

Keep artifacts that prove both design (what you intended) and operation (it stayed in place).

Design evidence

• SC-20 control statement (how you meet “origin authentication and integrity artifacts” for authoritative responses). ¹
• Scope document listing authoritative zones and which are externally queried.
• DNSSEC/key management procedure (including rollover and emergency changes).
• Architecture diagram showing authoritative DNS hosting model (in-house vs third party).

Operating evidence

• Configuration evidence: screenshots/exports showing DNSSEC enabled per zone (or provider attestation and zone settings exports).
• DS/DNSKEY/RRSIG proof: sampled outputs from external queries showing signed responses and successful validation.
• Change tickets and change logs for DNS record updates and key rollovers.
• Monitoring/alert logs for DNSSEC health (validation failures, signature expiration, DS mismatches).
• Access reviews for who can administer authoritative DNS and key material.

Common exam/audit questions and hangups

Expect these questions and prepare crisp answers:

1. “Which authoritative zones are in scope for SC-20?”
   Have a zone inventory with external exposure noted.

2. “Show me that responses to external queries include integrity/origin artifacts.”
   Be ready with external dig outputs (or equivalent) that display DNSSEC records and validation results.

3. “How do you manage keys and rollovers?”
   Auditors want a procedure plus proof that rollovers are controlled (tickets, logs).

4. “What happens if DNSSEC breaks?”
   Show monitoring, alerting, and incident response steps.

5. “Is this handled by a third party DNS provider?”
   Have third party due diligence: contractual scope, shared responsibility, and operational evidence you can obtain on request.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails SC-20	How to avoid
Enabling DNSSEC but not publishing/maintaining DS records	External validators cannot establish trust	Add a parent-zone DS publish step in the change procedure; verify chain-of-trust externally
Treating TLS/HTTPS as “good enough”	SC-20 targets name/address resolution integrity, not app-layer transport	Implement signing at the authoritative resolution layer (DNSSEC for DNS)
No recurring validation	A one-time config screenshot does not prove ongoing operation	Schedule external validation checks and retain outputs
Key rollover runbook missing	Rollover mistakes can break resolution and integrity validation	Document normal and emergency rollovers; rehearse
Outsourced DNS with no evidence	“Provider does it” is not auditable without artifacts	Require provider exports/attestations and keep validation outputs you generate externally

Risk implications (why operators care)

A failure of SC-20 controls increases the likelihood of:

• Redirecting users or services to attacker-controlled infrastructure
• Credential theft via lookalike endpoints
• Service disruption if resolvers reject bogus or inconsistent responses
• Higher incident blast radius because name resolution sits upstream of many controls (authentication, email security, service discovery)

From a compliance standpoint, SC-20 gaps often show up as “missing implementation evidence” even when teams believe DNS is “someone else’s problem.” ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Identify authoritative zones and external query exposure.
• Assign a single accountable owner (Network/DNS) and a control owner (GRC).
• Choose implementation approach (in-house DNSSEC vs managed DNSSEC with a third party).
• Draft the SC-20 control statement and evidence checklist in your GRC system (Daydream works well for mapping the owner, procedure, and recurring artifacts). ¹

By 60 days (Near-term)

• Enable DNSSEC signing for in-scope authoritative zones (or complete provider enablement).
• Publish DS records and confirm chain-of-trust where applicable.
• Implement change control workflow for DNS record and DNSSEC/key changes.
• Stand up external validation checks and start retaining outputs as evidence.

By 90 days (Stabilize and prove operations)

• Implement monitoring and alerts for signature expiration, DS mismatch, validation failures.
• Run a tabletop for DNSSEC failure or key compromise and document corrective actions.
• Complete an internal control test: pick a sample zone, pull evidence end-to-end (scope → config → external validation → monitoring → change logs).
• Close evidence gaps and lock the recurring evidence schedule into your compliance calendar.

Frequently Asked Questions

Does SC-20 require DNSSEC specifically?

SC-20 requires “data origin authentication and integrity verification artifacts” to be returned with authoritative name/address answers. For DNS, DNSSEC is the standard way to meet that expectation, but SC-20 is written generically. ¹

We use a third party DNS host. Are we still responsible?

Yes. You can delegate operation, but you still need evidence that authoritative responses include integrity/origin artifacts and that the process is managed (keys, rollovers, monitoring). Your third party due diligence should ensure you can obtain the artifacts you need.

Is this only for public internet DNS?

No. Scope is driven by “external name/address resolution queries.” If partners, other agencies, or external networks query your authoritative service, treat it as in scope. ¹

What evidence is most persuasive to auditors?

External validation outputs showing signed responses and successful verification, plus documented key management and change control. Pair that with monitoring evidence that would catch signature expiration or trust-chain breaks.

What if we have split-horizon DNS (internal and external views)?

Document both views, then scope SC-20 to the authoritative view that answers external queries. If both views serve external parties (common with partner connectivity), apply the same integrity/origin requirements to both.

How should we track SC-20 operationally in a GRC program?

Track it as a discrete control with a named owner, a procedure, and a recurring evidence set (zone signing status, external validation results, change records, monitoring alerts). Daydream can centralize ownership and evidence collection so SC-20 stays assessable over time. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5