SC-20 authoritative name resolution: NIST 800-53 evidence

What SC-20 secure name/address resolution service requires of authoritative DNS

SC-20 requires an authoritative name resolution service to return origin authentication and integrity artifacts with its answers to external queries and, in a hierarchical namespace, to indicate the security status of child zones so that a chain of trust can be verified. For an authoritative DNS operator, that means signing zone data and publishing what a validating resolver needs to follow the chain from the parent zone down. For a system owner, it means showing that the authoritative servers that answer for your domains do this. The control is assigned to the low, moderate and high security baselines in SP 800-53B, and Appendix C of SP 800-53 lists it as implemented by the system (S), so the system owner carries the requirement even when a hosting provider runs the servers.

The risk is straightforward. If an answer can be forged or altered in transit or at a poisoned cache, a user or service can be sent to the wrong address while every other control reports normal operation. Signed data lets a validating resolver detect that tampering. The control is harder to meet than it looks because it depends on several parties working in step: the zone operator must generate and rotate signing keys without outages, the parent zone must hold the correct delegation signer records for each child, and the two sides must agree on who publishes what. Operational drift is the usual failure, such as an expired signature, a key rollover that was not coordinated with the parent, or a zone change deployed without re-signing.

Start by confirming who runs each authoritative server and where signing keys are generated, stored and rotated, then write those answers into the system security plan. Ask for the design documentation and the configuration settings for signing and key management, since these are the objects an assessor examines under SP 800-53A for SC-20. Check that the parent zone publishes the delegation records that match your current keys. Related controls SC-12 (key management), SC-8 (transmission protection) and SC-22 (resolver architecture) cover parts of the same chain, so plan evidence for them together. The exact number of determination statements and their wording should be read directly from SP 800-53A Release 5.2.0 in the OSCAL content rather than from this summary.

Which name servers, zones and teams SC-20 reaches in practice

SC-20 applies to the authoritative name resolution service that answers external queries, so the first work is deciding which servers, zones and providers fall inside the system boundary. The cards below cover the scoping choices that change the effort, and the teams that must agree on them. SC-20 sits in all three SP 800-53B baselines and at FedRAMP Rev5 Classes B, C and D, and SC-21, SC-22, SC-12 and SC-13 shape the same work.

External authoritative servers in scope

Start with the authoritative name servers that answer queries from the public internet for your domains. SC-20 is about these servers returning origin authentication and integrity artifacts to external queries, so each one must be inventoried by hostname, network location and the zones it serves. Confirm whether secondary servers, anycast nodes and servers run by a third party are part of the same authoritative service or a separate system with its own boundary.

Public zones versus internal-only zones

Decide whether internal-only zones, such as split-horizon views and private namespaces, fall under SC-20. Internal zones are not answering the internet, so many organizations scope them under SC-22 and related controls instead. Write the decision into the system security plan with reasons, and confirm that no internal zone is reachable by external queries through a misconfigured view or forwarder.

Hosting and DNS provider responsibilities

When a managed DNS provider or cloud platform hosts the authoritative zones, the provider may sign zones, publish DS records or hold the signing keys. Ask the provider which SC-20 artifacts it produces, which configuration it exposes to you, and what evidence it supplies for your assessor. Responsibilities for DNSSEC key rollover and registrar DS updates must be assigned in the agreement, not assumed.

Parent zone and registrar chain of trust

SC-20 expects the security status of child zones to be indicated so a chain of trust can be verified from the parent. The chain depends on registrar and parent zone actions that sit outside your servers. Identify who submits DS records to the registrar, how changes are confirmed, and how a broken chain would be detected and escalated before users see resolution failures.

Teams that share the work

DNS operations own zone signing, key rollovers and server configuration. Security owns the control narrative, the cryptographic requirements under SC-12 and SC-13, and the assessment evidence. Change management approves signing key changes and zone edits, and the platform or hosting team owns redundancy under SC-22. Name one owner per SC-20 artifact so an assessor can trace each one to a person and a procedure.

Baseline and FedRAMP applicability

SC-20 is in the low, moderate and high SP 800-53B baselines, and FedRAMP's Rev5 baselines require it at Classes B, C and D. Confirm which baseline your authorization or contract uses, because that decides whether SC-20 is a required control or a tailoring question. Record the selected baseline and any tailoring decision in the plan so the scope stays consistent across assessments.

How an assessor tests SC-20 and which evidence the assessor requests

