Secure Name/Address Resolution Service (Authoritative Source)

To meet the Secure Name/Address Resolution Service (Authoritative Source) requirement (NIST SP 800-53 Rev 5 SC-20), you must ensure your authoritative DNS returns cryptographic proof of origin and integrity (typically via DNSSEC) and supports a verifiable chain of trust from parent to child zones. Operationally, that means signing zones, publishing DS records correctly, and keeping keys and signing workflows tightly controlled.

Key takeaways:

• SC-20 is a DNS integrity and authenticity control for authoritative name resolution responses (NIST Special Publication 800-53 Revision 5).
• You need DNSSEC-style artifacts plus chain-of-trust support for child zones, not just “secure DNS servers” (NIST Special Publication 800-53 Revision 5).
• Auditors will look for evidence of zone signing, key management, delegation/DS handling, and monitoring tied to your boundary and service model.

This requirement exists because name/address resolution is a high-leverage control point: if an attacker can tamper with authoritative DNS answers, they can redirect users and systems to malicious endpoints without breaking application-layer security controls. SC-20 focuses on the authoritative source side of DNS, meaning the systems that publish DNS answers for your domains (or the third party that does it for you).

Under FedRAMP Moderate, your job is to ensure external resolvers can validate that the DNS data came from your authoritative source and was not modified in transit. Practically, that means returning “data origin authentication and integrity verification artifacts” with DNS responses and enabling verifiers to confirm a chain of trust between parent and child zones (NIST Special Publication 800-53 Revision 5).

If you outsource authoritative DNS, SC-20 becomes a third-party due diligence and configuration assurance problem: you still need to prove the third party signs zones correctly, publishes delegation records correctly, and manages keys with appropriate controls. If you run authoritative DNS yourself, you need secure signing operations, robust change control, and evidence that your implementation supports validation across your DNS hierarchy.

Regulatory text

Control requirement (excerpt): “Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name and address resolution queries; and provide the means to indicate the security status of child zones and enable verification of a chain of trust among parent and child domains.” (NIST Special Publication 800-53 Revision 5)

What an operator must do:

• Return authoritative DNS answers with attached integrity/authenticity artifacts that external parties can validate. In practice, this is typically implemented with DNSSEC-signed zones that return signatures (for example, RRSIG) and related records needed for validation.
• Publish and maintain delegation and trust-chain signals for child zones so validators can confirm an unbroken chain of trust from parent to child (for example, using DS records at the parent and DNSKEY records in the child zone).
• Ensure the security status of child zones is indicated in a way that supports verification (commonly by correct presence/absence of DS and supporting records that enable validators to determine whether a zone is signed and how to validate it). (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation

SC-20 requires you to make your authoritative DNS tamper-evident and verifiable by outsiders. If someone queries your authoritative DNS, the response must include cryptographic material that lets the requester validate two things: (1) the response came from the real authority for that domain, and (2) it was not altered. You also must set up your DNS hierarchy so that child zones can be validated from their parent, creating a chain of trust across your domains (NIST Special Publication 800-53 Revision 5).

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers offering FedRAMP Moderate services where the service’s domains are reachable externally and depend on authoritative DNS.
• Federal agencies operating authoritative DNS for agency-owned domains or delegating to third parties. (NIST Special Publication 800-53 Revision 5)

Operational contexts you should map first:

• External-facing service domains: public APIs, web apps, SaaS endpoints, mail domains, identity/SSO domains.
• Authoritative DNS operating model: self-hosted authoritative DNS, managed DNS provider, registrar-hosted DNS, or hybrid.
• DNS zone hierarchy: parent zone(s), delegated child zones, subdomains used by the system, and any split-horizon patterns that could confuse what is “authoritative” externally.

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

1) Define the authoritative DNS scope you are securing

1. Inventory all domains and subdomains that route users/systems to your FedRAMP boundary endpoints.
2. Identify which zones you are authoritative for and who operates them (your team vs a third party).
3. Document which authoritative name servers answer externally for each zone and where they are hosted.

Output: authoritative DNS scope statement tied to system boundary and external endpoints.

2) Decide the implementation pattern (most teams choose DNSSEC)

