翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Route 53 でのダングリング委任レコードからの保護
Route 53 を使用すると、顧客は `example.com` などのホストゾーンを作成して、DNS レコードをホストできます。各ホストゾーンには「委託セット」が付属しています。これは、顧客が親ドメインで NS レコードを設定するために使用できる 4 つのネームサーバーのセットです。これらの NS レコードは、「委託 NS レコード」または「委任レコード」と呼ばれます。
`example.com` Route 53 ホストゾーンを権威あるものにするには、`example.com` ドメインの正当な所有者がドメインレジストラを通じて「.com」親ドメインに委任レコードを設定する必要があります。関連付けられたホストゾーンが削除されるなど、お客様が親ドメインに設定された 4 つのネームサーバーにアクセスできなくなった場合、攻撃者が悪用するリスクが発生する可能性があります。これは「ダングリング委任レコード」リスクと呼ばれます。
ホストゾーンが削除された場合、Route 53 によりダングリング委任レコードのリスクから保護されます。削除後、同じドメイン名で新しいホストゾーンが作成されている場合、Route 53 は、削除されたホストゾーンを指す委任レコードが親ドメインにまだ存在するかどうかを確認します。存在する場合、Route 53 は重複するネームサーバーが割り当てられないようにします。これは次の例のシナリオ 1 です。
ただし、次の例のシナリオ 2 から 5 で説明されているように、Route 53 が保護できないダングリング委任レコードリスクは他にもあります。より広範なこのリスクセットからユーザーを保護するには、親 NS レコードが Route 53 ホストゾーンの委任セットと一致していることを確認してください。ホストゾーンの委任セットは、Route 53 コンソールまたは で確認できます AWS CLI。詳細については、「[レコードの一覧表示](resource-record-sets-listing.md)」または「[get-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/get-hosted-zone.html)」を参照してください。
さらに、Route 53 ホストゾーンの DNSSEC 署名を有効にすると、上述のベストプラクティスを超えた保護の別のレイヤーとして機能することができます。DNSSEC は DNS の回答が信頼できる送信元からのものであることを認証し、このリスクを効果的に防止します。詳細については、「[Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)」を参照してください。
## 例
次の例では、ドメイン `example.com` とその子ドメイン `child.example.com` があると仮定します。さまざまなシナリオでダングリング委任レコードを作成する方法、Route 53 がドメインを悪用から保護する方法、およびダングリング委任レコードに関連するリスクを効果的に軽減する方法を説明します。
**シナリオ 1:**
4 個のネームサーバー 、、、および を使用してホストゾーン `child.example.com` を作成します。ホストゾーン `example.com` で委任を適切に設定し、4 つのネームサーバー 、、、および を使用して `child.example.com` の委任 NS レコードを作成します。`example.com` の委任 NS レコードを削除せずに `child.example.com` ホストゾーンが削除されると、Route 53 は、、、、および が同じドメイン名で新しく作成されたホストゾーンに割り当てられないようにすることで、ダングリング委任レコードのリスクから `child.example.com` を保護します。
**シナリオ 2:**
シナリオ 1 と同様ですが、今回は子ホストゾーンと、ホストゾーン `example.com` の委任 NS レコードを削除します。ただし、子ホストゾーンを作成せずに、委任 NS レコード 、、、および を再度追加します。ここでは、、、、および はダングリング委任レコードです。Route 53 は保留が削除されるため、、、、および が割り当てられなくなり、新しく作成されたホストゾーンがネームサーバー上で使用できるようになりました。リスクを軽減するには、委任レコードから 、、、および を削除し、子ホストゾーンが作成されてから再度追加するだけです。
**シナリオ 3:**
このシナリオでは、ネームサーバー 、、、および を使用して Route 53 の再利用可能な委託セットを作成します。次に、親ドメイン `.com` 内のこれらのネームサーバーにドメイン `example.com` を委任します。ただし、再利用可能な委託セットには `example.com` のホストゾーンをまだ作成していません。ここでは、、、、および は、ダングリング委任レコードです。リスクを軽減するには、ネームサーバー 、、、および で再利用可能な委託セットを使用してホストゾーンを作成します。
**シナリオ 4:**
ホストゾーンは、`child.example.com`ネームサーバー 、、、 と、`grandchild.child.example.com`ネームサーバー 、、、 の両方で作成します。ただし、両方を`example.com`ゾーンに直接委任すると、ダングリング委任リスクが発生します。委任が適切な DNS 階層に従うようにするには、直接の親ゾーンを介してサブドメインのみを委任します。たとえば、 を委任する場合`grandchild.child.example.com`: 最初に`example.com`ゾーン`child.example.com`内のネームサーバー 、、、 で委任し、次に`child.example.com`ゾーン内のネームサーバー 、、、 `grandchild.child.example.com`で委任し、`example.com`ゾーン`grandchild.child.example.com`から の直接委任を削除します。
**シナリオ 5:**
対応するホストゾーンを作成する前に、ドメインまたはサブドメインを Route 53 ネームサーバーに委任すると、ダングリング委任レコードが作成されます。これはシナリオ 3 の場合と似ていますが、再利用可能な委任セットが作成されない場合にもリスクが適用されます。たとえば、親ドメイン のネームサーバー 、、、 `example.com`にドメインを委任しますが`.com`、これらのネームサーバーが をホストしたことはありません`example.com`。Route 53 は、そのドメイン名のネームサーバーに保留を確立するためのホストゾーンが存在しないため、これから保護できません。リスクを軽減するには、自分が管理するパブリックホストゾーンに属する Route 53 ネームサーバーにのみ委任します。