This table maps the four determination statements in the SP 800-53A procedure for SC-20 to the examine, interview and test methods an assessor uses, the evidence requested for each and the findings that appear most often. Read each row as a question the assessor will put to your authoritative DNS service. The organization and any implementation partner prepare the evidence, but the independent assessor decides whether each element is met.

Assessment element	How the assessor tests it	Evidence requested	Common finding
Signing of authoritative zone data	Examine the design and configuration, then query each external authoritative server and check that responses carry signature records.	Zone signing design document, signing configuration settings and captured query output from every public name server.	Signing enabled on the primary server but disabled on a secondary server serving the same zone.
Origin authentication and integrity artifacts	Test external responses for the signature and key records a validating resolver needs, and confirm the artifacts verify.	Test query results, DNSKEY and RRSIG records, and the configuration that generates them.	Signatures expired because no monitoring or automated re-signing was documented or running.
Key management for signing keys	Interview key custodians and examine key generation, storage, access and rollover procedures against the configuration.	Key lifecycle procedure, key storage and access settings, and records of past key rollovers.	Signing keys held on a shared administrative account with no documented rollover schedule.
Chain of trust to child zones	Examine delegation records in the parent zone and test whether each child zone's security status can be verified from the parent.	Delegation signer records in the parent, child zone configuration and the process that updates them.	Child zone rolled its keys, but the parent still publishes the old delegation data, breaking validation.
Operation as part of the defined system boundary	Examine system design documentation to confirm which name servers are in scope and how their configuration is controlled.	Authoritative server inventory, system design diagrams and change records for DNS configuration.	Hosted or secondary DNS providers are used for external queries but are omitted from the boundary documentation.

How DNSSEC signing and chain-of-trust validation work in an audit

An assessor testing SC-20 wants to see that the authoritative side of your DNS produces the artifacts a validating resolver needs, and that those artifacts form an unbroken path from the root down to your zone. The path has three links. The zone operator signs the zone's records with a zone-signing key, which is the key that signs day-to-day data. A separate key-signing key signs the set of keys in the zone, and its public part is what the parent zone trusts. The parent zone then publishes a delegation record (a DS record) that is a digest of the child's key-signing key. A resolver that trusts the root can walk that chain: root to parent, parent to child, child to the answer. When your zone returns signed responses and publishes the correct delegation in its parent, you have produced the origin authentication and integrity material SC-20 describes. Assessors will ask for the signing configuration, the key inventory with roles, and proof that the delegation at the parent matches the active key-signing key.

SC-20 and its counterpart SC-21 divide the work along that path. SC-20 covers the authoritative server, which must generate and serve the signatures and indicate the security status of child zones. SC-21 covers the recursive or caching resolver, which must validate those signatures before it passes answers to clients. A signed zone that no resolver checks gives you little, and a validating resolver cannot verify a zone that was never signed, so an assessment of SC-20 should record which resolvers depend on your data and whether SC-21 is in place on the resolvers your users rely on. SC-22 sits alongside both. Redundant and separated name servers mean that signed data is still served when one server fails or is attacked, and a signature that cannot be retrieved is as unusable to a client as one that was never created. Signing keys and zone data should be replicated and managed consistently across those servers, so that a key change does not leave some servers serving answers that no longer verify.

Confirm the current algorithm choices, key handling, and key rollover procedures against NIST guidance and your DNS operator's documentation before you write them into your system security plan, since these details change over time. Ask your DNS provider or the team running your authoritative servers to show the signing state of each zone, the key roles in use, the delegation records held by the parent, and the procedure for rolling keys without an outage. Keep the key ceremony records and the change tickets for each rollover, because an assessor will test them against the configuration.

Implementing SC-20 in a self-hosted DNS estate, step by step

This sequence takes an organization from an unknown DNS footprint to a set of authoritative zones that sign their data, publish verifiable delegation records and are monitored for signature and key problems, producing the evidence an assessor needs for SC-20.

