

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# パブリックホストゾーンの使用
<a name="AboutHZWorkingWith"></a>

パブリックホストゾーンは、あるドメイン、例えば example.com とそのサブドメイン (acme.example.com や zenith.example.com) のトラフィックをインターネットまたは特定のドメインでルーティングする方法についての情報を保持するコンテナです。パブリックホストゾーンは、次の 2 つの方法で入手できます。
+ Route 53 にドメインを登録すると、そのドメインのホストゾーンが自動的に作成されます。
+ 既存のドメインの DNS サービスを Route 53 に転送する場合は、まずドメインのホストゾーンを作成します。詳細については、「[Amazon Route 53 を既存ドメインの DNS サービスとして使用するRoute 53 を既存ドメインの DNS サービスにする](MigratingDNS.md)」を参照してください。

どちらの場合も、ホストゾーンにレコードを作成して、ドメインとサブドメインのトラフィックをどのようにルーティングするかを指定します。例えば、www.example.com へのトラフィックを、CloudFront ディストリビューションや、データセンターのウェブサーバーにルーティングするためのレコードを作成することができます。レコードの詳細については、「[レコードを使用する](rrsets-working-with.md)」を参照してください。

このトピックでは、Amazon Route 53 コンソールを使用してパブリックホストゾーンを作成、一覧表示、削除する方法を説明します。

**注記**  
Amazon VPC サービスを使用して作成した 1 つ以上の VPC 内で、Route 53 *プライベート*ホストゾーンを使用してトラフィックをルーティングすることもできます。詳細については、「[プライベートホストゾーンの使用](hosted-zones-private.md)」を参照してください。

**Topics**
+ [パブリックホストゾーンを使用する場合の考慮事項](hosted-zone-public-considerations.md)
+ [パブリックホストゾーンの作成](CreatingHostedZone.md)
+ [パブリックホストゾーンに対するネームサーバーの取得](GetInfoAboutHostedZone.md)
+ [パブリックホストゾーンの一覧表示](ListInfoOnHostedZone.md)
+ [パブリックホストゾーンの DNS クエリメトリクスの表示](hosted-zone-public-viewing-query-metrics.md)
+ [パブリックホストゾーンの削除](DeleteHostedZone.md)
+ [Route 53 からの DNS 応答の確認](dns-test.md)
+ [ホワイトラベルネームサーバーの設定](white-label-name-servers.md)
+ [Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード](SOA-NSrecords.md)
+ [パブリック DNS レコードを管理するための高速リカバリの有効化](accelerated-recovery.md)

# パブリックホストゾーンを使用する場合の考慮事項
<a name="hosted-zone-public-considerations"></a>

パブリックホストゾーンを使用する場合は、以下の点を考慮してください。

**NS レコードと SOA レコード**  
ホストゾーンを作成すると、Amazon Route 53 はそのゾーンに対して、1 つのネームサーバー (NS) レコードと、1 つの Start of Authority (SOA) レコードを自動的に作成します。NS レコードはレジストラまたは DNS サービスに付与された 4 つのネームサーバーを識別し、DNS クエリが Route 53 ネームサーバーにルーティングされるようにします。NS および SOA レコードの詳細については、「[Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード](SOA-NSrecords.md)」を参照してください。

**同じ名前を持つ複数のホストゾーン**  
同じ名前を持つ複数のホストゾーンを作成し、各ホストゾーンに異なるレコードを追加できます。Route 53 は、4 つのネームサーバーをホストゾーンごとに割り当てます。ネームサーバーは各ホストゾーンで異なります。レジストラのネームサーバーレコードを更新する際には、 Route 53 ネームサーバーが、(ドメインのクエリに応答する場合に Route 53 が使用するレコードが含まれる) 正しいホストゾーンを使用するようにしてください。Route 53 が、同じ名前の他のホストゾーンのレコードに値を返すことは決してありません。

**再利用可能な委託セット**  
デフォルトで、Route 53 は作成された各ホストゾーンに対し、 4 つのネームサーバーによる一意なセット (まとめて委託セットと呼ばれます) を割り当てます。多数のホストゾーンを作成する場合は、プログラムで再利用可能な委託セットを作成できます。(再利用可能な委託セットは Route 53 コンソールからは操作できません)。次に、ホストゾーンをプログラムで作成し、同じ再利用可能な委任セット (同じ 4 つのネームサーバー) を各ホストゾーンに割り当てることができます。  
再利用可能な委託セットにより、Route 53 を DNS サービスとして使用するすべてのドメインで、同じ 4 つのネームサーバーを使用するようドメイン名のレジストラに指示できるため、DNS サービスの Route 53 への移行が簡素化されます。詳細については、[Amazon Route 53 API リファレンス](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)の「*CreateReusableDelegationSet*」を参照してください。

# パブリックホストゾーンの作成
<a name="CreatingHostedZone"></a>

パブリックホストゾーンは、あるドメイン、例えば example.com とそのサブドメイン (acme.example.com や zenith.example.com) のトラフィックをインターネットまたは特定のドメインでルーティングする方法についての情報を保持するコンテナです。ホストゾーンを作成した後で、ドメインとサブドメインのトラフィックをどのようにルーティングするかを指定するレコードを作成します。

**制限事項**  
Route 53 でホストゾーンを作成するための以下の制限に注意してください。  
ホストゾーンは、管理権限を持つドメインに対してのみ作成できます。通常、これはドメインを所有していることを指しますが、ドメインの登録者向けにアプリケーションを開発している場合にも当てはまります。
ホストゾーンは、ドメインとサブドメインに対してのみ作成できます。Route 53 は、`.com` などの最上位ドメイン (TLD) のホスティングをサポートしていません。

**Route 53 コンソールを使用してパブリックホストゾーンを作成するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。

1. Route 53 を初めて使用する場合は、[**DNS management (DNS の管理)**] で [**Get started (今すぐ始める) **] を選択します。

   既に Route 53 を利用している場合は、ナビゲーションペインの [**Hosted zones (ホストゾーン)**] を選択します。

1. [**ホストゾーンの作成**] を選択します。

1. [**Create Hosted Zone (ホストゾーンの作成)**] ペインに、そのトラフィックをルーティングするドメインの名前を入力します。オプションでコメントも入力できます。

   a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。

1. [**Type**] は、デフォルト値である [**Public Hosted Zone**] のままにします。

1. **[作成]** を選択します。

1. ドメインとサブドメインのトラフィックをどのようにルーティングするかを指定するレコードを作成します。詳細については、「[レコードを使用する](rrsets-working-with.md)」を参照してください。

1. 新しいホストゾーンのレコードを使用してドメインのトラフィックをルーティングする場合は、該当するトピックを参照してください。
   + Route 53 を、別のドメインレジストラに登録されているドメインの DNS サービスとして使用する場合は、「[Amazon Route 53 を既存ドメインの DNS サービスとして使用するRoute 53 を既存ドメインの DNS サービスにする](MigratingDNS.md)」を参照してください。
   + Route 53 に登録されているドメインに関しては、「[ドメインのネームサーバーおよびグルーレコードの追加あるいは変更](domain-name-servers-glue-records.md)」を参照してください。

# パブリックホストゾーンに対するネームサーバーの取得
<a name="GetInfoAboutHostedZone"></a>

ドメイン登録の DNS サービスを変更する場合は、パブリックホストゾーンのネームサーバーを取得します。DNS サービスを変更する方法については、「[Amazon Route 53 を既存ドメインの DNS サービスとして使用するRoute 53 を既存ドメインの DNS サービスにする](MigratingDNS.md)」を参照してください。

**注記**  
一部のレジストラでは、IP アドレスの使用によるネームサーバーの指定のみが許可され、完全修飾ドメイン名を指定することはできません。レジストラが IP アドレスを使用する必要がある場合は、dig ユーティリティ (Mac、Unix、Linux の場合) または nslookup ユーティリティ (Windows の場合) を使用してネームサーバーの IP アドレスを取得できます。一般的に、ネームサーバーの IP アドレスが変更されることはほとんどありません。IP アドレスを変更する必要がある場合は、事前に通知されます。

