Route 53 subdomain is delegated to a zone not in this account
- Severity
- Low
- Service
- Route 53
- Check ID
- ROUTE53_DANGLING_NS_DELEGATION
What this check finds
A public NS record delegates a subdomain to Route 53 name servers of a hosted zone that is not in this account. Delegating to another account of yours is normal; if that zone was deleted, someone else may be able to create one on the same name servers and answer for your subdomain.
Passing looks like: Every delegated subdomain points at a zone in this account.
How to fix it
Confirm you still own the delegated zone (in this or another AWS account) and that its name servers match the NS record. If not, delete the NS record.
AWS console
Route 53 → Hosted zones → select zone → select the NS record.
Compliance controls it is evidence for
A failing result counts against these controls in KloudLytics; a passing one is evidence towards them. How compliance mapping works
| Framework | Controls |
|---|---|
| NIST SP 800-53 Rev5 (Moderate) |
|
| NIST Cybersecurity Framework 2.0 |
|
| ISO/IEC 27001:2022 Annex A |
|
Checked on every scan
KloudLytics runs this check each time it scans a connected AWS account, through a read-only role, and lists every affected resource with its region. On Pro and Business a fix is written for the specific resource rather than the general case above. The exact access it needs
More Route 53 checks
- HighRoute 53 domain is not set to auto-renew
- HighRoute 53 record points at an S3 bucket not in this account
- LowDomain does not have a domain transfer lock set
- LowRoute 53 record points at a CloudFront distribution not in this account
- LowRoute 53 record points at a load balancer not in this account
- InfoVPC is associated with a hosted zone owned by another account