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 for sub-domain.parent-domain.com with 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.com has sub-domain.parent-domain.com NS 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.