AWS Route53 high security documentation change
Summary
Expanded dangling DNS delegation scenarios from 2 to 6, adding detailed mitigation guidance
Security assessment
Added scenarios 4-6 explicitly detail DNS delegation risks (dangling records leading to subdomain takeover vulnerabilities) and provide mitigation steps. The changes address security hardening by explaining how to prevent unauthorized domain control through proper delegation management.
Diff
diff --git a/Route53/latest/DeveloperGuide/protection-from-dangling-dns.md b/Route53/latest/DeveloperGuide/protection-from-dangling-dns.md index 7f6bacc97..722b3026c 100644 --- a//Route53/latest/DeveloperGuide/protection-from-dangling-dns.md +++ b//Route53/latest/DeveloperGuide/protection-from-dangling-dns.md @@ -15 +15 @@ Route 53 protects against the dangling delegation record risk in the case where -However, there are other dangling delegation record risks, which Route 53 can't protect against, as detailed in scenarios 2 and 3 in the following examples. To protect yourself against this broader set of risks, make sure the parent NS records match the delegation set for the Route 53 hosted zone. You can find the delegation set of a hosted zone through the Route 53 console or AWS CLI. For more information, see [Listing records](./resource-record-sets-listing.html) or [get-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/get-hosted-zone.html). +However, there are other dangling delegation record risks, which Route 53 can't protect against, as detailed in scenarios 2 through 6 in the following examples. To protect yourself against this broader set of risks, make sure the parent NS records match the delegation set for the Route 53 hosted zone. You can find the delegation set of a hosted zone through the Route 53 console or AWS CLI. For more information, see [Listing records](./resource-record-sets-listing.html) or [get-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/get-hosted-zone.html). @@ -37,0 +38,15 @@ In this scenario, you create a Route 53 reusable delegation set with name server +**Scenario 4:** + + +You have a hosted zone `child.example.com` with four name servers: <ns1>, <ns2>, <ns3>, and <ns4>. You add a delegation to <ns1>, <ns2>, <ns3>, and <ns4> in parent. You then delete the zone, but don't remove the <ns1>, <ns2>, <ns3>, and <ns4> delegation. Subsequently, you create a new `child.example.com` zone with nameservers <ns5>, <ns6>, <ns7>, <ns8>, and add delegation to <ns5>, <ns6>, <ns7>, and <ns8>. You now have a parent zone with delegations to both <ns1>, <ns2>, <ns3>, and <ns4> and <ns5>, <ns6>, <ns7>, and <ns8>. This creates a dangling delegation risk for <ns1>, <ns2>, <ns3>, and <ns4>. To mitigate this risk, remove the inactive nameservers <ns1>, <ns2>, <ns3>, <ns4> from the delegation records, leaving only the active nameservers <ns5>, <ns6>, <ns7>, <ns8>. In general, always ensure there is only one sub-domain delegation for `child.example.com` and that the NS records in `example.com` exactly match the four nameservers in the current child zone's delegation set. + +**Scenario 5:** + + +You create hosted zones for both `child.example.com` with name servers <ns1>, <ns2>, <ns3>, and <ns4>, and `grandchild.child.example.com` with name servers <ns5>, <ns6>, <ns7>, and <ns8>. However, you delegate both directly in the `example.com` zone, which creates a dangling delegation risk. To ensure delegations follow proper DNS hierarchy, only delegate subdomains through their immediate parent zones. For example, if you want to delegate `grandchild.child.example.com`: first delegate `child.example.com` with name servers <ns1>, <ns2>, <ns3>, and <ns4> in the `example.com` zone, then delegate `grandchild.child.example.com` with name servers <ns5>, <ns6>, <ns7>, and <ns8> in the `child.example.com` zone, and remove any direct delegations for `grandchild.child.example.com` from the `example.com` zone. + +**Scenario 6:** + + +You delegate a domain or subdomain to Route 53 name servers before creating a corresponding hosted zone, this creates dangling delegation records. This is similar to the case in Scenario 3, but the risk also applies when no reusable delegation set is created. For example, you delegate the domain `example.com` to name servers <ns1>, <ns2>, <ns3>, and <ns4> in the parent domain `.com`, but none of these name servers has ever hosted `example.com`. Route 53 cannot protect against this because no hosted zone has ever existed to establish a hold on those name servers for that domain name. To mitigate the risk, only delegate to Route 53 name servers that belong to a public hosted zone that you control. +