翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Route 53 での DNSSEC 署名の設定
ドメインネームシステムセキュリティ拡張 (DNSSEC) 署名により、DNS リゾルバーは DNS 応答が Amazon Route 53 から送信され、改ざんされていないことを検証できます。DNSSEC 署名を使用すると、ホストゾーンへのすべての応答は、公開キー暗号化を使用して署名されます。DNSSEC の概要については、「[AWS re:Invent 2021 - Amazon Route 53: A year in review](https://www.youtube.com/watch?v=77V23phAaAE)」の DNSSEC セクションを参照してください。
この章では、Route 53 の DNSSEC 署名を有効にする方法、キー署名キー (KSK) の使用方法および問題のトラブルシューティングについて説明します。で DNSSEC 署名を使用する AWS マネジメントコンソール か、 API を使用してプログラムで操作できます。CLI または SDK を使用して Route 53 を操作する方法の詳細については、「[Amazon Route 53 を設定する](setting-up-route-53.md)」を参照してください。
DNSSEC 署名を有効にする前に、以下の点に注意してください。
+ ゾーンの停止を防ぎ、ドメインが使用できなくなる問題を回避するには、DNSSEC エラーにすばやく対処し解決する必要があります。`DNSSECInternalFailure` または `DNSSECKeySigningKeysNeedingAction` エラーが検出されるたびにアラートを受け取ることができる、CloudWatch アラームをセットアップしておくことを強くお勧めします。詳細については、「[Amazon CloudWatch を使用したホストゾーンのモニタリング](monitoring-hosted-zones-with-cloudwatch.md)」を参照してください。
+ DNSSEC には、キー署名キー (KSK) とゾーン署名キー (ZSK) の 2 種類のキーがあります。Route 53 の DNSSEC 署名での各 KSK は、お客様が所有する AWS KMS 内の[非対称カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept)に基づいています。必要に応じて行うローテーションを初めとして、KSK管理の責任はお客様が持ちます。ZSK 管理は Route 53 によって実行されます。
+ ホストゾーンで DNSSEC 署名を有効にすると、Route 53 は TTL を 1 週間に制限します。ホストゾーンのレコードに対して TTL を 1 週間以上設定しても、エラーは発生しません。ただし、Route 53 では、レコードに対して 1 週間の TTL が強制されます。TTL が 1 週間未満のレコードと、DNSSEC 署名が有効になっていない他のホストゾーンのレコードは、この影響を受けません。
+ DNSSEC 署名を使用する場合、マルチベンダー構成はサポートされません。ホワイトラベルネームサーバー (別称: バニティネームサーバー、プライベートネームサーバー) を構成している場合は、それらのネームサーバーが単一の DNS プロバイダーから提供されていることを確認します。
+ 一部の DNS プロバイダーは、権威 DNS 内で委任署名者 (DS) レコードをサポートしていません。親ゾーンが DS クエリをサポートしていない (DS クエリ応答に AA フラグを設定していない) DNS プロバイダーによってホストされている場合、子ゾーンで DNSSEC を有効にすると、その子ゾーンに関する解決が不能になります。ご利用の DNS プロバイダーで、DS レコードがサポートされていることを確認してください。
+ ゾーン所有者以外の別のユーザーがゾーン内のレコードを追加または削除できるように、IAM アクセス許可を設定すると便利です。例えば、ゾーンの所有者は KSK を追加して署名を有効にし、キーのローテーションを担当することができます。同時に、他のユーザーがホストゾーンで他のレコードの操作を担当することも可能です。IAM ポリシーの例については、「[ドメインレコード所有者のアクセス許可の例](access-control-managing-permissions.md#example-permissions-record-owner)」を参照してください。
+ TLD に DNSSEC サポートがあるかどうかを確認するには、「[Amazon Route 53 に登録できる最上位ドメイン](registrar-tld-list.md)」を参照してください。
**Topics**
+ [DNSSEC 署名を有効にし、信頼チェーンを確立します。](dns-configuring-dnssec-enable-signing.md)
+ [DNSSEC 署名の無効化](dns-configuring-dnssec-disable.md)
+ [DNSSEC のためのカスタマー管理キーの使用](dns-configuring-dnssec-cmk-requirements.md)
+ [キー署名キー (KSK) の使用](dns-configuring-dnssec-ksk.md)
+ [Route 53 での KMS キーと ZSK 管理](dns-configuring-dnssec-zsk-management.md)
+ [Route 53 での DNSSEC の非存在証明](dns-configuring-dnssec-proof-of-nonexistence.md)
+ [DNSSEC 署名のトラブルシューティング](dns-configuring-dnssec-troubleshoot.md)
# DNSSEC 署名を有効にし、信頼チェーンを確立します。
****
増分手順はホストゾーンの所有者と親ゾーンの管理者に適用されます。これは同一の当事者でもかまいません。ただし、そうでない場合、ゾーンの所有者は親ゾーンの管理者に通知して協力する必要があります。
ゾーンを署名して信頼チェーンに含めるため、この記事の手順に従うことをお勧めします。以下の手順により、DNSSEC へのオンボーディングのリスクを最小限に抑えられます。
**注記**
始める前に、「[Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)」で前提条件を確認してください。
以下のセクションで説明する通り、DNSSEC 署名を有効にする場合、3 つの手順を実行します。
**Topics**
+ [ステップ 1: DNSSEC 署名を有効化する準備](#dns-configuring-dnssec-enable-signing-step-1)
+ [ステップ 2: DNSSEC 署名を有効にして KSK を作成](#dns-configuring-dnssec-enable)
+ [ステップ 3: 信頼チェーンを確立](#dns-configuring-dnssec-chain-of-trust)
## ステップ 1: DNSSEC 署名を有効化する準備
準備手順では、ゾーンの可用性を監視して署名の有効化から委任署名者 (DS) レコードの挿入までの待機時間を短縮することで、DNSSEC へのオンボーディングのリスクを最小限に抑えることができます。
**DNSSEC 署名を有効にする準備を行うには**
1. ゾーンの可用性を監視します。
ドメイン名の可用性をゾーンで監視できます。これにより、DNSSEC 署名を有効にした後、ステップのロールバックを必要とする問題に対処できます。クエリログを使用してトラフィックが最も多いドメイン名を監視できます。クエリ ログのセットアップの詳細については、「[Amazon Route 53 のモニタリング](monitoring-overview.md)」をご参照ください。
監視はシェルスクリプトまたはサードパーティサービスを通じて実行できます。ただし、ロールバックが必要か否かを判断する唯一のシグナルとして見なしてはなりません。また、ドメインが利用できない理由で顧客からフィードバックを得る場合があります。
1. ゾーンの最大 TTL を下げます。
ゾーンの最大 TTL は、ゾーン内の最長 TTL レコードです。以下のゾーン例では、ゾーンの最大 TTL は 1 日 (86400 秒) です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
ゾーンの最大 TTL を下げると、署名を有効にしてから Delegation Signer (DS) レコードの挿入までの待機時間を短縮できます。ゾーンの最大 TTL を 1 時間 (3600 秒) に下げることをお勧めします。これにより、リゾルバーが署名済みレコードのキャッシュに問題がある場合、わずか 1 時間後にロールバックできます。
**ロールバック:** TTL の変更を元に戻します。
1. SOA TTL および SOA の最小フィールドを下げます。
SOA 最小フィールドは、SOA レコードデータの最後のフィールドです。以下の SOA レコードの例では、最小フィールドの値は 5 分 (300 秒) です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
SOA TTL および SOA の最小フィールドは、リゾルバーがネガティブな回答を記憶する期間を決定します。署名を有効にすると、Route 53 ネームサーバーはネガティブな回答に対して NSEC レコードを返し始めます。NSEC には、リゾルバーがネガティブな回答を合成する際に使用する可能性がある情報が含まれています。NSEC 情報により、リゾルバーが名前に対してネガティブな回答を仮定したことによってロールバックが必要な場合、リゾルバーが仮定を停止するまで SOA TTL の最大値および SOA 最小フィールドに達するまで待つのみで解決します。
**ロールバック方法:** SOA の変更を元に戻します。
1. TTL および SOA の最小フィールドの変更が有効であることを確認します。
[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) を使用して、これまでの変更がすべての Route 53 DNS サーバーに反映されたことを確認します。
## ステップ 2: DNSSEC 署名を有効にして KSK を作成
Route 53 コンソールで AWS CLI または を使用して、DNSSEC 署名を有効にし、キー署名キー (KSK) を作成できます。
+ [CLI](#dnssec_CLI)
+ [コンソール](#dnssec_console)
KMS キーの指定または作成には、いくつかの要件があります。詳細については、「[DNSSEC のためのカスタマー管理キーの使用](dns-configuring-dnssec-cmk-requirements.md)」を参照してください。
------
#### [ CLI ]
既に持っているキーを使用、または以下のように `hostedzone_id`、`cmk_arn`、`ksk_name`、`unique_string` 用の値を使用して AWS CLI コマンドを実行してキーを作成します (リクエストをユニークにするため):
```
aws --region us-east-1 route53 create-key-signing-key \
--hosted-zone-id $hostedzone_id \
--key-management-service-arn $cmk_arn --name $ksk_name \
--status ACTIVE \
--caller-reference $unique_string
```
カスタマーマネージドキーの詳細については、「[DNSSEC のためのカスタマー管理キーの使用](dns-configuring-dnssec-cmk-requirements.md)」をご参照ください。[CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html) も併せてご参照ください。
DNSSEC 署名を有効にするには、 に独自の値を使用して、次のような AWS CLI コマンドを実行します`hostedzone_id`。
```
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
詳細については [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html) および [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) をご参照ください。
------
#### [ Console ]
**DNSSEC 署名を有効にして KSK を作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、[**ホストゾーン**] をクリックし、DNSSEC 署名を有効にするホストゾーンを選択します。
1. **[DNSSEC signing]** (DNSSEC 署名) タブで、**[Enable DNSSEC signing]** (DNSSEC 署名を有効にする) を選択します。
**注記**
このセクションで **[Disable DNSSEC signing]** (DNSSEC 署名を無効にする) というオプションが表示されている場合は、DNSSEC 署名を有効にするための最初のステップが既に完了しています。DNSSEC のホストゾーンの信頼チェーンが確立されている、あるいは既に存在していることを確認し、作業を完了します。詳細については、「[ステップ 3: 信頼チェーンを確立](#dns-configuring-dnssec-chain-of-trust)」を参照してください。
1. [**Key-signing key (KSK) creation**] (キー署名キー (KSK) の作成) セクション内で [**Create new KSK**] (新しい KSK を作成) を選択し、[**Provide KSK name**] (KSK 名を指定) の下で、Route 53 が作成する KSK 名を入力します。名前には、文字、数字、アンダースコア (\$1) のみを含めることができます。また、名前は一意である必要があります。
1. [**Customer managed CMK**] (カスタマー管理 CMK)で、KSK の作成時に Route 53 で使用される、カスタマー管理キーを選択します。既存のカスタマー管理キーを使用して DNSSEC 署名に適用することも、新しいカスタマー管理キーを作成して使用することもできます。
カスタマー管理キーの指定または作成には、いくつかの要件があります。詳細については、「[DNSSEC のためのカスタマー管理キーの使用](dns-configuring-dnssec-cmk-requirements.md)」を参照してください。
1. カスタマー管理キーのエイリアスを入力します。新たなカスタマーマネージドキーを使用する場合、カスタマーマネージドキーのエイリアスを入力します。これによって Route 53 がキーを作成します。
**注記**
Route 53 にカスタマー管理キーを作成させる場合、個別のカスタマー管理キーごとに料金が発生することにご注意ください。詳細については、[AWS Key Management Service の料金](https://aws.amazon.com/kms/pricing/)を参照してください。
1. [**DNSSEC 署名を有効にする**] をクリックします。
------
**ゾーン署名を有効にした後、以下の手順を実行します** (コンソールあるいは CLI を使用した場合を問わず):
1. ゾーン署名が有効であることを確認します。
を使用した場合は AWS CLI、`EnableHostedZoneDNSSEC()`呼び出しの出力からオペレーション ID を使用して [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) または [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) を実行し、すべての Route 53 DNS サーバーがレスポンスに署名していることを確認します (ステータス = `INSYNC`)。
1. 最低でも前ゾーンの最大 TTL を待ちます。
リゾルバーがキャッシュから署名されていないレコードをすべてフラッシュするまで待ちます。これを実現するため、最低でも前ゾーンの最大 TTL を待つ必要があります。上記の `example.com` ゾーンの場合、待機時間は 1 日です。
1. 顧客問題のレポートを監視します。
ゾーン署名を有効にした後、顧客がネットワークデバイスおよびリゾルバーに関連する問題に直面し始める可能性があります。推奨される監視期間は 2 週間です。
直面する問題例を以下の通り、紹介します:
+ 一部のネットワークデバイスは DNS 応答容量を 512 バイト未満に制限できますが、一部の署名応答としては小さすぎます。これらのネットワークデバイスは、より大きな DNS 応答容量を許可するために再設定する必要があります。
+ 一部のネットワークデバイスは、DNS 応答について詳細な検査を行い、DNSSEC に使用されるレコードなど、理解しない特定のものを削除します。これらのデバイスは再設定する必要があります。
+ 顧客の一部のリゾルバーは、ネットワークがサポートする UDP 応答よりも大量に受け入れることができると主張しています。ネットワーク機能をテストしてリゾルバーを適切に設定できます。詳細については、[DNS Reply Size Test Server](https://www.dns-oarc.net/oarc/services/replysizetest/) (DNS 応答容量テストサーバー) をご参照ください。
**ロールバック方法:**[DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) を呼び出した後、[ステップ 1: DNSSEC 署名を有効化する準備](#dns-configuring-dnssec-enable-signing-step-1) の手順をロールバックします。
## ステップ 3: 信頼チェーンを確立
Route 53 のホストゾーンで DNSSEC 署名を有効にした後に、ホストゾーンの信頼チェーンを確立して DNSSEC 署名のセットアップを完了します。これを行うには、Route 53 から提供される情報を使用しながら、自分のホストゾーンの*親*ホストゾーンで Delegation Signer (DS) レコードを作成します。ドメインが登録されている場所に応じて、Route 53 内または別のドメインレジストラにある親ホストゾーンに、DS レコードを追加します。
**DNSSEC 署名のために信頼チェーンを確立するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、[**ホストゾーン**] をクリックした後、 DNSSEC の信頼チェーンを確立するホストゾーンを選択します。*最初に DNSSEC 署名を有効にする必要があります。*
1. **[DNSSEC signing]** (DNSSEC 署名) タブを開き、**[DNSSEC signing]** (DNSSEC 署名) の **[View information to create DS record]** (DS レコードを作成するための情報を表示) を選択します。
**注記**
このセクションで **[View information to create DS record]** (DSレコードを作成するための情報を表示] が表示されていない場合は、信頼チェーンを確立する前に DNSSEC 署名を有効にする必要があります。**[Enable DNSSEC signing]** (DNSSEC 署名を有効にする) を選択して [ステップ 2: DNSSEC 署名を有効にして KSK を作成](#dns-configuring-dnssec-enable) の記載された手順を完了した後、これらの手順に戻って信頼チェーンを確立します。
1. ドメインが登録されている場所に応じ、[**信頼チェーンを確立**] から、[**Route 53 レジストラ**] または [**他のドメインレジストラ**] を選択します。
1. ステップ 3 で指定された値を使用して、Route 53 の親ホストゾーンの DS レコードを作成します。ドメインが Route 53 でホストされていない場合、表示された値をドメインレジストラのウェブサイトで使用して DS レコードを作成します。
親ゾーンの信頼チェーンを確立します。
+ ドメインが Route 53 で管理されている場合、次の手順に従います。
署名アルゴリズム (ECDSAP256SHA256 および type 13) とダイジェストアルゴリズム (SHA-256 およびタイプ 2) が正しく設定されたことを確認します。
Route 53 がレジストラである場合、Route 53 コンソールで以下の操作を実行します:
1. **[Key type]** (キータイプ)、**[Signing algorithm]** (署名アルゴリズム)、および **[Public key]** (パブリックキー) の各値を書き留めます。ナビゲーションペインで [**Registered Domains**] をクリックします。
1. ドメインを選択し、**[DNSSEC keys]** (DNSSEC キー) タブで **[Add key]** (キーの追加) を選択します。
1. **[Manage DNSSEC keys]** (DNSSEC キー管理) ダイアログボックス内のドロップダウンメニューから、**[Route 53 registrar]** (Route 53 レジストラ) の適切な **[Key type]** (キータイプ) と **[Algorithm]** (アルゴリズム) を選択します。
1. Route 53 レジストラの [**パブリックキー**] をコピーします。[**Manage DNSSEC keys**] (DNSSEC キー管理) ダイアログボックス内の [**Public key**] (パブリックキー) ボックスに値を貼り付けます。
1. **[Add]** (追加) を選択します。
Route 53 は、パブリックキーから親ゾーンに DS レコードを追加します。例えば、ドメインが `example.com` の場合、DS レコードが .com DNS ゾーンに追加されます。
+ ドメインが別のレジストリで管理されている場合は、「**別のドメインレジストラ**」セクションの手順に従います。
以下の手順をスムーズに進める場合、親ゾーンに低い DS TTL を導入します。変更をロールバックする必要がある場合、DS TTL を 5 分 (300 秒) に設定してリカバリの高速化をお勧めします。
+ 子ゾーンの信頼チェーンを確立します。
親ゾーンが別のレジストリで管理されている場合、レジストラに連絡してゾーンに DS レコードを導入するように依頼してください。通常、DS レコードの TTL を調整することはできません。
+ 親ゾーンが Route 53 でホストされている場合、親ゾーンの所有者に連絡してゾーンに DS レコードを導入するように依頼してください。
親ゾーンの所有者に `$ds_record_value` を提供します。コンソールの [**View Information to create DS record**] (情報を確認して DS レコードを作成) をクリックして [**DS record**] (DS レコード) フィールドをコピー、または [GetDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) API を呼び出して「DSRecord」フィールドの値を取得します。
```
aws --region us-east-1 route53 get-dnssec
--hosted-zone-id $hostedzone_id
```
親ゾーンの所有者は、Route 53 コンソールまたは CLI を使用してレコードを挿入できます。
+ を使用して DS レコードを挿入するには AWS CLI、親ゾーンの所有者が次の例のような JSON ファイルを作成して名前を付けます。親ゾーンの所有者は、ファイルに `inserting_ds.json` のような名前を付けることがあります。
```
{
"HostedZoneId": "$parent_zone_id",
"ChangeBatch": {
"Comment": "Inserting DS for zone $zone_name",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "$zone_name",
"Type": "DS",
"TTL": 300,
"ResourceRecords": [
{
"Value": "$ds_record_value"
}
]
}
}
]
}
}
```
次に、以下のコマンドを実行します。
```
aws --region us-east-1 route53 change-resource-record-sets
--cli-input-json file://inserting_ds.json
```
+ コンソールを使用して DS レコードを挿入するには、
Route 53 コンソール ([https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)) を開きます。
ナビゲーションペインで [**Hosted zones**] (ホストゾーン) とホストゾーン名を選択し、[**Create record**] (レコード作成) ボタンを押します。**[Routing policy]** (ルーティングポリシー) で [Simple routing] (簡易ルーティング) を選択していることを確認します。
[**Record name**] (レコード名) フィールドに `$zone_name` と同じ名前を入力し、[**Record type**] (レコードタイプ) ドロップダウンから DS を選択します。次に [**Value**] (値) フィールドに `$ds_record_value` の値を入力して [**Create records**] (レコード作成) を選択します。
**ロールバック方法:** 親ゾーンから DS を削除して DS TTL を待った後、信頼を確立するための手順にロールバックします。親ゾーンが Route 53 でホストされている場合、親ゾーンの所有者は JSON ファイル内の `UPSERT` の `Action` を `DELETE` に変更して上記の例の CLI を再実行できます。
1. ドメインレコードの TTL に基づいて、更新が全体に反映されるのを待ちます。
親ゾーンが Route 53 DNS サービス上にある場合、親ゾーンの所有者は [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API でプロパゲーション全体を確認できます。
または、親ゾーンの DS レコードを定期的に調査することが可能であり、DS レコードの挿入が完全にプロパゲートされる確率を上げるため、さらに 10 分待ちます。DS 挿入をスケジュールしているレジストラもいることにご留意ください (例えば 1 日 1 回など)。
親ゾーンに Delegation Signer (DS) レコードを導入すると、DS を取得した検証済みリゾルバーがゾーンから応答の検証を開始します。
信頼を確立する手順をスムーズに進めるため、以下の手順を実行します:
1. NS TTL の最大値を求めます。
ゾーンに関連付けられた NS レコードが 2 つのセットあります。
+ NS レコードの委任 - これは、親ゾーンが保持しているお客様ゾーンの NS レコードです。次の Unix コマンドを実行することでこれを検索できます (ゾーンが example.com の場合、親ゾーンは com です):
`dig -t NS com`
いずれの NS レコードを 1 つを選択して以下を実行します:
`dig @one of the NS records of your parent zone -t NS example.com`
例:
`dig @b.gtld-servers.net. -t NS example.com`
+ ゾーン内 NS レコード - これはゾーン内の NS レコードです。以下の Unix コマンドを実行すると探せます。
`dig @one of the NS records of your zone -t NS example.com`
例:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
両ゾーンの最大 TTL に注目してください。
1. NS TTL の最大値を待ちます。
DS を挿入前の段階では、リゾルバーは署名付きレスポンスを取得しますが、署名を検証しません。DS レコードが挿入されると、ゾーンの NS レコードが期限切れになるまで、リゾルバーはそのレコードを認識しません。リゾルバーが NS レコードを再フェッチすると、DS レコードも返されます。
お客様の顧客が非同期クロックのホスト内でリゾルバーを実行している場合、クロックが正しい時刻から 1 時間以内の誤差があることを確認してください。
この手順を完了すると、DNSSEC を認識したすべてのリゾルバーがゾーンを検証します。
1. 名前解決を確認します。
ゾーンを検証するリゾルバーに問題がないことにご留意してください。顧客が問題を報告するために必要な時間も考慮してください。
最大 2 週間監視することをお勧めします。
1. (任意) DS および NS TTL を長くします。
セットアップがよろしければ、変更した TTL および SOA 内容を保存できます。Route 53 は署名済みゾーンの TTL を 1 週に制限することにご留意ください。詳細については、「[Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)」を参照してください。
DS TTL を変更が可能な場合、1 時間に設定することをお勧めします。
# DNSSEC 署名の無効化
Route 53 で DNSSEC 署名を無効にする手順は、ホストゾーンが属する信頼チェーンによって異なります。
例えば、信頼チェーンの一部として、自分のホストゾーンには、Delegation Signer (DS) レコードを持つ親ゾーンが存在する場合があります。またホストゾーンは、DNSSEC 署名を有効にしている子ゾーンの親ゾーンにもなり得るが、信頼チェーンの別の部分となっている場合も考えられます。DNSSEC 署名を無効にする手順を実行する前に、使用しているホストゾーンの信頼チェーン全体を調べて判断します。
DNSSEC 署名を有効にしているホストゾーンの信頼チェーンは、署名を無効にする際に慎重に元に戻す必要があります。信頼チェーンからホストゾーンを削除するには、このホストゾーンを含む信頼チェーンに対して配置されているすべての DS レコードを削除します。つまり、以下の操作を、順番に実行する必要があります。
1. 信頼チェーンの一部である (それぞれの) 子ゾーンについて、親のホストゾーンにある DS レコードをすべて削除します。
1. 親ゾーンから DS レコードを削除します。信頼の島 (親ゾーンに DS レコードがなく、このゾーンの子ゾーンの DS レコードもありません) がある場合、この手順をスキップします。
1. 信頼チェーンからゾーンを削除する際に、DS レコードの削除が不可能な場合には、親ゾーンから NS レコードを削除します。詳細については、「[ドメインのネームサーバーおよびグルーレコードの追加あるいは変更](domain-name-servers-glue-records.md)」を参照してください。
次の増分手順は、ゾーン内の DNS 可用性の問題を回避するために個別手順の有効性を監視することを実現します。
**DNSSEC 署名を無効にするには**
1. ゾーンの可用性を監視します。
ドメイン名の可用性をゾーンで監視できます。これにより、DNSSEC 署名を有効にした後、ステップのロールバックを必要とする問題に対処できます。クエリログを使用してトラフィックが最も多いドメイン名を監視できます。クエリログのセットアップの詳細については、「[Amazon Route 53 のモニタリング](monitoring-overview.md)」をご参照ください。
監視はシェルスクリプトまたは有料サービスを通じて実行できます。ただし、ロールバックが必要か否かを判断する唯一のシグナルとして見なしてはなりません。また、ドメインが利用できない理由で顧客からフィードバックを得る場合があります。
1. 現在の DS TTL を検索します。
以下の Unix コマンドを実行して DS TTL を検索できます:
`dig -t DS example.com example.com`
1. NS TTL の最大値を求めます。
ゾーンに関連付けられた NS レコードが 2 つのセットあります。
+ NS レコードの委任 - これは、親ゾーンが保持しているお客様ゾーンの NS レコードです。以下の Unix コマンドを実行してこれを検索できます:
まず親ゾーンの NS を検索します (ゾーンが example.com の場合、親ゾーンは com です):
`dig -t NS com`
いずれの NS レコードを 1 つを選択して以下を実行します:
`dig @one of the NS records of your parent zone -t NS example.com`
例:
`dig @b.gtld-servers.net. -t NS example.com`
+ ゾーン内 NS レコード - これはゾーン内の NS レコードです。以下の Unix コマンドを実行すると探せます。
`dig @one of the NS records of your zone -t NS example.com`
例:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
両ゾーンの最大 TTL に注目してください。
1. 親ゾーンから DS レコードを削除します。
親ゾーンの所有者に連絡して DS レコードを削除するように依頼します。
**ロールバック方法:** DS レコードを再度挿入して DS 挿入が有効であることを確認し、すべてのリゾルバーが再検証を開始する前に最大 NS (DS ではない) TTL を待ちます。
1. DS の削除が有効であることを確認します。
親ゾーンが Route 53 DNS サービス上にある場合、親ゾーンの所有者は [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API でプロパゲーション全体を確認できます。
または、親ゾーンの DS レコードを定期的に調査することが可能であり、DS レコードの削除が完全にプロパゲートされる確率を上げるため、さらに 10 分待ちます。一部のレジストラは DS の削除をスケジュール (例えば、1 日 1 回など) していることをご留意ください。
1. DS TTL を待つ。
すべてのリゾルバーがキャッシュにある DS レコードの有効期限が切れるまで待ちます。
1. DNSSEC 署名を無効にしてキー署名キー (KSK) を無効にします。
+ [CLI](#CLI_dnssec_disable)
+ [コンソール](#console_dnssec_disable)
------
#### [ CLI ]
[DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) および [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) API を呼び出します。
例:
```
aws --region us-east-1 route53 disable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
aws --region us-east-1 route53 deactivate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
```
------
#### [ Console ]
**DNSSEC 署名を無効にするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、[**ホストゾーン**]をクリックし、DNSSEC 署名を無効にするホストゾーンを選択します。
1. **[DNSSEC signing]** (DNSSEC 署名) タブで、**[Disable DNSSEC signing]** (DNSSEC 署名を無効にする) を選択します。
1. **[Disable DNSSEC signing]** (DNSSEC 署名を無効にする) ページで、ゾーンにおける DNSSEC 署名の無効化のシナリオに応じて、次のいずれかのオプションを選択します。
+ **親ゾーンのみ** – このゾーンには、DS レコードを持つ親ゾーンがあります。このシナリオでは、親ゾーンの DS レコードを削除する必要があります。
+ **子ゾーンのみ** – このゾーンには、1 つまたは複数の子ゾーンが属する信頼チェーンのための DS レコードがあります。このシナリオでは、このゾーンの DS レコードを削除する必要があります。
+ **親ゾーンと子ゾーン** – このゾーンには、1 つまたは複数の子ゾーンが属する信頼チェーンのための DS レコード、および DS レコードを持つ親ゾーンの両方があります。このシナリオでは次の操作を順に実行します。
1. このゾーンの DS レコードを削除します。
1. 親ゾーンの DS レコードを削除します。
信頼の島がある場合、この手順をスキップできます。
1. ステップ 4 で削除する各 DS レコードの TTL の数値を特定し、最も長い TTL 期間が終了していることを確認します。
1. チェックボックスを選択して、手順を順番通りに実行したことを確認します。
1. 次に示すように、フィールドに「disable」と入力してから、**[Disable]** (無効化) を選択します。
**キー署名キー (KSK) を無効にする場合**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] (ホストゾーン) を選択し、キー署名キー (KSK) を無効にするホストゾーンを選択します。
1. [**Key-signing keys (KSKs)**] (キー署名キー (KSK) ) セクションで無効にする KSK を選択します。次に [**Actions**] (アクション) の下で [**Edit KSK**] (KSKの編集) を選択し、[**KSK status**] (KSKステータス) を [**Inactive**] (非アクティブ) に設定して [**Save KSK**] (KSKを保存) を選択します。
------
**ロールバック方法:** [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) および [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) API を呼び出します。
例:
```
aws --region us-east-1 route53 activate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
1. ゾーン署名の無効化が有効になっていることを確認します。
`EnableHostedZoneDNSSEC()` の呼び出しに使用した ID で [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) を実行し、すべての Route 53 DNS サーバーが応答の署名を停止していることを確認します (ステータス = `INSYNC`)。
1. 名前解決を確認します。
リゾルバーがゾーンを検証する問題がないことを確認する必要があります。顧客が問題を報告するために必要な時間も 1～2 週間ぐらい考慮してください。
1. (オプション) クリーンアップする。
署名を再有効にしない場合、[DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html) を使用して KSK をクリーンアップし、コスト削減のために該当カスタマーマネージドキーを削除できます。
# DNSSEC のためのカスタマー管理キーの使用
Amazon Route 53 で DNSSEC 署名を有効にすると、Route 53 によってキー署名キー (KSK) が作成されます。KSK を作成するには、Route 53 は DNSSEC をサポートする AWS Key Management Service でカスタマーマネージドキーを使用する必要があります。このセクションでは、DNSSEC を使用する際に役立つカスタマー管理キーの詳細と要件について説明します。
DNSSEC でカスタマー管理キーを使用する場合は、以下の点に注意してください。
+ DNSSEC 署名で使用するカスタマー管理キーは、米国東部 (バージニア北部) リージョンに置かれている必要があります。
+ カスタマー管理キーは、[非対称カスタマー管理キー](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks)であり、また [ECC\$1NIST\$1P256 のキースペック](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc)である必要があります。これらのカスタマー管理キーは、署名と検証にのみ使用されます。非対称カスタマーマネージドキーの作成については、[「 デベロッパーガイド」の「非対称カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk)の作成」を参照してください。 AWS Key Management Service 既存のカスタマーマネージドキーの暗号化設定を見つける方法については、 AWS Key Management Service デベロッパーガイドの[「カスタマーマネージドキーの暗号化設定の表示](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html)」を参照してください。
+ Route 53 の DNSSEC で使用するカスタマーマネージドキーを自分で作成する場合は、Route 53 に必要なアクセス許可を付与する特定のキーポリシーステートメントを定義する必要があります。Route 53 が KSK を作成する際には、カスタマー管理キーへのアクセスが可能である必要があります。詳細については、「[DNSSEC 署名に必要な Route 53 カスタマー管理キーアクセス許可](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC)」を参照してください。
+ Route 53 は、追加の AWS KMS アクセス許可なしで DNSSEC 署名で使用するカスタマーマネージドキー AWS KMS を で作成できます。ただし、作成後にキーを編集する場合は、特定のアクセス許可が必要です。ユーザーに必須な特定のアクセス許可は `kms:UpdateKeyDescription`、`kms:UpdateAlias`、および `kms:PutKeyPolicy` です。
+ カスタマー管理キーをユーザーが作成したか、あるいは Route 53 により作成されたかにかかわらず、カスタマー管理キーごとに個別の料金が適用されることにご注意ください。詳細については、[AWS Key Management Service 料金表](https://aws.amazon.com/kms/pricing/)を参照してください。
# キー署名キー (KSK) の使用
DNSSEC 署名を有効にすると、Route 53 によってキー署名キー (KSK) が作成されます。Route 53 ではホストゾーンごとに最大 2 つの KSK を使用できます。DNSSEC 署名を有効にした後は、KSK の追加、削除、または編集が行えます。
KSK を使用する場合は、次の点に注意してください。
+ KSK を削除する際には、先に KSK を編集して、そのステータスを [**非アクティブ**] に設定する必要があります。
+ ホストゾーンで DNSSEC 署名を有効にすると、Route 53 は TTL を 1 週間に制限します。ホストゾーンのレコードの TTL を 1 週間以上に設定した場合でもエラーは発生しませんが、Route 53 は TTL を 1 週間に強制します。
+ ゾーンの停止を防ぎ、ドメインが使用できなくなる問題を回避するには、DNSSEC エラーにすばやく対処し解決する必要があります。`DNSSECInternalFailure` または `DNSSECKeySigningKeysNeedingAction` エラーが検出されるたびにアラートを受け取ることができる、CloudWatch アラームをセットアップしておくことを強くお勧めします。詳細については、「[Amazon CloudWatch を使用したホストゾーンのモニタリング](monitoring-hosted-zones-with-cloudwatch.md)」を参照してください
+ このセクションで説明する KSK 操作を使用すると、ゾーンの KSK をローテーションさせることができます。詳細およびステップバイステップの例については、ブログ記事 [Configuring DNSSEC signing and validation with Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/) の、「*DNSSEC Key Rotation*」を参照してください。
で KSKs を使用するには AWS マネジメントコンソール、以下のセクションのガイダンスに従ってください。
## キー署名キー (KSK) の追加
DNSSEC 署名を有効にすると、Route 53 によってキー署名キー (KSK) が作成されます。KSK は個別に追加することもできます。Route 53 ではホストゾーンごとに最大 2 つの KSK を使用できます。
KSK の作成時には、KSK で使用するカスタマー管理キーを作成するための Route 53 を指定またはリクエストする必要があります。カスタマー管理キーの指定または作成には、いくつかの要件があります。詳細については、「[DNSSEC のためのカスタマー管理キーの使用](dns-configuring-dnssec-cmk-requirements.md)」を参照してください。
以下のステップに従って、 AWS マネジメントコンソールに KSK を追加します。
**KSK を追加するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、[**ホストゾーン**] をクリックした後で、ホストゾーンを選択します。
1. **[DNSSEC signing]** (DNSSEC 署名) タブを開き、**[Key-signing keys (KSKs)]** (キー署名キー (KSK)) で **[Switch to advanced view]** (詳細表示に切り替える) を選択し、さらに **[Actions]** (アクション) で **[Edit KSK]** (KSK の編集) を選択します。
1. [**KSK**] で、Route 53 により作成される KSK のために名前を入力します。名前には、文字、数字、アンダースコア (\$1) のみを含めることができます。また、名前は一意である必要があります。
1. DNSSEC 署名に適用するカスタマー管理型キーのエイリアスを入力するか、Route 53 が作成する新しいカスタマー管理型キーのエイリアスを入力します。
**注記**
Route 53 にカスタマー管理キーを作成させる場合、個別のカスタマー管理キーごとに料金が発生することにご注意ください。詳細については、[AWS Key Management Service 料金表](https://aws.amazon.com/kms/pricing/)を参照してください。
1. [**KSK を作成**] をクリックします。
## キー署名キー (KSK) の編集
KSK のステータスを編集して **[Active]** (アクティブ) または **[Inactive]** (非アクティブ) とすることができます。KSK がアクティブな場合、Route 53 はその KSK を DNSSEC 署名に使用します。KSK を削除する際には、先に KSK を編集して、そのステータスを [**非アクティブ**] に設定する必要があります。
以下のステップに従って、 AWS マネジメントコンソールで KSK を編集します。
**KSK を編集するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、[**ホストゾーン**] をクリックした後で、ホストゾーンを選択します。
1. [**DNSSEC signing**] (DNSSEC 署名) タブの [**Key-signing keys (KSKs)**] (キー署名キー (KSK) ) の下にある [**Switch to advanced view**] (詳細表示に切替) を選択し、さらに [**Actions**] (アクション) の下にある [**Edit KSK**] (KSK の編集) を選択します。
1. KSK に対し必要な更新を行った上で、**[Save]** (保存) を選択します。
## キー署名キー (KSK) の削除
KSK を削除する際には、先に KSK を編集して、そのステータスを [**非アクティブ**] に設定する必要があります。
KSK の削除が必要となる理由の 1 つに、定期的に行うキーのローテーション作業があります。暗号キーについては、定期的にローテーションすることがベストプラクティスです。組織によっては、キーをローテーションさせる頻度に関する標準的な取り決めをしている場合があります。
ここでのステップに従って、 AWS マネジメントコンソールの KSK を削除します。
**KSK を削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、[**ホストゾーン**] をクリックした後で、ホストゾーンを選択します。
1. **[DNSSEC signing]** (DNSSEC 署名) タブを開き、**[Key-signing keys (KSKs)]** (キー署名キー (KSK)) で **[Switch to advanced view]** (詳細表示に切り替える) を選択し、さらに **[Actions]** (アクション) で **[Edit KSK]** (KSK の編集) を選択します。
1. ガイダンスに従って、KSK の削除を確認します。
# Route 53 での KMS キーと ZSK 管理
このセクションでは、Route 53 が DNSSEC 署名対応ゾーンに使用する現在の手法について説明します。
**注記**
Route 53 は、変更される可能性がある次のルールを使用します。将来変更があっても、お客様のゾーンまたは Route 53 のセキュリティ体制が減少することはありません。
**Route 53 が KSK AWS KMS に関連付けられた を使用する方法**
DNSSEC では、KSK を使用して DNSKEY リソースレコードセットのリソースレコード署名 (RRSIG) を生成します。すべての `ACTIVE` KSK は RRSIG 世代で使用されます。Route 53 は、関連付けられた KMS キーで `Sign` AWS KMS API を呼び出して RRSIG を生成します。詳細については、「*AWS KMS API ガイド*」の「[署名](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html)」を参照してください。これらの RRSIG は、ゾーンのリソースレコードセットの制限には数えられません。
RRSIG には有効期限があります。RRSIG の有効期限が切れるのを防ぐため、RRSIG は 1 ～ 7 日ごとに再生成して定期的に更新されます。
RRSIG は、次のいずれかの API を呼び出すたびに更新されます。
+ [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)
+ [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)
+ [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html)
+ [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)
+ [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
+ [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
Route 53 が更新を実行するたびに、関連付けられた KMS キーにアクセスできなくなった場合に備えて、数日後まで使用できる 15 個 の RRSIG を生成します。KMS キーコストの見積もりについては、定期的な更新が 1 日に 1 回行われると考えることができます。KMS キーポリシーを誤って変更すると、KMS キーにアクセスできなくなる可能性があります。アクセスできない KMS キーは、関連付けられた KSK のステータスを `ACTION_NEEDED` に設定します。最後の RRSIG の有効期限が切れた後、リゾルバーの検証でルックアップが失敗し始めるため、`DNSSECKeySigningKeysNeedingAction` エラーが検出されたときには CloudWatch アラームを設定して、この状態をモニタリングすることを強くお勧めします。詳細については、「[Amazon CloudWatch を使用したホストゾーンのモニタリング](monitoring-hosted-zones-with-cloudwatch.md)」を参照してください。
**Route 53 がゾーンの ZSK を管理する方法**
DNSSEC の署名が有効になっている新しいホストゾーンには、それぞれ 1 つの `ACTIVE` ゾーン署名キー (ZSK) があります。ZSK はホストゾーンごとに別々に生成され、Route 53 が所有しています。現在のキーアルゴリズムは ECDSAP256SHA256 です。
署名開始から 7～30 日以内に、ゾーンで通常の ZSK ローテーションの実行を開始します。現在、Route 53 は事前公開キーロールオーバー方式を使用しています。詳細については、「[Pre-Publish Zone Signing Key Rollover (事前公開ゾーン署名キーのロールオーバー)](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1)」を参照してください。この方法では、ゾーンに別の ZSK を導入します。ローテーションは 7～30 日ごとに繰り返されます。
Route 53 はゾーンの ZSK の変更を考慮するために DNSKEY リソースレコードセットの RRSIG を再生成できないため、ゾーンの KSK のいずれかが `ACTION_NEEDED` ステータスである場合、Route 53 は ZSK のローテーションを一時停止します。ZSK ローテーションは、条件がクリアされた後に自動的に再開されます。
# Route 53 での DNSSEC の非存在証明
**注記**
Route 53 は、変更される可能性がある次のルールを使用します。将来変更があっても、お客様のゾーンまたは Route 53 のセキュリティ体制が減少することはありません。
DNSSEC には、次の 3 種類の非存在証明があります。
+ クエリ名に一致するレコードが存在しないことの証明。
+ クエリタイプに一致するタイプが存在しないことの証明。
+ レスポンスにレコードを生成するために使用されるワイルドカードレコードが存在することの証明。
Route 53 は、BL メソッドを使用して、クエリ名と一致するレコードが存在しないことの証明を実装します。詳細については「[BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00)」を参照してください。これは、証明をコンパクトに表現し、ゾーンウォーキングを防ぐ方法です。
クエリ名と一致するレコードは存在するものの、クエリタイプが存在しない場合 (クエリの対象は、web.example.com/AAAA であるのに、web.example.com/A しか存在しないなど)、サポートされているすべてのリソースレコードタイプを含む最小の NSEC (次にセキュアな) レコードを返します。
Route 53 がワイルドカードレコードから結果を生成する場合、そのレスポンスには後に続くセキュアレコード、あるいはワイルドカードの NSEC レコードは付属しません。このような NSEC レコードは、レスポンスのリソースレコード署名 (RRSIG) が別のレスポンスを偽装するために再利用されないように、一部の実装 (通常はオフライン署名を実行する実装) で使用されます。Route 53 では、別のレスポンスで再利用できないレスポンスに固有の RRSIG を生成する非 DnsKey のレコードに、オンライン署名を使用しています。
# DNSSEC 署名のトラブルシューティング
このセクションの情報は、DNSSEC 署名の有効化、無効化、およびキー署名キー (KSK) の使用に関する問題を解決するのに役立ちます。
DNSSEC の有効化
DNSSEC 署名を有効化する前に、「[Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)」で前提条件を確認してください。
DNSSEC の無効化
DNSSEC を安全に無効化するために、Route 53 は、ターゲットゾーンが信頼チェーン内にあるかどうかを確認します。ターゲットゾーンの親に、そのターゲットゾーンの NS レコードと DS レコードがあることも確認します。NS と DS のクエリ時に SERVFAIL 応答が返されるなど、ターゲットゾーンがパブリックに解決できない場合には、Route 53 は DNSSEC を安全に無効化できるかどうかを判断できません。親ゾーンに接続し、これらの問題を修正した上で、DNSSEC の無効化を再試行します。
KSK のステータスが **[Action needed]** (アクションが必要) になっています
Route 53 DNSSEC が対応する へのアクセスを失った場合 (アクセス許可の変更または削除により）、KSK はステータスを**必要なアクション** AWS KMS key (または `ACTION_NEEDED` [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) ステータス) に変更できます AWS KMS key 。
KSK のステータスが [**Action needed**] (実行が必要) の場合、最終的に DNSSEC 検証リゾルバーを使用する顧客でゾーン停止が発生し、本番ゾーンが解決不能になることを防ぐため、迅速に対処しなければなりません。
問題を解決する場合、KSK の基になっているカスタマーマネージドキーが有効であり、適切なアクセス許可が付与されていることをご確認ください。必要な許可の詳細については、「[DNSSEC 署名に必要な Route 53 カスタマー管理キーアクセス許可](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC)」を参照してください。
KSK を修正したら、「」で説明されているように AWS CLI、コンソールまたは を使用して再度アクティブ化します[ステップ 2: DNSSEC 署名を有効にして KSK を作成](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable)。
今後この問題を回避するには、「」で提案されているように KSK の状態を追跡する Amazon CloudWatch メトリクスを追加することを検討してください[Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)。
KSK のステータスが **[Internal failure]** (内部エラー) になっています
KSK のステータスが [**Internal failure**] (内部障害) の場合 (または [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) ステータスで `INTERNAL_FAILURE`)、この問題が解決されるまで他の DNSSEC エンティティを操作することはできません。この KSK または他の KSK での作業を含め、DNSSEC 署名での操作を行う前に対策を取る必要があります。
この問題を解決するには、KSK のアクティブ化または非アクティブ化を再試行します。
API を使う際にこの問題を解決する場合、署名 ([EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)) の有効化、または署名の無効化 ([DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)) を試みます。
**[Internal failure]** (内部エラー) の問題には、迅速に対処することが重要です。この問題が解決されるまで、**[Internal failure]** (内部エラー) を修正するためのオペレーションを除き、ホストゾーンに対して他の変更を加えることはできません。