Inventory authoritative servers and zones
The organization's DNS owner lists every authoritative name server, every hosted zone, the parent zone that delegates to each one, and which zones answer external queries. Internal-only zones are recorded separately so they can be scoped out with a stated reason. The output is a zone inventory that names the owner, the hosting system and the in-scope status of each zone. The step is done when every externally reachable zone has a row and a named owner, and the scope decision is approved by the system owner.
Define the signing and key management design
The security and DNS teams agree who generates, stores, rotates and retires the signing keys for each zone, how keys are separated into signing and key-signing roles, where private material is held, and who approves a key change. This design links directly to SC-12 for key establishment and management, so the same key lifecycle rules and records apply. The output is a written key management procedure with roles, storage location, rotation triggers and a key retirement record template. It is done when the system owner and the assessor-facing control owner have both signed the procedure.
Enable signing on each in-scope zone
Engineers enable DNSSEC signing for each in-scope zone on the authoritative servers, using the key design from the previous step and the signing parameters the chosen server software documents. Changes go through the organization's change control process so the before and after configuration is recorded. The output is a configuration record for each zone showing that signing is enabled, the keys in use and the signature validity settings. The step is done when each zone serves signed responses from every authoritative server that hosts it.
Publish and verify delegation data with the parent
The zone owner submits the delegation signer data for each signed zone to the parent zone operator, following the parent's process. Engineers then confirm the parent publishes matching records and that the delegation chain is complete from the root down. The output is a delegation verification record listing the parent, the submitted data, the publication date and the check results. The step is done when the parent's published data matches what the zone is signing with, and any mismatch has been corrected and logged.
Validate the chain of trust from an external resolver
An engineer, working from outside the organization's network, queries each signed zone through a validating resolver and confirms that the responses carry the signature and key artifacts and that validation succeeds up to the root. Failed validation is traced to either the zone or the parent delegation. The output is a signed-zone verification record with the query time, the resolver used, the zone name, the validation result and a reference to the test output. It is done when every in-scope zone validates on the external test.
Document the configuration and control mapping
The DNS owner writes the SC-20 control implementation statement, describing the zones in scope, the signing method, the key procedure, the delegation process and the verification method. The statement is cross-referenced to SC-12, SC-22 for resolver architecture and the related DNS controls, and to the system security plan. The output is an approved control implementation record with a version number and an owner. It is done when the document matches the live configuration and has been reviewed after the last change.
Monitor for signature expiry and key mismatch
Monitoring checks each signed zone on a schedule the organization sets, looking for signatures approaching expiry, signing keys that no longer match the parent's delegation data, and validation failures from external resolvers. Alerts route to the DNS owner and the incident response contact. The output is a monitoring configuration record and a log of alerts with their resolution, which an assessor can sample. The step is done when a test alert has been triggered, delivered and closed through the documented process.

Evidence that passes an SC-20 assessment and how to keep it current

An assessor testing SC-20 looks for proof that authoritative zones are signed, that the keys behind them are managed, and that the chain of trust actually validates from outside. The cards below cover the artifacts that show this and the routine checks that keep them accurate between assessments.

System design document for signing

This document shows how authoritative zones are signed, which servers hold or sign zone data, where signing keys live, and how the chain of trust connects the root, parent and child zones. SC-20 assessors examine system design documentation first, so it should match the running environment. Check that the diagram names every in-scope zone and that it is updated whenever a provider, server or signing workflow changes.

Configuration exports showing signing enabled

Exports of authoritative server configuration and zone status show that signing is enabled on each in-scope zone and that the signed data is served to external queries. Assessors compare these settings against the design document and test whether they hold. Re-export after every zone change, and keep the exports with the change ticket that caused them so the record shows when signing was enabled or altered.

Key management procedure and key inventory

The procedure defines who generates, stores, uses, rotates and retires each signing key, and the inventory lists every active and retired key by zone with its purpose and location. SC-20 relies on SC-12 and SC-13 for the key and cryptography decisions behind signing, so these records must agree. Review the inventory on a schedule the organization sets and reconcile it against what the servers actually publish.

Records of parent delegation updates

A signed child zone is only verifiable when the parent zone publishes the matching delegation data. Keep the request, the approval, the submission and the confirmation for each delegation update, including the registrar or parent operator that accepted it. Check that the published parent data matches the child zone's current keys after every key change, because a mismatch breaks validation for external resolvers.

External validation test results

Results from a validating resolver outside your network show whether an external query for each zone returns signed data that verifies up the chain of trust. Run these tests from a location and resolver an assessor could also use, and keep the output with its date and the zone version tested. Rerun the test after zone changes, delegation updates and key rollovers, not only before an assessment.

Change records for key rollovers

Each key rollover should have a change record that names the reason, the old and new keys, the planned sequence of publishing and retiring keys, the validation results before and after, and the approver. These records prove that rollovers follow the documented procedure and that validation was checked at each step. Review open and closed rollover records on the schedule the organization sets to confirm none were left incomplete.

What meeting SC-20 costs in tooling, engineering time and assessment

This table breaks down the cost components of meeting SC-20, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. NIST does not estimate compliance costs, so the table names no figures; use it to structure a written quote and to see where open-source tooling removes license spend while engineering time remains.