SC-20 does not name a specific protocol, but the requirement for origin authentication, integrity artifacts, and chain-of-trust support maps directly to DNSSEC-style mechanisms (NIST Special Publication 800-53 Revision 5). Your implementation decision should be explicit:

• Managed authoritative DNS with DNSSEC support (common for SaaS): you configure signing and delegation; the provider runs the infrastructure.
• Self-operated authoritative DNS with DNSSEC: you run signers, key management, and publishing workflows.

Control owner note: if a third party hosts your authoritative DNS, treat it as a control that is shared operationally but still requires your governance and evidence.

3) Implement signed zones and publish validation material

For each in-scope authoritative zone:

1. Enable zone signing and confirm signed records are served externally with the required integrity artifacts ¹ (NIST Special Publication 800-53 Revision 5).
2. Ensure the correct public key material is published in-zone (for validators).
3. Ensure responses for common record types used by your service (A/AAAA, CNAME, MX, TXT, SRV as applicable) are covered by signatures as expected for your signing approach.

Practical check: query your authoritative servers directly (not a caching resolver) and confirm signed responses include the expected verification records for the zone.

4) Establish and maintain the chain of trust for child zones

SC-20 explicitly calls out child zones and chain-of-trust between parent and child (NIST Special Publication 800-53 Revision 5). Operationally:

1. For each delegated child zone, confirm whether it is intended to be signed.
2. If signed, ensure the parent publishes the delegation records that allow validators to build trust to the child (commonly DS at the parent).
3. Put change control around delegation updates. A single incorrect delegation record can break validation for the entire child zone.
4. Document how you indicate and manage “security status” for child zones (signed vs unsigned, expected validation behavior).

Common governance need: registrar and DNS provider roles must be controlled; otherwise the chain of trust becomes an “admin account security” problem.

5) Key management and signing operations

SC-20’s integrity/authentication artifacts are only credible if the signing keys and signing process are controlled (NIST Special Publication 800-53 Revision 5). Implement:

1. Key ownership and access controls (who can generate, activate, rotate, and revoke signing keys).
2. Change approval for enabling/disabling signing and for delegation record changes.
3. Secure storage for private signing keys (HSM-backed or provider-managed equivalents, depending on your model).
4. A defined rotation and rollover process that avoids validation outages.

6) Monitoring, logging, and incident response hooks

You need operational detection for:

• Validation failures caused by misconfigurations (broken chain of trust).
• Unauthorized changes to zones, signing state, name server sets, or delegation records.
• Expiring signatures or key rollovers that could cause outages.

Tie these signals into your incident management process, because DNS integrity issues can present as availability incidents, integrity incidents, or both.

Required evidence and artifacts to retain

Keep artifacts that prove implementation, operation, and control over change:

Design and scope

• DNS architecture diagram: authoritative servers/providers, zones, parent/child delegations.
• In-scope domain inventory mapped to system endpoints.

Configuration and technical proof

• Screenshots or exports showing zone signing enabled for each zone.
• Evidence of published delegation/trust-chain records for child zones (for example, registrar/parent-zone configuration exports).
• Sample external queries showing signed responses from authoritative name servers (store command output with timestamps and the queried authoritative servers).

Operations and governance

• Key management procedure (generation, storage, access, rotation, emergency rollover).
• Change tickets for signing enablement, key rollovers, delegation record changes, and name server changes.
• Access reviews for DNS admin roles (your org and any third party).
• Monitoring/alert definitions and incident records for DNSSEC/validation-related events.

Common exam/audit questions and hangups

• “Which authoritative zones are in scope for this system, and where is that documented?”
• “Show me evidence that authoritative responses include origin authentication and integrity artifacts.” (NIST Special Publication 800-53 Revision 5)
• “How do you establish a chain of trust from parent to child zones? Show the delegation records and the child zone keys.” (NIST Special Publication 800-53 Revision 5)
• “Who can change DNS signing status or delegation records? Show approvals and access controls.”
• “How do you prevent a third party DNS provider admin from making unapproved changes?”
• “What monitoring detects broken validation, expired signatures, or misconfigured rollovers?”

Frequent implementation mistakes and how to avoid them

