Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Protection from dangling delegation records in RouteĀ 53
With RouteĀ 53, you can route traffic to a sub-domain by creating NS records. When these NS records point to RouteĀ 53 name servers, itās expected that the name servers match those in the delegation set of a hosted zone thatās authoritative for the sub-domain. If these NS records are not pointing to the right name servers, it exposes a risk that an attacker can exploit and take control of the sub-domain. These are called dangling NS records.
For example, when a RouteĀ 53 hosted zone for a sub-domain is deleted, its NS records may get left dangling in the parent domain. When this happens, an attacker could hijack the sub-domain by creating a new hosted zone on the name servers of the deleted zone. RouteĀ 53 attempts to prevent this by keeping track of the sub-domain delegation set pairs and not allowing any new zones of the sub-domain to be created on those name servers before you remove the dangling NS records.
However, dangling NS records can still happen due to misconfiguration of the NS records. To mitigate this risk, we recommend you take the following actions:
Make sure the apex NS records of the sub-domainās authoritative RouteĀ 53 hosted zone match the delegation set for the hosted zone. You can find the delegation set of a hosted zone through RouteĀ 53 console or AWS CLI. For more information, see Listing records or get-hosted-zone
. Enable DNSSEC signing for RouteĀ 53 hosted zone. DNSSEC authenticates that DNS answers come from the authoritative source, effectively prevents the risk. For more information see Configuring DNSSEC signing in Amazon RouteĀ 53.
Remove the name servers that donāt host the sub-domain from the sub-domain NS records in the parent hosted zone.
- or -
Replace the name servers with the four name servers in the delegation set of the sub-domainās authoritative RouteĀ 53 hosted zone. This effectively mitigates the risk as well.
Examples
In the following examples, we assume you have a parent domain, parent-domain.com, and a sub-domain,
sub-domain.parent-domain.com,
and show three scenarios where there are dangling NS records and how to mitigate the risk.
- Scenario 1:
In the parent hosted zone
parent-domain.com, you create NS records forsub-domain.parent-domain.comwith four name servers <ns1>, <ns2>, <ns3>, and <ns4>. And the name servers of the authoritative sub-domain are <ns5>, <ns6>, <ns7>, and <ns8>. Therefore, <ns1>, <ns2>, <ns3>, and <ns4> are all dangling NS records and it exposes a risk that an attacker can gain control of sub-domain.parent-domain.com. To mitigate the risk, replace the sub-domain NS record with <ns5>, <ns6>, <ns7>, and <ns8>.- Scenario 2:
parent-domain.comhassub-domain.parent-domain.comNS records point at <ns1>, <ns2>, <ns3>, <ns4>, <ns5>, <ns6>, <ns7>, and <ns8>. The name servers for the authoritative sub-domain hosted zone are <ns5>, <ns6>, <ns7>, and <ns8>. Therefore, <ns1>, <ns2>, <ns3>, and <ns4> are again dangling NS records. To mitigate the risk, remove <ns1>, <ns2>, <ns3>, and <ns4> from the NS records.- Scenario 3:
You have a reusable delegation set <ns1>, <ns2>, <ns3> and <ns4>. You create an NS record in the parent zone and delegate the sub-domain to these name servers in the reusable delegation set. However, you havenāt created the sub-domain zone on the reusable delegation set. Therefore, <ns1>, <ns2>, <ns3> and <ns4> are dangling NS records. To mitigate the risk, create the sub-domain hosted zone with the reusable delegation set.