Cost component	One-time or recurring	What drives it up or down
DNS hosting or managed DNS fees	Recurring, paid to the DNS provider or hosting platform	Number of zones and query volume; self-hosted authoritative servers remove a vendor fee but add operations work
Engineering time for zone signing design and rollout	One-time, paid to internal staff or an implementation partner	Number of zones and how many already have DNSSEC; a single signing procedure reused across zones shortens the work
Parent delegation and DS record coordination	One-time per zone, with occasional recurring key rollover	Number of parent relationships and whether registrars or parent operators need manual steps
Key management tooling or hardware	One-time setup, recurring for rotation and custody	Key management maturity; hardware security modules add purchase and support cost, while software key storage is cheaper but needs stricter procedures
Monitoring and evidence upkeep	Recurring, paid to staff or a retainer	Frequency of key rollovers and validation checks; scheduled evidence capture avoids rebuilding proof at assessment time
External validation or penetration testing	Recurring if scheduled, one-time for a point assessment	Scope of external DNS testing and whether validation of chain of trust is included in the test plan
Assessor time	One-time per assessment cycle	Clarity of the system design documentation and configuration evidence provided in advance; confirm the assessor's fee basis in writing

Which open-source tools support SC-20 evidence and which do not

SC-20 asks for signed authoritative DNS data and a verifiable chain of trust, which is a property of the DNS platform that serves the zones. The tools below can support the surrounding evidence, such as hardened server settings, host configuration and traffic rules, but none of them signs zone data, so confirm each tool's fit with your DNS platform before you rely on it.

Wazuh configuration assessment

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and checks files, directories, registry keys and running processes. For SC-20, it can show that the hosts running authoritative DNS servers have the settings your policy expects, such as the DNS service configuration file and its permissions. It does not sign zones or publish DS records, so DNSSEC key management and signing must be evidenced separately. Check that your DNS software is covered by an existing policy or that you can write a custom one. The license is GPL-2.0-only, so confirm how your distribution of the tool meets its terms.

Fleet policies for host configuration

Fleet policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices pass or fail each one. For SC-20, you can write queries that confirm DNS-related host configuration, such as whether the resolver service is running or whether the zone-signing host has the expected software version. A passing result is evidence of configuration state at the time of the query, not evidence that zone data is signed. Keep the query text and the pass or fail history as assessment evidence. Fleet is MIT licensed, so confirm that its license terms fit your deployment model.

OPNsense rules and logs

OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses for easier review. For SC-20, its rules and logs can show that DNS queries to your authoritative servers are permitted from the networks you intend and that rule matches are logged for review. They cannot show that answers carry origin authentication or that a chain of trust validates. Confirm that the firewall sits where your DNS traffic actually flows, and check how the logging option is configured for each rule. OPNsense is BSD-2-Clause licensed.

Coraza is not an SC-20 control

Coraza is an open-source web application firewall, Apache-2.0 licensed, compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It defends web applications against attacks such as SQL injection, cross-site scripting and code injection. It does not sign DNS data, validate DNSSEC or protect name resolution, so it should not be listed as SC-20 evidence. It may still matter for other controls if you publish web services that depend on your DNS. Keep it out of the SC-20 evidence package and map it to the controls it actually addresses.

Who signs, who prepares evidence and who issues the assessment result

Your organization owns SC-20. DNS operations hold the authoritative zones, the signing keys and the delegation records that the parent zone depends on, so they decide when signing is enabled, when keys roll and who can change the zone. The security team owns the key management procedure, the validation tests that prove chain-of-trust validation works from outside the network, and the decision that the control is implemented as documented. Neither team can hand these responsibilities to a partner or an assessor.

Zone and key ownership: DNS operations approve the signing policy, key lifetimes and the custody of key material.
Parent updates: DNS operations submit and confirm delegation signer records with the registrar or parent zone operator.
Procedure approval: the security team approves the key management procedure and the rules for emergency key rollover.
Validation tests: the security team runs or reviews external validation queries and keeps the results.
Control statement: the control owner states how SC-20 is implemented in the system security plan.

Before engaging anyone, confirm which named individual signs the procedure and who receives validation results each month.

Questions buyers ask about SC-20 cost, effort and outsourcing

Does SC-20 apply to DNS that only serves internal names?

SC-20 is written around authoritative name resolution that answers external queries, so a zone that only serves internal clients is usually outside its main intent, but the decision belongs to the organization and its assessor. The control asks that authoritative responses carry origin authentication and integrity artifacts for external queries, and that child zones signal their security status so a chain of trust can be verified. If your internal zone is never resolvable from outside, document that boundary in the system security plan, record why SC-20 is scoped out or addressed by another control, and have the assessor confirm the reasoning. Check whether any internal zone is delegated to or queried by external parties, because that changes the answer. Ask your implementation partner to read the scope against your actual DNS topology before any signing work starts.

