SC-20 Secure Name/Address Resolution Service (Authoritative Source) has two requirements. Provide data origin authentication and integrity verification artifacts along with the authoritative data your system returns to external queries. And provide a way to indicate the security status of child zones, and to enable verification of a chain of trust among parent and child domains.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from.
The guidance names the usual technology. Systems that provide this service include DNS servers, the extra artifacts are DNSSEC signatures and keys, and authoritative data is DNS resource records. Child zone status is indicated through delegation signer records. It also says systems using something other than DNS need their own equivalent.
What it means in practice
If you run the authoritative DNS for your domains, outside resolvers should be able to check that the answers really came from you and were not altered. That means signing your zones with DNSSEC and publishing the delegation signer record at the parent so the chain of trust holds.
Two enhancements are listed. SC-20.1 covers child subspaces and SC-20.2 covers data origin and integrity.
Many small companies use a managed DNS provider. In that case the provider operates the signing, and your job is to show that you enabled it and that the chain validates.
Concrete checks make this control easy to evidence. Run a DNSSEC validation query for each zone and save the output with a date. Many public tools will show the chain from the root down to your zone and flag a missing or mismatched delegation signer record. Keep screenshots of the clean result, and rerun after any registrar or provider change.
The most common real world failure is operational, not cryptographic. Teams enable signing, then migrate DNS providers and forget to update the delegation signer record at the registrar. Resolvers that validate then treat the domain as bogus and users see failures. A change checklist for DNS migrations prevents this.
If your company has no authoritative servers because a registrar or cloud provider runs everything, record that fact. Your evidence becomes the provider's documentation, the status of signing per zone, and the controls on your account at the provider. Say so plainly instead of leaving the control blank.
Also consider email. Signed zones help protect records that email authentication depends on, so DNSSEC supports your anti spoofing story as well as web traffic.
Evidence to collect
- The list of zones you are authoritative for.
- DNSSEC status per zone, such as output from a public validator or a dig command with the DNSSEC flag.
- The delegation signer record published at the registrar.
- Key rollover procedure and the date of the last rollover.
- Provider documentation if signing is managed for you.
Common gaps
Signing is on for the main domain but not for marketing or legacy domains. The delegation signer record was never added at the registrar, so the chain is broken and validation either fails or is skipped. Keys expire because nobody owns rollover. Registrar accounts have weak authentication.
How to implement it
Inventory every domain you own and note who operates its name servers. Enable signing at the DNS provider, publish the delegation signer record at the registrar, and verify with an external validator. Put key rollover on a calendar with an owner.
Protect the registrar login with multifactor authentication and registry lock if offered, because a hijacked registrar account defeats the whole signature scheme.
Quick check
Is DNSSEC required by SC-20?
The control requires data origin authentication and integrity artifacts. The guidance names DNSSEC as the usual way for DNS.
What if my provider manages signing?
You still show that signing is enabled and the chain validates for each zone.
