Primary DNS VM dies at 07:00
Secondary recursive resolvers on another host/AZ continue serving nursing stations; EHR open is delayed seconds, not hours—SC-22 redundancy earns its keep.
Architecture and Provisioning for Name / Address Resolution Service
High Risk
Moderate
Medium Cost
SC-22 requires that name/address resolution services be architected and provisioned to be fault-tolerant and to implement role separation (commonly separating authoritative and recursive functions) as appropriate. Healthcare outages often cascade when DNS is a single point of failure: EHR login, badge door integrations, lab instruments, and cloud connectors all stop when resolution fails.
Control Objective
Design and provision DNS/name services supporting ePHI operations with redundancy, capacity, and logical separation of authoritative vs recursive roles.
Implementation Guidance
- Run geographically or AZ-diverse recursive pairs for clinical campuses; avoid single VM DNS.
- Separate authoritative and recursive roles on different nodes/services (SC-20/SC-21).
- Size capacity for peak clinic open and overnight batch interface loads.
- Document failover and break-glass resolution procedures for downtime.
- Include DNS in contingency plans (CP-2) and tabletop exercises.
- Monitor latency, query rates, and saturation; alert before clinical impact.
- Cover DR site and cloud resolvers in the same architecture diagram.
- Review biomed/IoT DHCP options so devices receive resilient resolver lists.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
Authoritative/recursive split
Compromise attempt against a recursive node does not automatically grant zone-signing keys hosted only on hardened authoritative primaries.
DR site activation
DR runbook includes bringing up resolution services before EHR database mount so clinicians are not pointed at stale production IPs.
Best Practices
- No single points of failure for clinical DNS.
- Role separation authoritative vs recursive.
- Include DNS in CP/DR tests.
- Dual resolver IPs via DHCP for endpoints.
- Capacity headroom for bursts.
- Diagram for assessors.
Common Gaps & Violations
- One DNS server for the entire hospital.
- Combined open recursive + authoritative on the same weak host.
- DHCP hands out a single resolver IP.
- DNS omitted from downtime procedures.
- Cloud apps assume resolution without documented architecture.
Required Documentation
- Name resolution architecture (SC-22)
- High-availability / failover design
- Role separation evidence
- Capacity and monitoring notes
- CP/DR inclusion of DNS
How to Test & Validate
- Fail a primary recursive node in a maintenance window; confirm clinical resolution continues.
- Verify authoritative services are not exposing recursion.
- Check DHCP option 006 lists ≥2 resolvers.
- Review last DR test for DNS steps.
- Load-test or review peak query metrics vs capacity.
Audit Considerations
SC-22 is architecture evidence: diagrams, dual nodes, and DR steps—not a single checkbox for \"DNSSEC on.\"
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.308(a)(7) Contingency Plan — availability of systems that maintain ePHI includes supporting name services.
- 164.312(a) Access Control — users cannot access authorized ePHI systems if names do not resolve.
- 164.308(a)(1) Risk Analysis — DNS SPOF is a common availability finding.
- 164.310(a) Facility Access — physical hosting of DNS gear should be protected like other critical infra.
Compliance Tips
- Put DNS HA on the same slide as EHR HA for leadership.
- Track DNS as a critical dependency in the ePHI data-flow diagram.
- Retest after data-center or SD-WAN changes.
Frequently Asked Questions
Is cloud DNS enough for SC-22?
It can be, if provisioned with fault tolerance, clear failure modes, and clinical path testing—document it as the architecture.
Do we need SC-22 if we only have SC-20?
SC-20/21 secure the data; SC-22 ensures the service is resilient and properly structured.
Are internal RFC1918 zones in scope?
Yes—most EHR hostnames live on internal resolution services.
References & Resources
- NIST SP 800-53 Rev. 5 — SC-22
- Related controls: SC-20, SC-21, CP-2, CP-7, SI-13
Related Guidelines
Related controls that commonly accompany SC-22.
Need Help Implementing SC-22?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.