How much effort does signing an existing DNS zone take?

The effort depends mostly on how many zones you run, how complex their delegations are, and how many systems depend on the current resolution path. Signing a zone adds cryptographic keys, publishes signature records alongside the existing data, and requires the parent zone to hold a matching delegation signer record before validating resolvers can verify the chain. The main drivers are the number of zones and delegations, whether your DNS provider or registrar supports the steps you need, the state of current records, and how much testing you do against validating resolvers before going live. Testing against a staging zone, a rollback plan and a monitored change window add time that is worth budgeting for. Ask any quote to list each zone, each parent delegation, the tooling used and the test evidence delivered.

Can an in-house team sign and maintain DNSSEC without outside help?

Many in-house DNS teams can do it, provided they have someone who understands DNSSEC key roles, parent delegation, and validation failure modes, and they own the work after go-live. The skills are specific: key generation and rollover, signature lifetimes, handling a broken chain that makes a zone unresolvable for validating clients, and coordinating with registrars or parent operators. Outside help is most useful when the team has no recent DNSSEC experience, when several zones and providers are involved, or when the assessor will need consistent written evidence. One cost to plan for is recurring: keys must be rotated and signatures kept current, so someone must own that routine after the project ends. Ask whether your team can run a key rollover from documentation alone, and treat a no as a reason to scope training or support.

What does the organization need to provide for a DNS signing project?

The organization must supply access, decisions and time, and an implementation partner cannot provide them on its behalf. The usual inputs are administrative access to the authoritative DNS platform and registrar or parent-zone accounts, a list of zones and their current delegations, change windows approved by operations, and a named owner for key material. Key ownership decisions matter: you must decide where private keys are generated and stored, who may trigger rollovers, and how keys are backed up and recovered. Also agree on a rollback path, since a misconfigured signed zone can fail resolution for validating resolvers. Write these inputs into the statement of work so the scope, responsibilities and approvals are visible to your auditor.

How long does DNSSEC signing take, and what sets the timeline?

The timeline depends on scope, and no single duration applies across organizations, so ask for a schedule tied to a written scope rather than a general figure. The factors that lengthen work are the number of zones, parent-zone dependencies that require a third party to act, change freeze periods, testing depth, and any remediation of existing DNS hygiene problems found during discovery. Work can often be sequenced so that one zone is signed, validated and documented before others follow, which reduces the risk of a broad outage. Require the quote to show phases, the approvals each phase needs, and which steps depend on outside parties such as registrars. Fixed-scope engagements agree deliverables and timing in writing before work begins.

Can a partner guarantee that the assessor will pass SC-20?

No partner can guarantee an assessment result, and an honest partner will not offer one. An assessor decides whether each determination statement is met based on evidence and the organization's own system boundary, and only an independent assessor or certification body issues reports or certificates. DeployOpen prepares systems, configuration evidence and documentation for an assessment, and the organization owns its controls. A useful partner will show you how the work maps to the SC-20 assessment objects, such as system design documentation and configuration settings, and will tell you which evidence still depends on your own operations. Ask for a written list of deliverables and the evidence each one produces, then confirm the expected result with your assessor before the work starts.

How DeployOpen scopes, implements and prepares SC-20 evidence

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For SC-20, we prepare the authoritative DNS service, its DNSSEC signing configuration and the evidence an assessor will examine, while the organization owns the control and an independent assessor tests it.

How we scope

The written scope lists every authoritative zone, name server and hosting location that serves external queries.
We record which DNSSEC signing keys, zones and key-management processes fall inside the SC-20 boundary.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure DNSSEC signing for in-scope zones so responses carry origin authentication and integrity data.
We confirm child zones publish their security status so a chain of trust can be validated from the root.
We test validation from external resolvers and record the results against the SC-20 determination statements.

How we hand over

You receive configuration records, zone signing settings and test output mapped to each SC-20 assessment objective.
Runbooks cover key rollover, signing failures and how the system design documentation is kept current.
We confirm with your assessor which artifacts they expect, since only the independent assessor judges the control.

How we support

Ongoing support, upgrades and continuous testing of the DNS configuration are available as a retainer.
Changes to zones, keys or hosting locations can be re-tested and the evidence refreshed for the next assessment.
Your team keeps ownership of the control, and we document any changes to the scope agreed in writing.