**Route 53 コンソールを使用してホストゾーンのネームサーバーを取得するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。

1. ナビゲーションペインで [**Hosted zones (ホストゾーン)**] をクリックします。

1. [**Hosted Zones (ホストゾーン)**] ページで、ホストゾーンのラジオボタン (名前ではない) を選択し、[**View details (詳細を表示)**] を選択します。

1. ホストゾーンの詳細ページで、[**Hosted zone details (ホストゾーンの詳細)**] を選択します。

1. **[Name Servers]** (ネームサーバー) で一覧表示されている 4 つのサーバー名を書き留めます。

# パブリックホストゾーンの一覧表示
<a name="ListInfoOnHostedZone"></a>

Amazon Route 53 コンソールを使用して、現在の AWS アカウントで作成したすべてのホストゾーンを一覧表示できます。Route 53 API を使用してホストゾーンを一覧表示する方法については、*Amazon Route 53 API リファレンス*の「[ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)」を参照してください。

**Route 53 コンソールを使用して AWS アカウントに関連付けられたパブリックホストゾーンを一覧表示するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。

1. ナビゲーションペインで [**Hosted zones**] を選択します。このページには、現在サインインしている AWS アカウントに関連付けられているホストゾーンのリストが表示されます。

1.  ホストゾーンをフィルタリングするには、表の上部にある検索バーを使用します。

   検索動作は、ホストゾーンに最大で 2,000 のレコードが含まれているか、または 2,000 を超えるレコードが含まれているかによって異なります。

   **最大 2,000 のホストゾーン**
   + 特定の値を持つレコードを表示するには、検索バーをクリックし、ドロップダウンリストでそのプロパティを選択した上で値を入力します。検索バーに値を直接入力し、Enter を押すこともできます。例えば、名前が **abc** で始まるホストゾーンを表示する場合は、この値を検索バーに入力した後で Enter キーを押します。
   + ホストゾーンタイプが共通なホストゾーンのみを表示するには、ドロップダウンリストから対象のタイプを選択し、タイプを入力します。

   **2,000 を超えるホストゾーン**
   + プロパティは、完全なドメイン名、すべてのプロパティ、およびタイプに基づいて検索できます。
   + 完全なドメイン名を使用して検索すると、検索結果が速く得られます。

# パブリックホストゾーンの DNS クエリメトリクスの表示
<a name="hosted-zone-public-viewing-query-metrics"></a>

指定したパブリックホストゾーン、またはパブリックホストゾーンの組み合わせについて、Route 53 が応答している DNS クエリの総数を表示できます。メトリクスは CloudWatch に表示されるので、グラフの表示、調査したい期間の選択、その他のさまざまな方法でメトリクスのカスタマイズを行うことができます。アラームを作成して通知を設定することもできます。これにより、指定した期間内の DNS クエリの数が指定したレベルを超える、または下回ったときに通知を受け取ることができます。

**注記**  
Route 53 では、すべてのパブリックホストゾーンでの DNS クエリの数を CloudWatch に自動的に送信するため、何も設定しなくてもクエリメトリクスを表示できます。DNS クエリメトリクスには料金はかかりません。

**どの DNS クエリがカウントされますか?**  
メトリクスには、DNS リゾルバーが Route 53 に転送するクエリのみが含まれます。DNS リゾルバーが既にクエリ (example.com のロードバランサーの IP アドレスなど) への応答をキャッシュしている場合、リゾルバーは Route 53 へのクエリの転送は行わず、対応するレコードの TTL の有効期限が切れるまで、キャッシュされた応答を返信し続けます。  
ドメイン名 (example.com) またはサブドメイン名 (www.example.com) に送信された DNS クエリ数、ユーザーが使用しているリゾルバー、およびレコードの TTL によって、DNS クエリメトリクスに含まれる情報は DNS リゾルバーに送信された数千件の各クエリのうち 1 つのクエリのみに関するものである場合があります。DNS の仕組みについては、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください。

**ホストゾーンのクエリメトリクスは、いつ CloudWatch に表示され始めますか？**  
ホストゾーンを作成した後、そのホストゾーンが CloudWatch に表示されるまでに最大数時間の遅延が発生します。また、表示するデータが存在するように、ホストゾーンのレコードの DNS クエリを送信する必要があります。

**メトリクスは米国東部 (バージニア北部) でのみ利用できます**  
コンソールでメトリクスを取得するには、リージョンに米国東部 (バージニア北部) を指定する必要があります。 AWS CLI を使用してメトリクスを取得するには、 AWS リージョンを指定しないままにするか、リージョン`us-east-1`として を指定する必要があります。他のリージョンを選択した場合、Route 53 メトリクスは使用できません。

**DNS クエリの CloudWatch メトリクスとディメンション**  
DNS クエリの CloudWatch メトリクスとディメンションの詳細については、「[Amazon CloudWatch を使用したホストゾーンのモニタリング](monitoring-hosted-zones-with-cloudwatch.md)」を参照してください。CloudWatch メトリクスの詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)」を参照してください。

**DNS クエリに関する詳細データの取得**  
Route 53 が応答する各 DNS クエリの詳細情報 (以下の値を含む) を取得するには、クエリログ記録を設定します。  
+ リクエストされたドメインまたはサブドメイン
+ リクエストの日付と時刻
+ DNS レコードタイプ (A や AAAA など)
+ DNS クエリに応答した Route 53 エッジロケーション
+ DNS レスポンスコード (`NoError` や `ServFail` など)
詳細については、「[パブリック DNS クエリのログ記録](query-logs.md)」を参照してください。

**DNS クエリメトリクスの取得方法**  
ホストゾーンを作成するとすぐに、Amazon Route 53 は、メトリクスとディメンションを CloudWatch に対し 1 分間隔で送信し始めます。次の手順を使用して、CloudWatch コンソールでメトリクスを表示するか、 AWS Command Line Interface () を使用してメトリクスを表示できますAWS CLI。