1. Signing the zone but failing to publish parent delegation records. Result: validators treat the child as bogus. Avoid with a delegation checklist and peer review for every DS/delegation update.
2. Unclear scope (some domains signed, some not, nobody knows why). Avoid by tying every external endpoint domain to a documented signing decision and owner.
3. Key rollover without a tested runbook. Avoid by rehearsing rollover in a non-production zone and keeping a rollback plan.
4. Registrar access sprawl. Avoid by limiting registrar access, enforcing MFA, and requiring change tickets for delegation updates.
5. Treating managed DNS as “provider responsibility.” Avoid by requiring evidence in due diligence and ongoing control checks; the compliance obligation remains with you.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SC-20 primarily as an auditability and risk-reduction control rather than a case-law-driven requirement. The practical risk is straightforward: if authoritative DNS answers can be spoofed or tampered with, users and systems can be redirected to attacker-controlled infrastructure even when the application stack is otherwise hardened. SC-20 reduces that risk by enabling cryptographic validation of authoritative DNS answers and hierarchical trust (NIST Special Publication 800-53 Revision 5).

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Build the authoritative DNS inventory: zones, authoritative servers, providers, registrars, and child delegations.
• Assign control owners for DNS operations, registrar management, and key management.
• Select the implementation model (self-operated signing vs managed DNS signing) and document it in the system security documentation set.

Days 31–60 (implement signing and trust chain)

• Enable signing for in-scope zones and verify externally that responses contain integrity/authentication artifacts (NIST Special Publication 800-53 Revision 5).
• For each signed child zone, publish/verify parent delegation records that support validation and document the chain of trust (NIST Special Publication 800-53 Revision 5).
• Establish access controls, approvals, and logging for DNS changes across both your environment and any third party DNS provider consoles.

Days 61–90 (operationalize and make it auditable)

• Implement monitoring for validation failures, signing/rollover health, and unauthorized DNS/delegation changes.
• Finalize runbooks: key rollover, emergency key compromise response, delegation change procedure.
• Assemble an audit-ready evidence pack (queries, exports, tickets, access reviews).
• If you manage many zones and third parties, consider using Daydream to standardize evidence collection workflows (tickets, provider attestations, and configuration snapshots) so SC-20 proof stays current without manual scrambles.

Frequently Asked Questions

Does SC-20 require DNSSEC specifically?

SC-20 requires origin authentication, integrity verification artifacts, and a verifiable chain of trust for child zones (NIST Special Publication 800-53 Revision 5). DNSSEC is the most common way to meet those elements, but your method must still produce those artifacts and trust-chain properties.

We use a managed DNS provider. Are we still responsible?

Yes. Even if a third party operates authoritative DNS, you must govern configuration, access, and evidence because the system’s authoritative answers are part of your compliance scope (NIST Special Publication 800-53 Revision 5).

What counts as “authoritative name resolution data” in practice?

It’s the DNS records your authoritative servers return for your zones in response to external queries (NIST Special Publication 800-53 Revision 5). Focus on records that route traffic or establish trust, such as A/AAAA, CNAME, MX, TXT, and service discovery records used by your system.

How do we handle unsigned child zones?

SC-20 requires that you “provide the means to indicate the security status of child zones” and enable trust-chain verification where applicable (NIST Special Publication 800-53 Revision 5). If a child zone is intentionally unsigned, document the decision, the risk acceptance (if needed), and how validators should interpret that status in your architecture.

What evidence do auditors accept to prove signed authoritative responses?

Provide captured external query outputs against authoritative servers showing the signed response contents, plus configuration exports/screenshots from your DNS platform showing signing enabled (NIST Special Publication 800-53 Revision 5). Pair that with change tickets and access control evidence to show it is controlled, not ad hoc.

What’s the fastest way to fail SC-20 during an assessment?

Having DNSSEC enabled in the child zone but missing or incorrect delegation records at the parent, which breaks the chain of trust (NIST Special Publication 800-53 Revision 5). The second-fastest is weak control over registrar/DNS admin access that allows unauthorized delegation or signing changes.

Footnotes

1. NIST Special Publication 800-53 Revision 5