AWS Route53 documentation change
Summary
Updated dangling DNS protection documentation by removing Scenario 5 and renumbering Scenario 6 to Scenario 5, reducing the total number of risk scenarios from 6 to 5.
Security assessment
This change appears to be a documentation cleanup or correction of scenario numbering. While the topic is security-related (dangling DNS risks), there's no evidence in the diff that this change addresses a specific security vulnerability or incident. The removal of a scenario suggests it may have been redundant or incorrect, but without explicit security context, this is likely routine documentation maintenance.
Diff
diff --git a/Route53/latest/DeveloperGuide/protection-from-dangling-dns.md b/Route53/latest/DeveloperGuide/protection-from-dangling-dns.md index 722b3026c..25c8684ab 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 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). +However, there are other dangling delegation record risks, which Route 53 can't protect against, as detailed in scenarios 2 through 5 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). @@ -41,5 +40,0 @@ In this scenario, you create a Route 53 reusable delegation set with name server -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:** - - @@ -48 +43 @@ You create hosted zones for both `child.example.com` with name servers <ns1>, <n -**Scenario 6:** +**Scenario 5:**