**Topics**
+ [CloudWatch コンソールでのパブリックホストゾーンの DNS クエリメトリクスの表示](#hosted-zone-public-viewing-query-metrics-console)
+ [を使用した DNS クエリメトリクスの取得 AWS CLI](#hosted-zone-public-viewing-query-metrics-cli)

## CloudWatch コンソールでのパブリックホストゾーンの DNS クエリメトリクスの表示
<a name="hosted-zone-public-viewing-query-metrics-console"></a>

CloudWatch コンソールでパブリックホストゾーンの DNS クエリメトリクスを表示するには、以下の手順を実行します。<a name="hosted-zone-public-viewing-query-metrics-console-procedure"></a>

**CloudWatch コンソールでパブリックホストゾーンの DNS クエリメトリクスを表示するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) で CloudWatch コンソールを開きます。

1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。

1. コンソールの右上隅にある AWS リージョンリストで、**米国東部 (バージニア北部)** を選択します。他の AWS リージョンを選択した場合、Route 53 メトリクスは使用できません。

1. [**All metrics**] タブで、[**Route 53**] を選択します。

1. [**Hosted Zone Metrics (ホストゾーンのメトリクス)**] を選択します。

1. メトリクス名 **DNSQueries** を持つ 1 つ以上のホストゾーンのチェックボックスをオンにします。

1. [**グラフ化したメトリクス**] タブで、該当する値を変更して、目的の形式でメトリクスを表示します。

   [**統計**] で、[**Sum**] または [**SampleCount**] を選択します。これらの統計はどちらも同じ値を表示します。

## を使用した DNS クエリメトリクスの取得 AWS CLI
<a name="hosted-zone-public-viewing-query-metrics-cli"></a>

を使用して DNS クエリメトリクスを取得するには AWS CLI、[get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) コマンドを使用します。次の点に注意してください。
+ コマンドのほとんどの値は、別の JSON ファイルで指定します。詳細については、「[get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)」を参照してください。
+ コマンドは、JSON ファイル `Period` で指定した間隔ごとに 1 つの値を返します。`Period` は秒単位であるため、5 分の期間を指定し `60` に `Period` を指定すると、5 つの値が取得されます。5 分の期間を指定し、`300` に `Period` を指定した場合、1 つの値が取得されます。
+ JSON ファイルでは、`Id` に任意の値を指定できます。
+  AWS リージョンを指定しないままにするか、リージョン`us-east-1`として を指定します。他のリージョンを選択した場合、Route 53 メトリクスは使用できません。詳細については、[AWS 「 ユーザーガイド」の「 CLI の設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」を参照してください。 *AWS Command Line Interface *

以下は、2019 年 5 月 1 日の 4:01 から 4:07 までの 5 分間の DNS クエリメトリクスを取得するために使用する AWS CLI コマンドです。`metric-data-queries` パラメータは、コマンドに続くサンプル JSON ファイルを参照します。

```
aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z
```

サンプル JSON ファイルを次に示します。

```
[
    {
        "Id": "my_dns_queries_id",
        "MetricStat": {
            "Metric": {
                "Namespace": "AWS/Route53",
                "MetricName": "DNSQueries",
                "Dimensions": [
                    {
                        "Name": "HostedZoneId",
                        "Value": "Z1D633PJN98FT9"
                    }
                ]
            },
            "Period": 60,
            "Stat": "Sum"
        },
        "ReturnData": true
    }
]
```

このコマンドの出力は次のとおりです。次の点に注意してください。
+ コマンドの開始時刻と終了時刻は、7 分間の期間 (`2019-05-01T04:01:00Z` から `2019-05-01T04:07:00Z`) を対象としています。
+ 戻り値は 6 つだけです。`2019-05-01T04:05:00Z` に値がないのは、その 1 分間に DNS クエリがなかったためです。
+ JSON ファイルで指定された `Period` の値は `60` (秒) であるため、値は 1 分間隔で報告されます。

```
{
    "MetricDataResults": [
        {
            "Id": "my_dns_queries_id",
            "StatusCode": "Complete",
            "Label": "DNSQueries",
            "Values": [
                101.0,
                115.0,
                103.0,
                127.0,
                111.0,
                120.0
            ],
            "Timestamps": [
                "2019-05-01T04:07:00Z",
                "2019-05-01T04:06:00Z",
                "2019-05-01T04:04:00Z",
                "2019-05-01T04:03:00Z",
                "2019-05-01T04:02:00Z",
                "2019-05-01T04:01:00Z"
            ]
        }
    ]
}
```

# パブリックホストゾーンの削除
<a name="DeleteHostedZone"></a>

このセクションでは、Amazon Route 53 コンソールを使用してパブリックホストゾーンを削除する方法を説明します。

デフォルトの SOA レコードと NS レコード以外のレコードがない場合にのみ、ホストゾーンを削除できます。ホストゾーンに他のレコードが含まれる場合、ホストゾーンを削除する前にそれらを削除する必要があります。これによって、レコードが含まれているホストゾーンを誤って削除するのを防ぎます。

**Topics**
+ [トラフィックがドメインにルーティングされないようにする](#delete-public-hosted-zone-stop-routing)
+ [別のサービスによって作成されたパブリックホストゾーンを削除する](#delete-public-hosted-zone-created-by-another-service)
+ [Route 53 コンソールを使用してのパブリックホストゾーンの削除](#delete-public-hosted-zone-procedure)

## トラフィックがドメインにルーティングされないようにする
<a name="delete-public-hosted-zone-stop-routing"></a>

ドメイン登録は維持するものの、ウェブサイトやウェブアプリケーションへのインターネットトラフィックのルーティングを停止する場合、ホストゾーンを削除する代わりに、ホストゾーン内の*レコード*を削除することをお勧めします。

**重要**  
ホストゾーンを削除した場合、復元することはできません。新しいホストゾーンを作成して、ドメイン登録のネームサーバーを更新する必要があります。更新が有効になるには、最大 48 時間かかることがあります。さらに、ホストゾーンを削除すると、他のユーザーがお客様のドメイン名を使用してドメインをハイジャックし、自分のリソースにトラフィックをルーティングする可能性があります。  
サブドメインの責任をホストゾーンに委任し、子ホストゾーンを削除する場合は、子ホストゾーンと同じ名前の NS レコードを削除して、親ホストゾーンも更新する必要があります。例えば、ホストゾーン acme.example.com を削除する場合は、example.com ホストゾーンの NS レコード acme.example.com も削除する必要があります。最初に NS レコードを削除し、NS レコードの TTL が経過するまで待ってから、子ホストゾーンを削除することをお勧めします。これにより、子ホストゾーンのネームサーバーがまだ DNS リゾルバーにキャッシュされている間に、子ホストゾーンのハイジャックを防止できます。

ホストゾーンの月額料金を回避するには、ドメインの DNS サービスを無料の DNS サービスに転送することもできます。DNS サービスを転送する場合、ドメイン登録のネームサーバーを更新する必要があります。ドメインが Route 53 に登録されている場合に、新しい DNS サービスのネームサーバーを使用して Route 53 ネームサーバーを置き換える方法については、「[ドメインのネームサーバーおよびグルーレコードの追加あるいは変更](domain-name-servers-glue-records.md)」を参照してください。ドメインが他のレジストラに登録されている場合、レジストラが提供する方法を使用してドメイン登録のネームサーバーを更新します。詳細については、「無料の DNS サービス」についてインターネットで検索してください。

## 別のサービスによって作成されたパブリックホストゾーンを削除する
<a name="delete-public-hosted-zone-created-by-another-service"></a>

ホストゾーンが別のサービスで作成されている場合、Route 53 コンソールを使用して削除することはできません。代わりに、他のサービスに該当するプロセスを使用する必要があります。
+ **AWS Cloud Map** – パブリック DNS 名前空間の作成時に AWS Cloud Map が作成したホストゾーンを削除するには、namespace を削除します。 はホストゾーンを自動的に AWS Cloud Map 削除します。詳細については、*AWS Cloud Map デベロッパーガイド*の[名前空間の削除](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html)を参照してください。
+ **Amazon Elastic Container Service (Amazon ECS) Service Discovery** – Service Discovery を使用してサービスを作成した際に Amazon ECS が作成したパブリックホストゾーンを削除するには、名前空間を使用している Amazon ECS サービスを削除した上で、その名前空間を削除します。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の「[サービスの削除](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html)」を参照してください。

## Route 53 コンソールを使用してのパブリックホストゾーンの削除
<a name="delete-public-hosted-zone-procedure"></a>

Route 53 コンソールを使用してパブリックホストゾーンを削除するには、以下の手順を実行します。

**Route 53 コンソールを使用してパブリックホストゾーンを削除するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。

1. ナビゲーションペインで **[Hosted zones]** (ホストゾーン) を選択した後に、削除するホストゾーンの強調表示されたリンクを選択します。

1. 削除するホストゾーンに NS と SOA のレコードのみが含まれていることを確認します。他のレコードが含まれている場合は、それらを削除します。また、DNSSEC 署名を無効にする必要があります。
**注記**  
これらの要件を満たさずにホストゾーンを削除しようとすると、Route 53 はエラーを返します。  
DNSSEC 署名が有効になっている場合: 指定されたホストゾーンに DNSSEC キー署名キーが含まれているため、削除できません
他のリソースレコードセットが存在する場合 (デフォルトの SOA および NS レコードを除く): 指定されたホストゾーンには必須ではないリソースレコードセットが含まれているため、削除できません

   1. ホストゾーンの詳細ページにある **[Records]** (レコード) リストで、**[Type]** (タイプ) 列の値が「NS」または「SOA」以外に設定されたレコードがある場合には、その行を選択し、次に **[Delete]** (削除) を選択します。

     複数の連続するレコードを選択するには、最初の行を選択し、[**Shift**] (シフト) キーを押したまま最後の行を選択します。複数の連続していないレコードを選択するには、最初の行を選択し、**Ctrl** キーを押したまま、残りの行を選択します。
**注記**  
ホストゾーンでサブドメインの NS レコードを作成した場合は、それらのレコードも削除します。

1. **[Hosted Zones]** (ホストゾーン) ページで、削除するホストゾーンの行を選択します。

1. **[削除]** を選択します。

1. 確認キーを入力し、[**Delete (削除)**] を選択します。

1. ドメインをインターネット上で利用できなくするには、DNS サービスを無料の DNS サービスに移管し、Route 53 のホストゾーンを削除することをお勧めします。これにより、今後の DNS クエリが誤ってルーティングされることを防ぐことができます。

   ドメインが Route 53 に登録されている場合に、新しい DNS サービスのネームサーバーを使用して Route 53 ネームサーバーを置き換える方法については、「[ドメインのネームサーバーおよびグルーレコードの追加あるいは変更](domain-name-servers-glue-records.md)」を参照してください。ドメインが他のレジストラに登録されている場合、レジストラが提供する方法を使用してドメインのネームサーバーを変更します。
**注記**  
サブドメイン (acme.example.com) のホストゾーンを削除する場合は、ドメイン (example.com) のネームサーバーを変更する必要はありません。

# Route 53 からの DNS 応答の確認
<a name="dns-test"></a>

ドメインに Amazon Route 53 ホストゾーンを作成すると、コンソールから DNS チェックツールが使用可能になります。これにより、Route 53 を DNS サービスとして使用するようドメインを設定している場合に、Route 53 が DNS クエリにどのように応答しているかを確認できます。位置情報、地理的近接性、レイテンシーのレコードの場合、特定の DNS リゾルバーやクライアント IP アドレスからのクエリをシミュレートして、Route 53 が返すレスポンスを確認することもできます。

**重要**  
このツールはドメインネームシステムにクエリを送信しません。ホストゾーンのレコードの設定にのみ基づいて応答します。このツールは、ホストゾーンがドメインのトラフィックをルーティングするために現在使用されているかどうかにかかわらず、同じ情報を返します。

DNS チェックツールは、パブリックホストゾーンにのみ使用できます。

**注記**  
DNS チェックツールが、`dig` コマンドの応答セクションで想定される情報と同じ情報を返します。したがって、親ネームサーバーを指すサブドメインのネームサーバーをクエリしても、それらは返されません。

**Topics**
+ [チェックツールを使用した DNS クエリへの Amazon Route 53 の応答の確認](#dns-test-how-route-53-responds)
+ [チェックツールを使用した特定の IP アドレスからのクエリのシミュレート (位置情報およびレイテンシーレコードのみ)](#dns-test-simulate-requests)

## チェックツールを使用した DNS クエリへの Amazon Route 53 の応答の確認
<a name="dns-test-how-route-53-responds"></a>

ツールを使用して、レコードに対する DNS クエリへの応答として Amazon Route 53 が返すレスポンスを確認できます。<a name="dns-test-how-route-53-responds-procedure"></a>

**チェックツールを使用して、Route 53 が DNS クエリにどうのように応答するかを確認するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。

1. ナビゲーションペインで [**Hosted Zones**] を選択します。

1. [**Hosted Zones**] ページで、ホストゾーンの名前を選択します。コンソールには、ホストゾーンのレコードのリストが表示されます。

1. [**Check response from Route 53 (Route 53 からの応答を確認)**] ページに直接移動するには、[**Test record (レコードをテスト)**] を選択します。

1. 次の値を指定します。
   + ホストゾーンの名前を除く、レコードの名前。たとえば、**www.example.com** をチェックするには、**www** と入力します。**example.com** をチェックするには、[**レコード名**] フィールドを空白のままにします。
   + チェックするレコードのタイプ (**A** や **CNAME** など)。

1. [**Get Response**] を選択します。

1. [**Response returned by Route 53**] セクションには、次の値が表示されます。  
**DNS レスポンスコード**  
クエリが有効であったかどうかを示すコード。最も一般的なレスポンスコードは、クエリが有効であったことを意味する **NOERROR** です。レスポンスが有効でない場合、Route 53 はその理由を示すレスポンスコードを返します。返されるレスポンスコードのリストについては、IANA ウェブサイトで「[DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6)」を参照してください。  
**プロトコル**  
Amazon Route 53 がクエリの応答に使用したプロトコル (**UDP** または **TCP**)。  
**Route 53 によって返されるレスポンス**  
Route 53 がウェブアプリケーションに返す値。値は次のいずれかです。  
   + 非エイリアスレコードの場合、レスポンスにはレコード内の値が含まれています。
   + 同じ名前およびタイプの複数レコードの場合 (加重、レイテンシー、位置情報、フェイルオーバーを含む)、リクエストに基づいて、レスポンスには該当するレコードからの値が含まれています。
   + 別のレコード以外の AWS リソースを参照するエイリアスレコードの場合、レスポンスにはリソースのタイプに応じて、 AWS リソースの IP アドレスまたはドメイン名が含まれます。
   + 他のレコードを参照するエイリアスレコードの場合、レスポンスには参照されるレコードの値が含まれています。

## チェックツールを使用した特定の IP アドレスからのクエリのシミュレート (位置情報およびレイテンシーレコードのみ)
<a name="dns-test-simulate-requests"></a>

レイテンシーまたは位置情報レコードを作成した場合、チェックツールを使用して DNS リゾルバーおよびクライアントの IP アドレスからのクエリをシミュレートできます。<a name="dns-test-simulate-requests-procedure"></a>

**チェックツールを使用して、指定された IP アドレスからのクエリをシミュレートするには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。

1. ナビゲーションペインで [**Hosted Zones**] を選択します。

1. [**Hosted Zones**] ページで、ホストゾーンの名前を選択します。コンソールには、ホストゾーンのレコードのリストが表示されます。

1. [**Check response from Route 53**] ページに直接移動するには、[**Test record set**] を選択します。

   特定のレコードの [**Check response from Route 53**] (Route 53 からのレスポンスを確認) ページに移動するには、そのレコードのチェックボックスを選択し、[**Test record set**] (レコードセットのテスト) を選択します。

1. まずレコードを選択せずに [**レコードセットのテスト**] を選択した場合、次の値を指定します。
   + ホストゾーンの名前を除く、レコードの名前。たとえば、**www.example.com** をチェックするには、**www** と入力します。**example.com** をチェックするには、[**レコード名**] フィールドを空白のままにします。
   + チェックするレコードのタイプ (**A** や **CNAME** など)。

1. 適用可能な値を指定します。  
**リゾルバー IP アドレス**  
クライアントがリクエストに使用する DNS リゾルバーの場所をシミュレートする IPv4 または IPv6 アドレスを指定します。これは、レイテンシーおよび位置情報レコードのテストに役立ちます。この値を省略すると、ツールは AWS 米国東部 (バージニア北部) リージョン (us-east-1) の DNS リゾルバーの IP アドレスを使用します。  
**EDNS0 クライアントサブネット IP**  
リゾルバーが EDNS0 をサポートしている場合は、該当する地理的な場所の IP アドレスのクライアントサブネット IP (例: **192.0.2.0**、**2001:db8:85a3::8a2e:370:7334**) を入力します。  
**サブネットマスク**  
[**EDNS0 client subnet IP**] に IP アドレスを指定した場合、オプションで、チェックツールが DNS クエリに含める IP アドレスのビット数を指定できます。例えば、**EDNS0 クライアントサブネット IP** に **192.0.2.44** を指定し、**サブネットマスク**に **24** を指定した場合には、チェックツールは **192.0.2.0/24** からのクエリをシミュレートします。デフォルト値は IPv4 アドレスの場合は 24 ビット、IPv6 アドレスの場合は 64 ビットです。

1. [**Get Response**] を選択します。

1. [**Response returned by Route 53**] セクションには、次の値が表示されます。  
**Route 53 に送信された DNS クエリ**  
クエリは、[BIND 形式](https://en.wikipedia.org/wiki/Zone_file)で、チェックツールが Route 53 に送信されたことを確認します。これは、ウェブアプリケーションがクエリの送信に使用するのと同じ形式です。3 つの値は通常、レコードの名前、**IN** (インターネットの場合)、レコードのタイプです。  
**DNS レスポンスコード**  
クエリが有効であったかどうかを示すコード。最も一般的なレスポンスコードは、クエリが有効であったことを意味する **NOERROR** です。レスポンスが有効でない場合、Route 53 はその理由を示すレスポンスコードを返します。返されるレスポンスコードのリストについては、IANA ウェブサイトで「[DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6)」を参照してください。  
**プロトコル**  
Amazon Route 53 がクエリの応答に使用したプロトコル (**UDP** または **TCP**)。  
**Route 53 によって返されるレスポンス**  
Route 53 がウェブアプリケーションに返す値。値は次のいずれかです。  
   + 非エイリアスレコードの場合、レスポンスにはレコード内の値が含まれています。
   + 同じ名前およびタイプの複数レコードの場合 (加重、レイテンシー、位置情報、フェイルオーバーを含む)、リクエストに基づいて、レスポンスには該当するレコードからの値が含まれています。
   + 別のレコード以外の AWS リソースを参照するエイリアスレコードの場合、レスポンスにはリソースのタイプに応じて、 AWS リソースの IP アドレスまたはドメイン名が含まれます。
   + 他のレコードを参照するエイリアスレコードの場合、レスポンスには参照されるレコードの値が含まれています。

# ホワイトラベルネームサーバーの設定
<a name="white-label-name-servers"></a>

各 Amazon Route 53 ホストゾーンは、まとめて委託セットと呼ばれる 4 つのネームサーバーに関連付けられています。デフォルトでは、これらのネームサーバーは ns-2048.awsdns-64.com のような名前です。ネームサーバーのドメイン名をホストゾーンのドメイン名、例えば ns1.example.com と同じにする場合は、ホワイトラベルネームサーバー (別名バニティネームサーバーまたはプライベートネームサーバー) を設定できます。

複数のドメインで再利用できる 4 つのホワイトラベルネームサーバーの組を設定する方法を次のステップで説明します。例えば、example.com、example.org、example.net というドメインを所有しているとします。このステップで example.com のホワイトラベルネームサーバーを設定し、それを example.org と example.net で再利用できます。

**Topics**
+ [ステップ 1: 再利用可能な Route 53 の委任セットを作成する](#white-label-name-servers-create-reusable-delegation-set)
+ [ステップ 2: Amazon Route 53 ホストゾーンを作成または再作成し、NS レコードと SOA レコードの TTL を変更する](#white-label-name-servers-create-hosted-zones)
+ [ステップ 3: ホストゾーンにレコードを再作成する](#white-label-name-servers-create-resource-record-sets)
+ [ステップ 4: IP アドレスを取得します](#white-label-name-servers-get-ip-addresses)
+ [ステップ 5: ホワイトラベルネームサーバーにレコードを作成する](#white-label-name-servers-create-white-label-resource-record-sets)
+ [ステップ 6: NS と SOA レコードを更新します](#white-label-name-servers-update-ns-soa-records)
+ [ステップ 7: グルーレコードを作成し、レジストラの名前サーバーを変更します。](#white-label-name-servers-create-glue-records)
+ [ステップ 8: ウェブサイトまたはアプリケーションのトラフィックをモニタリングします。](#white-label-name-servers-monitor-traffic)
+ [ステップ 9: TTL を元の値に戻す](#white-label-name-servers-change-ttls-back)
+ [ステップ 10: (オプション) 再帰的な DNS サービスへのお問い合わせ](#white-label-name-servers-contact-recursive-dns-services)

## ステップ 1: 再利用可能な Route 53 の委任セットを作成する
<a name="white-label-name-servers-create-reusable-delegation-set"></a>

ホワイトラベルネームサーバーは、Route 53 の再利用可能な委任セットに関連付けられています。ホストゾーンと再利用可能な委任セットが同じ AWS アカウントによって作成された場合にのみ、ホストゾーンにホワイトラベルネームサーバーを使用できます。

再利用可能な委任セットを作成するには、Route 53 API、 CLI、またはいずれかの AWS SDKs AWS を使用できます。詳細については、次のドキュメントを参照してください。
+ **Route 53 API** – *Amazon Route 53 API リファレンス*の「[CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)」を参照してください 
+ **AWS CLI** – *AWS CLI コマンドリファレンス*の [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html) を参照してください。
+ **AWS SDKs** ドキュメントページの該当する SDK [AWS ドキュメント](https://docs.aws.amazon.com/)を参照してください。

## ステップ 2: Amazon Route 53 ホストゾーンを作成または再作成し、NS レコードと SOA レコードの TTL を変更する
<a name="white-label-name-servers-create-hosted-zones"></a>

Amazon Route 53 ホストゾーンを作成または再作成します。
+ **ホワイトラベルネームサーバーを使用するドメインの DNS サービスとして現在 Route 53 を使用していない場合** – ホストゾーンを作成し、以前のステップで作成した再利用可能な委託セットを各ホストゾーンに指定します。詳細については、*Amazon Route 53 API リファレンス*の「[CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)」を参照してください。
+ **ホワイトラベルネームサーバーを使用するドメインの DNS サービスとして Route 53 を使用している場合** – ホワイトラベルネームサーバーを使用するホストゾーンは再作成する必要があります。その後、以前のステップで作成した再利用可能な委託セットを各ホストゾーンに指定します。
**重要**  
既存のホストゾーンに関連付けられるネームサーバーを変更することはできません。再利用可能な委託セットをホストゾーンに関連付けることができるのは、ホストゾーンを作成するときのみです。

ホストゾーンを作成して、それに該当するドメインのリソースにアクセスを試みる前に、各ホストゾーンの次の TTL 値を変更します。
+ ホストゾーンの NS レコードの TTL を 60 秒以下に変更します。
+ ホストゾーンの SOA レコードの最小 TTL を 60 秒以下に変更します。これは SOA レコードの最後の値です。

誤ってレジストラにホワイトラベルネームサーバーの間違った IP アドレスを伝えた場合、ウェブサイトが利用できなくなり、問題を解決しても TTL の期間が経過するまでは利用できないままです。TTL を低い値に設定することで、ウェブサイトが利用できない時間を短縮できます。

ホストゾーンの作成と、ホストゾーンのネームサーバーに再利用可能な委任セットを指定する方法の詳細については、*Amazon Route 53 API リファレンス*の「[CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)」を参照してください。

## ステップ 3: ホストゾーンにレコードを再作成する
<a name="white-label-name-servers-create-resource-record-sets"></a>

ステップ 2 で作成したホストゾーンのレコードを作成する
+ **ドメインの DNS サービスを Amazon Route 53 に移行する場合** – 既存のレコードに関する情報をインポートしてレコードを作成することができます。詳細については、「[ゾーンファイルをインポートしてレコードを作成する](resource-record-sets-creating-import.md)」を参照してください。
+ **ホワイトラベルネームサーバーを使用できるように既存のホストゾーンを置き換える場合** – 新しいホストゾーンで、現在のホストゾーンに表示されるレコードを再作成します。Route 53 には、ホストゾーンからレコードをエクスポートする方法が用意されていませんが、一部のサードパーティベンダーにはその機能があります。その後、Route 53 のインポート機能を使用して、ルーティングポリシーがシンプルな、非エイリアスレコードをインポートすることができます。ルーティングポリシーがシンプルでないエイリアスレコードまたはレコードをエクスポートして再インポートする方法はありません。

  Route 53 API を使用したレコード作成の詳細については、*Amazon Route 53 API リファレンス*の「[CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)」を参照してください。Route 53 コンソールを使用したレコード作成の詳細については、「[レコードを使用する](rrsets-working-with.md)」を参照してください。

## ステップ 4: IP アドレスを取得します
<a name="white-label-name-servers-get-ip-addresses"></a>

再利用可能な委託セット内のネームサーバーの IPv4 および IPv6 アドレスを取得して、次の表に入力します。


****  

| 再利用可能な委託セットのネームサーバー名 (例: Ns-2048.awsdns-64.com) | IPv4 および IPv6 アドレス                                             | ホワイトラベルネームサーバーに割り当てる名前 (例: ns1.example.com) | 
| --- | --- | --- | 
|   | IPv4: IPv6:   |   | 
|   | IPv4: IPv6:   |   | 
|   | IPv4: IPv6:   |   | 
|   | IPv4: IPv6:   |   | 

例えば、再利用可能な委託セットの 4 つのネームサーバーが次のようであるとします。
+ ns-2048.awsdns-64.com
+ ns-2049.awsdns-65.net
+ ns-2050.awsdns-66.org
+ ns-2051.awsdns-67.co.uk

4 つのネームサーバーのうち最初のサーバーの IP アドレスを取得するために実行する Linux および Windows コマンドを次に示します。

**Linux での dig コマンド**

```
% dig A ns-2048.awsdns-64.com +short
192.0.2.117
```

```
% dig AAAA ns-2048.awsdns-64.com +short
2001:db8:85a3::8a2e:370:7334
```

**Windows での nslookup コマンド**

```
c:\> nslookup ns-2048.awsdns-64.com
Non-authoritative answer:
Name:    ns-2048.awsdns-64.com
Addresses:  2001:db8:85a3::8a2e:370:7334
          192.0.2.117
```

## ステップ 5: ホワイトラベルネームサーバーにレコードを作成する
<a name="white-label-name-servers-create-white-label-resource-record-sets"></a>

ホワイトラベルネームサーバーのドメイン名 (ns1.example.com など) と同じ名前 (example.com など) を持つホストゾーンで、8 つのレコードを作成します。
+ 各ホワイトラベルネームサーバーの 1 つの A レコード
+ 各ホワイトラベルネームサーバーの 1 つの AAAA レコード

**重要**  
同じホワイトラベルネームサーバーを複数のホストゾーンで使用する場合、他のホストゾーンではこのステップを実行しないでください。

レコードごとに、以下の値を指定します。以前のステップで記入した表を参照してください。

**ルーティングポリシー**  
**シンプルルーティング**を指定します。

**レコード名**  
ホワイトラベルネームサーバーの 1 つに割り当てる名前、例えば ns1.example.com です。プレフィックス (この例では ns1) としては、ドメイン名で有効な任意の値を使用できます。

**値/トラフィックのルーティング先**  
再利用可能な委託セットにある 1 つの Route 53 ネームサーバーの、IPv4 または IPv6 アドレス。  
ホワイトラベルネームサーバーのレコードを作成するときに間違った IP アドレスを指定した場合、以降のステップを実行するときに、ウェブサイトまたはウェブアプリケーションをインターネットで利用できなくなります。IP アドレスをすぐに訂正した場合でも、ウェブサイトまたはウェブアプリケーションは、TTL の期間、利用できないままです。

**レコードタイプ**  
IPv4 アドレスのレコードを作成する場合は **A** を指定します。  
IPv6 アドレスのレコードを作成する場合は **AAAA** を指定します。

**TTL (秒)**  
この値は、DNS リゾルバーが別の DNS クエリを Route 53 に転送する前に、このレコードの情報をキャッシュする時間です。このレコードに誤って正しくない値を指定した場合でも迅速に回復できるように、最初は 60 秒以下を指定することをお勧めします。

## ステップ 6: NS と SOA レコードを更新します
<a name="white-label-name-servers-update-ns-soa-records"></a>

ホワイトラベルネームサーバーに使用するホストゾーンの SOA レコードと NS レコードを更新します。ホストゾーンとそれに対応するドメインについてステップ 6 から ステップ 8 までを実行し、別のドメインとホストゾーンについても同じ作業を繰り返します。

**重要**  
作業は、ホワイトラベルネームサーバー (ns1.example.com など) と同じドメイン名 (example.com など) を持つ、Amazon Route 53 ホストゾーンから始めます。

1. Route 53 ネームサーバーの名前をホワイトラベルネームサーバーの 1 つの名前に置き換えて、SOA レコードを更新します。

   **例**

   Route 53 ネームサーバーの名前を置き換えます。

   `ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60`

   ホワイトラベルネームサーバーの 1 つの名前を使用する。

   `ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60`
**注記**  
最後の値としての有効期限 (TTL) を [ステップ 2: Amazon Route 53 ホストゾーンを作成または再作成し、NS レコードと SOA レコードの TTL を変更する](#white-label-name-servers-create-hosted-zones) で変更しました。

   Route 53 コンソールを使用しながらのレコードの更新については、「[レコードの編集](resource-record-sets-editing.md)」を参照してください。

1. NS レコードで、必要に応じて元のネームサーバーに戻せるように、ドメインの現在のネームサーバーの名前をメモします。

1. NS レコードを更新します。Route 53 ネームサーバーの名前を 4 つのホワイトラベルネームサーバーの名前、例えば `ns1.example.com`、`ns2.example.com`、`ns3.example.com`、および `ns4.example.com` に置き換えます。

## ステップ 7: グルーレコードを作成し、レジストラの名前サーバーを変更します。
<a name="white-label-name-servers-create-glue-records"></a>

レジストラが用意している方法を使って、グルーレコードを作成し、レジストラのネームサーバーを変更します。

1. グルーレコードを追加します。
   + **ホワイトラベルネームサーバーとドメイン名が同じドメインを更新する場合** – ステップ 4 で取得した値と名前および IP アドレスが一致する 4 件のグルーレコードを作成します。対応するグルーレコードにホワイトラベルネームサーバーの IPv4 および IPv6 アドレスの両方を含めてください。次に例を示します。

     **ns1.example.com** – IP アドレス = 192.0.2.117 および 2001:db8:85a3::8a2e:370:7334

     レジストラはグルーレコードを表すのにさまざまな用語を使っています。この作業は、新しいネームサーバーの登録などと言われていることもあります。
   + **別のドメインを更新する場合** – Route 53 が DNS サービスの場合、最初に前の箇条書きのステップを完了してから、ドメイン名と一致するグルーレコードを作成する必要があります。その後、この手順のステップ 2 にスキップします。

1. ドメインのネームサーバーをホワイトラベルネームサーバーの名前に変更します。

DNS サービスとして Amazon Route 53 を使用している場合は、「[ドメインのネームサーバーおよびグルーレコードの追加あるいは変更](domain-name-servers-glue-records.md)」を参照してください。

## ステップ 8: ウェブサイトまたはアプリケーションのトラフィックをモニタリングします。
<a name="white-label-name-servers-monitor-traffic"></a>

ステップ 7 でグルーレコードを作成しネームサーバーを変更したウェブサイトまたはアプリケーションのトラフィックをモニタリングします。
+ **トラフィックが停止している場合** – レジストラから提供される方法を使って、ドメインのネームサーバーを以前の Route 53 ネームサーバーに戻します。これはステップ 6b でメモしたネームサーバーです。その後、何が悪かったのかを見極めます。
+ **トラフィックに影響がない場合** – 同じホワイトラベルネームサーバーを使用する残りのホストゾーンに対して、ステップ 6 ～ 8 を繰り返します。

## ステップ 9: TTL を元の値に戻す
<a name="white-label-name-servers-change-ttls-back"></a>

ホワイトラベルネームサーバーを使用するようになったすべてのホストゾーンについて、以下の値を変更します。
+ ホストゾーンの NS レコードの TTL を、NS レコードでもっと一般的な値、例えば 172800 秒 (2 日) に変更します。
+ ホストゾーンの SOA レコードの最小 TTL を、SOA レコードでもっと一般的な値、例えば 900 秒に変更します。これは SOA レコードの最後の値です。

## ステップ 10: (オプション) 再帰的な DNS サービスへのお問い合わせ
<a name="white-label-name-servers-contact-recursive-dns-services"></a>

*オプション* Amazon Route 53 の位置情報ルーティングを使用している場合は、EDNS0 の edns-client-subnet 拡張をサポートする再帰的 DNS サービスに連絡して、ホワイトラベルネームサーバーの名前を伝えます。こうすることで、この DNS サービスは、クエリが発信されたおおよその地理的場所に基づいて、最適な場所にある Route 53 に対し DNS クエリをルーティングし続けることができます。

# Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード
<a name="SOA-NSrecords"></a>

作成したパブリックホストゾーンごとに、Amazon Route 53 はネームサーバー (NS) レコードと Start of Authority (SOA) レコードを自動的に作成します。これらのレコードを変更する必要はほとんどありません。

**Topics**
+ [ネームサーバー (NS) レコード](#NSrecords)
+ [Start of Authority (SOA) レコード](#SOArecords)

## ネームサーバー (NS) レコード
<a name="NSrecords"></a>

Amazon Route 53 によって、ホストゾーンと同じ名前のネームサーバー (NS) レコードが自動的に作成されます。これには、ホストゾーンの 4 つの正式なネームサーバーがリストされます。まれな状況を除き、このレコードのネームサーバーを追加、変更、または削除しないことをお勧めします。

次の例に、Route 53 ネームサーバーの名前の形式を示します (これらはサンプルとして提供されています。レジストラのネームサーバーレコードを更新する際には、これらを使用しないでください)。
+ *ns-2048.awsdns-64.com*
+ *ns-2049.awsdns-65.net*
+ *ns-2050.awsdns-66.org*
+ *ns-2051.awsdns-67.co.uk*

ホストゾーンのネームサーバーのリストを取得するには:

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。

1. ナビゲーションペインで [**Hosted zones (ホストゾーン)**] をクリックします。

1. [**Hosted Zones (ホストゾーン)**] ページで、ホストゾーンのラジオボタン (名前ではない) を選択し、[**View details (詳細を表示)**] を選択します。

1. ホストゾーンの詳細ページで、[**Hosted zone details (ホストゾーンの詳細)**] を選択します。

1. **[Name Servers]** (ネームサーバー) で一覧表示されている 4 つのサーバー名を書き留めます。

他の DNS サービスプロバイダから Route 53 への DNS サービスの移行方法については、「[Amazon Route 53 を既存ドメインの DNS サービスとして使用するRoute 53 を既存ドメインの DNS サービスにする](MigratingDNS.md)」を参照してください。

## Start of Authority (SOA) レコード
<a name="SOArecords"></a>

Start of Authority (SOA) レコードは、次のようなドメインについての DNS 情報ベースを特定します。

```
1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400
```

SOA レコードには以下の要素が含まれています。
+ SOA レコードを作成した Route 53 ネームサーバー (例: `ns-2048.awsdns-64.net`)。
+ 管理者の E メールアドレス。`@` 記号はピリオドに置き換えられます (例: `hostmaster.example.com`)。デフォルト値は、監視されない amazon.com E メールアドレスです。
+ ホストゾーンでレコードを更新されるときにオプションで増分されるシリアル番号。Route 53 は自動的にこの番号を増分しません。(シリアル番号はセカンダリ DNS をサポートする DNS サービスによって使用されます)。この例では、この値は `1` です。
+ 変更を確認するためにプライマリ DNS サーバーの SOA レコードを問い合わせるまでに、セカンダリ DNS サーバーが待機するリフレッシュ時間 (秒数)。この例では、この値は `7200` です。
+ 失敗したゾーン転送を再試行するまでに、セカンダリサーバーが待機する再試行間隔 (秒数)。通常は、再試行時間はリフレッシュ時間より短くなります。この例では、この値は `900` (15 分) です。
+ セカンダリサーバーがゾーン転送の完了を試み続ける時間 (秒数)。ゾーン転送に成功する前にこの時間が経過すると、セカンダリサーバーはデータが古すぎて信頼できないと見なし、クエリへの応答を停止します。この例では、この値は `1209600` (2 週間) です。
+ 最小有効期限 (TTL)。この値を使用して、Route 53 からの以下のレスポンスが、再帰的リゾルバーによりキャッシュされる時間の長さを定義できます。  
**NXDOMAIN**  
DNS クエリで指定された名前 (example.com など) を持つレコードは、どのようなタイプのものも存在しません。また、DNS クエリで指定された名前 (zenith.example.com など) を持つ子のレコードも存在しません。  
**NODATA**  
DNS クエリで指定された名前を持つレコードが少なくとも 1 つありますが、いずれも DNS クエリで指定されたタイプ (A など) のレコードではありません。

  DNS リゾルバーで NXDOMAIN または NODATA をキャッシュすることは、*ネガティブキャッシング*と呼ばれます。

  ネガティブキャッシングの期間は、次の値にうち小さいほうです。
  + この値 – SOA レコードの最小 TTL。前述の例では、この値は `86400` (1 日) です。
  + SOA レコードの TTL の値。デフォルト値は 900 秒です。この値の変更については、「[レコードの編集](resource-record-sets-editing.md)」を参照してください。

  Route 53 が NXDOMAIN または NODATA レスポンス (ネガティブレスポンス) で DNS クエリに応答する場合は、標準クエリの料金が課金されます [Amazon Route 53 の料金](https://aws.amazon.com/route53/pricing/)の「クエリ」を参照してください。ネガティブレスポンスのコストが懸念される場合は、1 つのオプションとして、SOA レコードの TTL、SOA レコードの最小 TTL (この値)、またはその両方を変更する手段もあります。これらの TTL を増やすと、ホストゾーン全体のネガティブレスポンスに適用されるため、プラスとマイナスの両方の影響が生じる場合があります。
  + インターネット上の DNS リゾルバーがレコードの不在をキャッシュする期間が長くなるため、Route 53 に転送されるクエリの数が減ります。これにより、DNS クエリに関する Route 53 料金が削減されます。
  + ただし、有効なレコードを誤って削除して後で再作成すると、DNS リゾルバーがネガティブレスポンス (このレコードは存在しない) をキャッシュする期間が長くなります。これにより、顧客やユーザーが、対応するリソース (acme.example.com の Web サーバーなど) にアクセスできない時間が長くなります。<a name="get-soa-records-in-route-53-procedure"></a>

**Route 53 で SOA レコードを検索するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。

1. ナビゲーションペインで [**Hosted zones**] を選択します。

1. レコードを表示するドメインのリンク名を選択します。

1. **[Records]** (レコード) セクションでは、すべてのレコードをリスト表示でき、その結果をフィルタリングして、SOA 値を検索することもできます。

# パブリック DNS レコードを管理するための高速リカバリの有効化
<a name="accelerated-recovery"></a>

パブリック DNS レコードを管理する Route 53 高速リカバリは、米国東部 (バージニア北部) リージョンでサービスが利用できない場合に 60 分の目標復旧時間 (RTO) を達成するように設計されています。Route 53 パブリックホストゾーンで有効にすると、 が米国東部 (バージニア北部) リージョンでのオペレーションに障害 AWS があることを検出してから約 60 分以内に、パブリックホストゾーンの DNS レコードの変更を再開できます。

**重要**  
高速復旧は、パブリックホストゾーンでのみ使用できます。プライベートホストゾーンはサポートされていません。

**注記**  
Route 53 データプレーンからの DNS クエリ解決は、リージョンのサービスに障害が発生しても正常に動作し続けます。データプレーンとコントロールプレーンオペレーションの理解については、[「Route 53 の耐障害性](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html)」を参照してください。

**Topics**
+ [パブリック DNS レコードの高速復旧の仕組み](#accelerated-recovery-how-it-works)
+ [フェイルオーバー後の DNS 変更の再送信](#accelerated-recovery-resubmit)
+ [米国東部 (バージニア北部) リージョンへのフェイルバック](#accelerated-recovery-failback)
+ [その他の考慮事項](#accelerated-recovery-considerations)
+ [パブリック DNS レコードを管理するための高速復旧を有効にする方法](#accelerated-recovery-enable)

## パブリック DNS レコードの高速復旧の仕組み
<a name="accelerated-recovery-how-it-works"></a>

高速復旧が有効になっている場合、Route 53 はパブリックホストゾーンのコピーを米国西部 (オレゴン) リージョンに保持します。米国東部 (バージニア北部) リージョンのサービスが長期間使用できなくなった場合、Route 53 は 60 分以内にフェイルオーバーを実行し、高速復旧が有効なパブリックホストゾーンのコントロールプレーンオペレーションを米国西部 (オレゴン) リージョンに自動的にリダイレクトします。その後、CLI、SDK、API を使用してプログラムで DNS の変更を続行できます。フェイルオーバー中は、限られた API メソッドのセットが使用できることに注意してください。詳細については、「その他の考慮事項」セクションを参照してください。リージョンが回復すると、Route 53 はフェイルバック手順を実行し、コントロールプレーンオペレーションを自動的に米国東部 (バージニア北部) リージョンに戻します。

**注記**  
米国東部 (バージニア北部) リージョンに障害が発生する前に、まず、パブリックホストゾーンでパブリック DNS レコードを管理するための高速復旧を有効にする必要があります。これは、コンソール、CLI、SDK、または API を介して行うことができます (このページの*「パブリック DNS レコードを管理するための高速復旧を有効にする方法*」セクションを参照してください）。フェイルオーバーの発生後にパブリック DNS レコードを管理するための高速復旧を有効にすることはできません。

## フェイルオーバー後の DNS 変更の再送信
<a name="accelerated-recovery-resubmit"></a>

通常の条件下では、高速復旧が有効になっているパブリックホストゾーンへの変更は、米国東部 (バージニア北部) リージョンで受け入れられ、米国西部 (オレゴン) リージョンに正常にレプリケートされます。ただし、米国東部 (バージニア北部) リージョンでサービスの中断が発生した場合、一部の変更は米国東部 (バージニア北部) リージョンで受け入れられますが、米国西部 (オレゴン) リージョンにレプリケートできない場合があります。これらの進行中の変更は、「ストランド変更」と呼ばれます。フェイルオーバーが完了すると、Route 53 では、DNS ワークフローを再開する前に、ストランドされた変更を再送信することをお勧めします。これを実現するには、 API を使用するか、以下で説明する AWS CloudFormation を使用します。

### API を使用して DNS の変更を追跡および送信する
<a name="accelerated-recovery-api"></a>

Route 53 API、 AWS CLI、または AWS SDKs を使用して DNS レコードを管理する場合は、それぞれ [ChangeResourceRecordSets API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) と [GetChange API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) を使用して DNS の変更を送信および追跡する必要があります。

ChangeResourceRecordSets API を使用して DNS を変更すると、Route 53 は行った変更の識別子 (ID) を返します (変更レスポンスオブジェクトの詳細については、[ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html)」を参照）。この ID は、GetChange API への後続のリクエストで指定し、変更のステータスを確認できます。INSYNC ステータスの DNS 変更は、米国西部 (オレゴン) リージョンにレプリケートされ、すべての Route 53 DNS サーバーに伝播されています。フェイルオーバーの前後に、これらの変更に対して追加のアクションを実行する必要はありません。ただし、米国東部 (バージニア北部) リージョンに障害が発生すると、GetChange が PENDING を返すことがあります。これは、変更が米国西部 (オレゴン) リージョンにレプリケートされていないことを示している可能性があります。この場合、フェイルオーバーが完了すると、GetChange は NoSuchChange を返し、Route 53 がこの DNS 変更をレプリケートできなかったことを示します。したがって、フェイルオーバー後にこれらのストランドされた DNS の変更を安全に無視し、新しい DNS の変更として再送信できます。Route 53 が AWS Health Dashboard にメッセージを投稿すると、フェイルオーバープロセスが完了したことがわかります。

### AWS CloudFormation を使用した変更の追跡と送信
<a name="accelerated-recovery-cloudformation"></a>

AWS CloudFormation は、GetChange API を使用して DNS 変更のレプリケーションステータスを自動的に追跡し、DNS 変更が INSYNC と確認された後にのみ更新を完了します。CloudFormation を使用して DNS レコードを管理し、米国東部 (バージニア北部) リージョンが使用できなくなった場合、CloudFormation を使用して実行するアクションは、使用不可の期間中に正常に完了しません。ただし、Route 53 フェイルオーバープロセスが完了すると、CloudFormation が DNS の変更を再送信できるように、同じアクションを再試行するだけで済みます。

## 米国東部 (バージニア北部) リージョンへのフェイルバック
<a name="accelerated-recovery-failback"></a>

Route 53 は、リージョンが回復すると、パブリックホストゾーンのコントロールプレーンオペレーションを米国東部 (バージニア北部) リージョンにフェイルバックします。このプロセス中にストランド変更が導入されないため、フェイルバック中に DNS 変更を再送信する必要はありません。

## その他の考慮事項
<a name="accelerated-recovery-considerations"></a>

高速復旧機能に関連して注意すべき追加の考慮事項がいくつかあります。

1. フェイルオーバー中に、新しいホストゾーンの作成、既存のホストゾーンの削除、DNSSEC 署名の有効化、DNSSEC 署名の無効化を行うことはできません。

1. AWS PrivateLink 接続はフェイルオーバー後は機能しませんが、米国東部 (バージニア北部) リージョンへのフェイルバック後に再び機能します。

1. [CloudFront の定額プラン](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html)は現在サポートされていません。

1. 高速復旧が有効になっているホストゾーンは削除できません。ホストゾーンを削除する前に、高速復旧を無効にする必要があります。

1. フェイルオーバー中、高速復旧が有効になっているパブリックホストゾーンでは、次の API メソッドが引き続きサポートされます。ただし、フェイルバックが発生するまで、他のすべての Route 53 API メソッドは機能しません。
   + `ChangeResourceRecordSets`
   + `GetChange`
   + `GetGeoLocation`
   + `GetHostedZone`
   + `GetHostedZoneCount`
   + `GetHostedZoneLimit`
   + `GetReusableDelegationSet`
   + `GetReusableDelegationSetLimit`
   + `ListGeoLocations`
   + `ListHostedZones`
   + `ListHostedZonesByName`
   + `ListResourceRecordSets`
   + `ListReusableDelegationSets`

## パブリック DNS レコードを管理するための高速復旧を有効にする方法
<a name="accelerated-recovery-enable"></a>

Route 53 コンソール、API、CLI、または SDK を使用して、パブリック DNS レコードを管理するための高速リカバリを有効にできます。高速復旧を有効にするのにかかる時間は、パブリックホストゾーンのサイズやその他の要因によって異なります。高速復旧を有効にするプロセスには、最大数時間かかることを計画する必要があります。有効化プロセスのステータスは、パブリックホストゾーンの高速復旧タブまたは `GetHostedZone` API で確認できます。プロセスが終了すると、DNS の変更が受け入れられない期間が数分まで短くなります。完了すると、DNS の変更は通常どおり続行できます。

**Route 53 コンソールを使用して高速復旧を有効または無効にするには**

1. Route 53 コンソール ([https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)) を開きます。

1. ナビゲーションペインで [**Hosted zones**] を選択します。

1. 高速復旧を有効にするパブリックホストゾーンを選択します。

1. **高速復旧**タブで、**有効化**を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

1. ホストゾーンのステータスをモニタリングします。ステータスは、セットアップ時の**高速復旧の有効化**と、完了時の**有効化**への変更を示しています。

上記の同じステップを使用して高速復旧を無効にすることができますが、代わりに **Disable** を選択します。

を有効にする CLI の例

```
aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789
```

を無効にする CLI の例

```
aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789
```