SC-22 Architecture and Provisioning for Name/Address Resolution Service asks you to ensure that the systems providing name and address resolution for your organization are fault tolerant and implement internal and external role separation.
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 gives concrete practice. To remove single points of failure, use at least two authoritative DNS servers, one primary and one secondary, typically in two geographically separated network subnetworks and not in the same physical facility. For role separation, servers with internal roles answer only requests from internal clients, while servers with external roles answer only requests about externally visible hosts.
What it means in practice
Do not run your public DNS on one server or one provider region. Do not let your public name servers expose records for internal hosts. Split horizon is a common way to deliver both views, as long as the internal view is reachable only from internal networks.
Role separation is the part teams skip. An external DNS server should hold only records for hosts you want the world to see. If it also carries internal names such as build servers, databases and admin portals, you have given attackers a map. The fix is two sets of servers or two views, with the internal one limited to internal clients.
Fault tolerance is easy to claim and hard to prove. The guidance suggests two authoritative servers on geographically separated subnetworks. A reviewer will look at your NS records, then ask where those servers live. If both resolve into one provider's network, be prepared to explain that provider's own redundancy, or add a second provider.
Time to live values also matter. If a record has a long time to live, a failover that changes an address takes hours to reach users. Pick lower values for records you may need to move quickly, and note the choice in your design record.
Watch recursion too. External authoritative servers should not also act as open recursive resolvers. Open resolvers are abused in amplification attacks, and the role separation language exists partly to prevent that. A quick external test for open recursion belongs in your checklist.
Evidence to collect
- NS records showing at least two authoritative servers, ideally with different providers or networks.
- Diagram of internal and external resolvers.
- Configuration proving the external servers do not carry internal zones.
- Zone transfer restrictions.
- Failover test notes, including when a name server was taken offline on purpose.
Common gaps
Both name servers belong to one provider and one account. Internal hostnames leak in public zones, which helps attackers map your network. Zone transfers are open to anyone. Nobody has tested losing a name server.
How to implement it
Use two independent DNS providers or at least two networks. Keep internal zones on resolvers that only accept internal clients. Restrict zone transfers to named secondaries. Schedule a yearly drill where you disable one name server and confirm resolution continues.
For small teams a managed multi provider DNS setup is the simplest way to show fault tolerance without running servers.
Quick check
What is role separation?
Internal resolvers serve internal clients only. External servers answer only for externally visible hosts.
Is one managed DNS provider enough?
Providers run many servers, but an auditor may still ask about provider level failure. Be ready to explain your choice or add a second provider.
