翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# DNS サービスとしての Amazon Route 53 の設定
Amazon Route 53 は、example.com などのドメインに対して DNS サービスとして使用できます。DNS サービスとしての Route 53 は、可読性の良いドメイン名 (www.example.com など) を、コンピュータが相互接続に使用する IP アドレス (192.0.2.1 など) に変換します。これにより、インターネットトラフィックをウェブサイトにルーティングします。誰かがブラウザにドメイン名を入力するか、E メールを送信すると、DNS クエリが Route 53 に転送され適切な値が返されます。例えば、Route 53 は example.com に対し、ウェブサーバーの IP アドレスで応答します。
**DNS ホスティングとドメイン登録**
この章では、*DNS ホスティングにのみ* Route 53 を使用する方法について説明します。つまり、ドメイン登録は現在のレジストラに残り、ドメインの更新に対して引き続き支払います。Route 53 は DNS 設定のみを管理し、ドメインの DNS クエリを処理します。
ドメイン登録を Route 53 にも移管する場合は (Route 53 をレジストラと DNS サービスの両方にする）、「[ドメイン移管の移管前チェックリスト](domain-transfer-checklist.md)」および「[ドメイン登録の Amazon Route 53 への移管](domain-transfer-to-route-53.md)」を参照してください。
この章では、インターネットトラフィックが適切な場所にルーティングされるように Route 53 を設定する方法について説明します。また、現在別の DNS サービスをお使いの場合の Route 53 への DNS サービスの移行方法や、Route 53 を新しいドメインの DNS サービスとして使用する方法についても説明します。
**Topics**
+ [Amazon Route 53 を既存ドメインの DNS サービスとして使用する](MigratingDNS.md)
+ [新しいドメインの DNS ルーティングの設定](dns-configuring-new-domain.md)
+ [リソースへのトラフィックのルーティング](dns-routing-traffic-to-resources.md)
+ [ホストゾーンの使用](hosted-zones-working-with.md)
+ [レコードを使用する](rrsets-working-with.md)
+ [Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)
+ [AWS Cloud Map によるレコードとヘルスチェックの作成](autonaming.md)
+ [DNS の制約と動作](DNSBehavior.md)
+ [関連トピック](dns-configuring-related-topics.md)
# Amazon Route 53 を既存ドメインの DNS サービスとして使用する
1 つまたは複数のドメイン登録を Route 53 に移管していて、現在有料の DNS サービスを提供していないドメインレジストラを使用している場合は、ドメインを移行する前に DNS サービスを移行する必要があります。そうしないと、レジストラはドメインの移行時に DNS サービスの提供を停止し、関連するウェブサイトやウェブアプリケーションはインターネット上で使用できなくなります。(現在のレジストラから別の DNS サービスプロバイダーに DNS サービスを移管することもできます。 Route 53 に登録されているドメインの DNS サービスプロバイダとして、Route 53 の使用は必須ではありません。)
プロセスは、現在ドメインを使用しているかどうかによって異なります。
+ ドメインが現在トラフィックを受信している場合 (ユーザーがドメイン名を使用してウェブサイトを閲覧したり、ウェブアプリケーションにアクセスしている場合など) は、「[Route 53 を使用中のドメインの DNS サービスにする](migrate-dns-domain-in-use.md)」を参照してください。
+ ドメインにトラフィックがない場合 (またはトラフィックをほとんど受け取っていない場合) は、「[Route 53 を非アクティブドメインの DNS サービスにする](migrate-dns-domain-inactive.md)」を参照してください。
どちらのオプションでも、移行プロセス全体でドメインを利用可能にしておく必要があります。ただし、万一問題が発生した場合でも、最初のオプションでは移行をすばやくロールバックできます。2 番目のオプションの場合、ドメインを数日間利用できなくなる可能性があります。
の専門家に接続する場合は AWS、[「 販売サポート](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs)」を参照してください。
# Route 53 を使用中のドメインの DNS サービスにする
現在トラフィックが発生している (ユーザーがドメイン名を使用してウェブサイトを閲覧したり、ウェブアプリケーションにアクセスしている場合などで) ドメインの DNS サービスを Amazon Route 53 に移行する場合は、このセクションの手順を実行します。
**Topics**
+ [ステップ 1: 現在の DNS サービスプロバイダから現在の DNS 設定を取得する (オプション、ただし推奨)](#migrate-dns-get-zone-file)
+ [ステップ 2: ホストゾーンを作成する](#migrate-dns-create-hosted-zone)
+ [ステップ 3: レコードを作成する](#migrate-dns-create-records)
+ [ステップ 4: TTL の設定を下げる](#migrate-dns-lower-ttl)
+ [ステップ 5: (DNSSEC を構成している場合) 親ゾーンから DS レコードを削除する](#migrate-remove-ds)
+ [ステップ 6: 古い TTL の有効期限切れを待つ](#migrate-dns-wait-for-ttl)
+ [ステップ 7: NS レコードを更新して、Route 53 ネームサーバーを使用する](#migrate-dns-change-name-servers-with-provider)
+ [ステップ 8: ドメインのトラフィックの監視](#migrate-dns-monitor-traffic)
+ [ステップ 9: NS レコードの TTL を高い値に戻す](#migrate-dns-change-ttl-back)
+ [ステップ 10: ドメイン登録を Amazon Route 53 に移管する](#migrate-dns-transfer-domain-registration)
+ [ステップ 11: DNSSEC 署名を再度有効にする (必要な場合)](#migrate-dns-re-enable-dnssec)
## ステップ 1: 現在の DNS サービスプロバイダから現在の DNS 設定を取得する (オプション、ただし推奨)
DNS サービスを他のプロバイダから Route 53 に移行した後に、現在の DNS 設定を Route 53 で再現できます。まず、ドメインと同じ名前のホストゾーンを Route 53 に作成し、そのホストゾーンにレコードを作成します。各レコードは、指定されたドメイン名またはサブドメイン名のトラフィックをどのようにルーティングするかを示します。例えば、誰かがウェブブラウザにドメイン名を入力した際、そのトラフィックをデータセンターのウェブサーバーにルーティングするのか、それとも Amazon EC2 インスタンスや CloudFront ディストリビューションなどにルーティングするのかを指定します。
使用するプロセスは、現在の DNS 設定の複雑さによって異なります。
+ **現在の DNS 設定が単純な場合** – 少数のサブドメインへのインターネットトラフィックを、ウェブサーバーや Amazon S3 バケットなどの少数のリソースにルーティングする場合は、Route 53 コンソールから手動でレコードをいくつか作成します。
+ **現在の DNS 設定がより複雑で現在の設定を複製したいだけの場合** – 現在の DNS サービスプロバイダからゾーンファイルを入手して、そのゾーンファイルを Route 53 にインポートすることで、移行作業が簡単になります。(すべての DNS サービスプロバイダがゾーンファイルを提供しているわけではありません。) ゾーンファイルをインポートすると、Route 53 はホストゾーン内に対応するレコードを作成して、既存の設定を自動的に再現します。
*ゾーンファイル*または*レコードリスト*を取得する方法を、現在の DNS サービスプロバイダのカスタマーサポートに問い合わせてみてください。必要なゾーンファイルのフォーマットの詳細については、「[ゾーンファイルをインポートしてレコードを作成する](resource-record-sets-creating-import.md)」を参照してください。
+ **現在の DNS 設定がより複雑で Route 53 のルーティング機能に関心がある場合** – 次のドキュメントを参照して、他の DNS サービスプロバイダでは提供されていない Route 53 の機能の中で、使用できるものがあるかを確認してください。使用する場合は、手動でレコードを作成するか、ゾーンファイルをインポートして、後でレコードを作成または更新することができます。
+ [エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md) では、CloudFront ディストリビューションや Amazon S3 バケットなどの一部の AWS リソースに無料でトラフィックをルーティングする Route 53 エイリアスレコードの利点について説明します。 Amazon S3
+ 「[ルーティングポリシーの選択](routing-policy.md)」では、Route 53 のルーティングオプションについて解説しています。これらには、ユーザーの場所に基づいたルーティング、ユーザーとリソース間のレイテンシーに基づいたルーティング、リソースの正常性に基づいたルーティング、および指定した重みに基づくリソースへのルーティングなどがあります。
**注記**
また、ゾーンファイルをインポートした後で設定を変更して、エイリアスレコードと複雑なルーティングポリシーを利用することもできます。
ゾーンファイルを取得できない場合や、Route 53 のレコードを手動で作成する場合に、移行の必要性が考えられるレコードは次のとおりです。
+ **A (アドレス) レコード** – このレコードは、ドメイン名またはサブドメイン名を、対応するリソースの IPv4 アドレス (192.0.2.3 など) に関連付けます
+ **AAAA (アドレス) レコード** – このレコードは、ドメイン名またはサブドメイン名を、対応するリソースの IPv6 アドレス (2001:0db8:85a3:0000:0000:abcd:0001:2345 など) に関連付けます
+ **メールサーバー (MX) レコード** – このレコードは、トラフィックをメールサーバーにルーティングします
+ **CNAME レコード** – このレコードは、あるドメイン名 (example.net) のトラフィックを別のドメイン名 (example.com) に再ルーティングします
+ **サポートされているその他の DNS レコードタイプに対応するレコード** – サポートされているレコードタイプの一覧については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
## ステップ 2: ホストゾーンを作成する
ドメインのトラフィックをどのようにルーティングするかを Amazon Route 53 に指示するには、ドメインと同じ名前のホストゾーンを作成し、そのホストゾーンにレコードを作成します。
**重要**
ホストゾーンは、管理権限を持つドメインに対してのみ作成できます。通常、これはドメインを所有していることを指しますが、ドメインの登録者向けにアプリケーションを開発している場合にも当てはまります。
ホストゾーンを作成すると、Route 53 はそのゾーンに対して、1 つのネームサーバー (NS) レコードと、1 つの Start of Authority (SOA) レコードを自動的に作成します。NS レコードは、Route 53 がホストゾーンに関連付けた 4 つのネームサーバーを識別します。Route 53 をドメインの DNS サービスとして使用するには、これら 4 つのネームサーバーを使用するようにドメインの登録を更新します。
**重要**
ホストゾーンに追加のネームサーバー (NS) レコードまたは Start of Authority (SOA) レコードを作成しないでください。また、既存の NS レコードと SOA レコードを削除しないでください。
**ホストゾーンを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. Route 53 を初めて使用する場合は、[**DNS management (DNS 管理)**] の [**Get started (今すぐ始め) **] を選択した後、[**Create Hosted Zone (ホストゾーンの作成)**] を選択します。
既に Route 53 を利用している場合は、ナビゲーションペインで [**Hosted zones (ホストゾーン)**] を選択した上で、[**Create Hosted Zone (ホストゾーンの作成)**] を選択します。
1. **[Create hosted zone]** (ホストゾーンの作成) ペインで、ドメイン名とコメント (必要に応じて) を入力します。設定の詳細については、右側のヘルプパネルを開き参照してください。
a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。
1. **[Type]** (タイプ) では、デフォルト値の **[Public hosted zone]** (パブリックホストゾーン) をそのまま使用します。
1. [**ホストゾーンの作成**] を選択します。
## ステップ 3: レコードを作成する
ホストゾーンを作成した後、ドメイン (example.com) またはサブドメイン (www.example.com) のトラフィックをルーティングする場所を定義するレコードをホストゾーンに作成します。例えば、example.com と www.example.com のトラフィックを、Amazon EC2 インスタンス上にあるウェブサーバーにルーティングする場合は、example.com という名前のレコードと www.example.com という名前のレコードを 2 つ作成します。各レコードでは、EC2 インスタンスの IP アドレスを指定します。
レコードはさまざまな方法で作成できます。
**ゾーンファイルをインポートする**
「[ステップ 1: 現在の DNS サービスプロバイダから現在の DNS 設定を取得する (オプション、ただし推奨)](#migrate-dns-get-zone-file)」で現在の DNS サービスからゾーンファイルを取得している場合には、これが最も簡単な方法となります。Amazon Route 53 では、エイリアスレコードを作成するタイミングや、加重やフェイルオーバーなどの特殊なルーティングタイプを使用するタイミングを予測できません。この理由から、インポートするゾーンファイルがある場合、Route 53 では、シンプルなルーティングポリシーを使用しながら標準的な DNS レコードが作成されます。
詳細については、「[ゾーンファイルをインポートしてレコードを作成する](resource-record-sets-creating-import.md)」を参照してください。
**コンソールで個別にレコードを作成する**
ゾーンファイルを取得しておらず、シンプルなルーティングポリシーを持つレコードをいくつか作成して使用を開始する場合には、Route 53 コンソールでレコードを作成します。エイリアスレコードと非エイリアスレコードの両方を作成できます。
詳細については、以下のトピックを参照してください。
+ [ルーティングポリシーの選択](routing-policy.md)
+ [エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)
+ [Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)
**プログラムでレコードを作成する**
レコードは、 AWS SDKs、、 AWS CLIまたは のいずれかを使用して作成できます AWS Tools for Windows PowerShell。詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/) を参照してください。
SDK を提供し AWS ないプログラミング言語を使用している場合は、Route 53 API を使用することもできます。詳細については、「[Amazon Route 53 API リファレンス](https://docs.aws.amazon.com/Route53/latest/APIReference/)」を参照してください。
## ステップ 4: TTL の設定を下げる
レコードの TTL (有効期限) 設定は、DNS リゾルバーがレコードをキャッシュし、キャッシュされた情報を使用する期間を指定します。TTL が期限切れになると、リゾルバーはドメインの DNS サービスプロバイダに別のクエリを送信し、最新の情報を取得します。
NS レコードの一般的な TTL 設定は 172800 秒、つまり 2 日です。NS レコードには、ドメインネームシステム (DNS) がドメインのトラフィックをルーティングする方法に関する情報を得るために使用できるネームサーバーがリストされています。現在の DNS サービスプロバイダと Amazon Route 53 の両方で NS レコードの TTL を下げることで、DNS を Route 53 に移行している際に問題が検出された場合のドメインのダウンタイムを短縮できます。TTL を下げないと、何か問題が発生した場合、ドメインはインターネット上で最大 2 日間使用できなくなる可能性があります。
**注記**
フルリゾルバーによっては、親権限サーバーの NS レコードの TTL をキャッシュする場合があるため、親権限 DNS サーバーに登録されている NS レコードの TTL も短縮する必要があります。
次の NS レコードの TTL を変更することをお勧めします。
+ 現在の DNS サービスプロバイダのホストゾーンにある NS レコード。(現在のプロバイダでは異なる用語を使用している場合もあります。)
+ 「[ステップ 2: ホストゾーンを作成する](#migrate-dns-create-hosted-zone)」で作成したホストゾーンの NS レコード。
**現在の DNS サービスプロバイダで NS レコードの TTL 設定を下げるには**
+ ドメインの現在の DNS サービスプロバイダが提供するメソッドを使用して、ドメインのホストゾーンでの NS レコードの TTL を変更します。
**Route 53 ホストゾーンの NS レコードの TTL 設定を下げるには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted Zones**] を選択します。
1. ホストゾーンの名前を選択します。
1. NS レコードを選択してから、**[Edit]** (編集) を選択します。
1. [**TTL (Seconds)**] の値を変更します。60 秒から 900 秒 (15 分) の間の値を指定することをお勧めします。
1. **[Save changes]** (変更の保存) をクリックします。
## ステップ 5: (DNSSEC を構成している場合) 親ゾーンから DS レコードを削除する
ドメインで DNSSEC を設定している場合は、ドメインを Route 53 に移行する前に、親ゾーンから Delegation Signer (DS) レコードを削除します。
Route 53 または別のレジストラが親ゾーンをホストしている場合は、それらのホストに対し DS レコードの削除を依頼します。
現在、2 つのプロバイダー間で DNSSEC 署名を有効にすることはできないため、DNSSEC を無効にするには、すべての DS または DNSSEC を削除する必要があります。これにより、DNS リゾルバーに一時的にシグナルが送られて DNSSEC 検証が無効になります。[ステップ 11](#migrate-dns-re-enable-dnssec) でRoute 53 への移行が完了した後、必要に応じて DNSSEC 検証を再度有効にすることができます。
詳細については、「[ドメインのパブリックキーの削除](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys)」を参照してください。
## ステップ 6: 古い TTL の有効期限切れを待つ
ドメインが使用されている場合 (ユーザーがドメイン名を使用してウェブサイトを閲覧したり、ウェブアプリケーションにアクセスしている場合など)、DNS リゾルバーは現在の DNS サービスプロバイダが提供したネームサーバーの名前をキャッシュしています。数分前にその情報をキャッシュした DNS リゾルバーでは、この後ほぼ 2 日ほど保存されます。
DNS サービスが Route 53 に移行されたことを一度ですべて確認するには、TTL を短くした後、2 日間待ってください。2 日間が経過すると TTL の有効期限が切れ、リゾルバーがドメインのネームサーバーを要求します。リゾルバーは現在のネームサーバーを取得し、「[ステップ 4: TTL の設定を下げる](#migrate-dns-lower-ttl)」で指定した新しい TTL も取得します。
## ステップ 7: NS レコードを更新して、Route 53 ネームサーバーを使用する
ドメインの DNS サービスとして Amazon Route 53 の使用を開始するには、レジストラまたは親ゾーンが提供する方法を使用して、NS レコード内の現在のネームサーバーを Route 53 ネームサーバーに置き換えます。
**注記**
Route 53 ネームサーバーを使用するように、現在の DNS サービスプロバイダーで NS レコードを更新するときは、ドメインの DNS 設定を更新します。(これは、ドメインの Route 53 ホストゾーンの NS レコードを更新するのと同じですが、移行元の DNS サービスで設定を更新する点が異なります)。
**レジストラまたは親ゾーンで NS レコードを更新して Route 53 ネームサーバーを使用するには**
1. Route 53 コンソールで、 ホストゾーンのネームサーバーを取得します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. **[Hosted Zones]** (ホストゾーン) ページで、該当するホストゾーンの名前を選択します。
1. **[Hosted zone details]** (ホストゾーンの詳細) セクションの **[Name servers]** (ネームサーバー) で一覧表示されている、 4 つの名前を書き留めます。
1. ドメインの現在の DNS サービスが提供するメソッドを使用して、ホストゾーンの NS レコードを更新します。ドメインが Route 53 に登録されている場合は、「[ドメインのネームサーバーおよびグルーレコードの追加あるいは変更](domain-name-servers-glue-records.md)」を参照してください。このプロセスは、現在の DNS サービスでネームサーバーの削除が可能かどうかによって異なります。
**ネームサーバーを削除できる場合**
+ ホストゾーンの NS レコードで、現在のネームサーバーの名前をメモします。現在の DNS 設定を復元する必要がある場合は、これらが指定するサーバーになります。
+ NS レコードから現在のネームサーバーを削除します。
+ NS レコードを、この手順のステップ 1 で取得した 4 つすべての Route 53 ネームサーバーの名前に置き換えます。
**注記**
完了すると、NS レコード内のネームサーバーは 4 つの Route 53 ネームサーバーのみになります。
**ネームサーバーを削除できない場合**
+ カスタムネームサーバーを使用するオプションを選択します。
+ この手順のステップ 1 で取得した、4 つの Route 53 ネームサーバーをすべて追加します。
## ステップ 8: ドメインのトラフィックの監視
ウェブサイトやアプリケーションのトラフィック、電子メールなど、ドメインのトラフィックを監視する。
+ **トラフィックが減速または停止した場合** – 以前の DNS サービスが提供するメソッドを使用して、ドメインのネームサーバーを以前のネームサーバーに戻します。これらは「[レジストラまたは親ゾーンで NS レコードを更新して Route 53 ネームサーバーを使用するには](#migrate-dns-change-name-servers-with-provider-procedure)」のステップ 7 でメモしたネームサーバーです。その後、何が悪かったのかを見極めます。
+ **トラフィックに影響がない場合** –「[ステップ 9: NS レコードの TTL を高い値に戻す](#migrate-dns-change-ttl-back)」に進みます。
## ステップ 9: NS レコードの TTL を高い値に戻す
ドメインの Amazon Route 53 ホストゾーンで、NS レコードの TTL をより一般的な値、例えば 172800 秒 (2 日) に変更します。これにより、DNS リゾルバーがドメインのネームサーバーのクエリを送信するのを頻繁に待つ必要がないため、ユーザーのレイテンシーが改善されます。
**Route 53 ホストゾーン内で NS レコードの TTL を変更するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted Zones**] を選択します。
1. ホストゾーンの名前を選択します。
1. ホストゾーンのレコードのリストで、NS レコードを選択します。
1. **[編集]** を選択します。
1. [**TTL (Seconds)**] を、DNS リゾルバーがドメインのネームサーバーの名前をキャッシュする秒数に変更します。172800 秒の値を推奨します。
1. **[Save changes]** (変更の保存) をクリックします。
## ステップ 10: ドメイン登録を Amazon Route 53 に移管する
ドメインの DNS サービスの Amazon Route 53 への移行が完了したので、必要な場合には、ドメインの登録を Route 53 に移管します。詳細については、「[ドメイン登録の Amazon Route 53 への移管](domain-transfer-to-route-53.md)」を参照してください。
## ステップ 11: DNSSEC 署名を再度有効にする (必要な場合)
これでドメインの DNS サービスを Amazon Route 53 に移管したので、DNSSEC 署名を再度有効にすることができます。
DNSSEC 署名を有効にするには、次の 2 つの手順を実行します。
+ ステップ 1: Route 53 の DNSSEC 署名を有効にし、 AWS Key Management Service () のカスタマーマネージドキーに基づいてキー署名キー (KSK) を作成するよう Route 53 にリクエストしますAWS KMS。
+ 手順 2: Delegation Signer (DS) レコードを親ゾーンに追加して、ホストゾーンの信頼チェーンを作成します。これにより、信頼された暗号化署名を使用して DNS 応答を認証できます。
手順については、「[DNSSEC 署名を有効にし、信頼チェーンを確立します。](dns-configuring-dnssec-enable-signing.md)」を参照してください。
# Route 53 を非アクティブドメインの DNS サービスにする
トラフィックがない (またはトラフィックをほとんど受信していない) ドメイン用に、DNS サービスを Amazon Route 53 に移行する場合は、このセクションの手順を実行します。
**Topics**
+ [ステップ 1: 現在の DNS サービスプロバイダから現在の DNS 設定を取得する (非アクティブドメイン)](#migrate-dns-get-zone-file-domain-inactive)
+ [ステップ 2: ホストゾーンを作成する (非アクティブドメイン)](#migrate-dns-create-hosted-zone-domain-inactive)
+ [ステップ 3: レコードの作成 (非アクティブドメイン)](#migrate-dns-create-records-domain-inactive)
+ [ステップ 4: Amazon Route 53 ネームサーバーを使用するようにドメイン登録を更新する (非アクティブドメイン)](#migrate-dns-update-domain-inactive)
## ステップ 1: 現在の DNS サービスプロバイダから現在の DNS 設定を取得する (非アクティブドメイン)
DNS サービスを他のプロバイダから Route 53 に移行する場合は、現在の DNS 設定を Route 53 に再現します。まず、ドメインと同じ名前のホストゾーンを Route 53 に作成し、そのホストゾーンにレコードを作成します。各レコードは、指定されたドメイン名またはサブドメイン名のトラフィックをどのようにルーティングするかを示します。例えば、誰かがウェブブラウザにドメイン名を入力した際、そのトラフィックをデータセンターのウェブサーバーにルーティングするのか、それとも Amazon EC2 インスタンスや CloudFront ディストリビューションなどにルーティングするのかを指定します。
使用するプロセスは、現在の DNS 設定の複雑さによって異なります。
+ **現在の DNS 設定が単純な場合** – 少数のサブドメインへのインターネットトラフィックを、ウェブサーバーや Amazon S3 バケットなどの少数のリソースにルーティングする場合は、Route 53 コンソールから手動でレコードをいくつか作成します。
+ **現在の DNS 設定がより複雑で現在の設定を複製したいだけの場合** – 現在の DNS サービスプロバイダからゾーンファイルを入手して、そのゾーンファイルを Route 53 にインポートすることで、移行作業が簡単になります。(すべての DNS サービスプロバイダがゾーンファイルを提供しているわけではありません。) ゾーンファイルをインポートすると、Route 53 はホストゾーン内に対応するレコードを作成して、既存の設定を自動的に再現します。
*ゾーンファイル*または*レコードリスト*を取得する方法を、現在の DNS サービスプロバイダのカスタマーサポートに問い合わせてみてください。必要なゾーンファイルのフォーマットの詳細については、「[ゾーンファイルをインポートしてレコードを作成する](resource-record-sets-creating-import.md)」を参照してください。
+ **現在の DNS 設定がより複雑で Route 53 のルーティング機能に関心がある場合** – 次のドキュメントを参照して、他の DNS サービスプロバイダでは提供されていない Route 53 の機能の中で、使用できるものがあるかを確認してください。使用する場合は、手動でレコードを作成するか、ゾーンファイルをインポートして、後でレコードを作成または更新することができます。
+ [エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md) では、CloudFront ディストリビューションや Amazon S3 バケットなどの一部の AWS リソースに無料でトラフィックをルーティングする Route 53 エイリアスレコードの利点について説明します。 Amazon S3
+ 「[ルーティングポリシーの選択](routing-policy.md)」では、Route 53 のルーティングオプションについて解説しています。これらには、ユーザーの場所に基づいたルーティング、ユーザーとリソース間のレイテンシーに基づいたルーティング、リソースの正常性に基づいたルーティング、および指定した重みに基づくリソースへのルーティングなどがあります。
**注記**
また、ゾーンファイルをインポートした後で設定を変更して、エイリアスレコードと複雑なルーティングポリシーを利用することもできます。
ゾーンファイルを取得できない場合や、Route 53 のレコードを手動で作成する場合に、移行の必要性が考えられるレコードは次のとおりです。
+ **A (アドレス) レコード** – このレコードは、ドメイン名またはサブドメイン名を、対応するリソースの IPv4 アドレス (192.0.2.3 など) に関連付けます
+ **AAAA (アドレス) レコード** – このレコードは、ドメイン名またはサブドメイン名を、対応するリソースの IPv6 アドレス (2001:0db8:85a3:0000:0000:abcd:0001:2345 など) に関連付けます
+ **メールサーバー (MX) レコード** – このレコードは、トラフィックをメールサーバーにルーティングします
+ **CNAME レコード** – このレコードは、あるドメイン名 (example.net) のトラフィックを別のドメイン名 (example.com) に再ルーティングします
+ **サポートされているその他の DNS レコードタイプに対応するレコード** – サポートされているレコードタイプの一覧については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
## ステップ 2: ホストゾーンを作成する (非アクティブドメイン)
ドメインのトラフィックをどのようにルーティングするかを Amazon Route 53 に指示するには、ドメインと同じ名前のホストゾーンを作成し、そのホストゾーンにレコードを作成します。
**重要**
ホストゾーンは、管理権限を持つドメインに対してのみ作成できます。通常、これはドメインを所有していることを指しますが、ドメインの登録者向けにアプリケーションを開発している場合にも当てはまります。
ホストゾーンを作成すると、Route 53 はそのゾーンに対して、1 つのネームサーバー (NS) レコードと、1 つの Start of Authority (SOA) レコードを自動的に作成します。NS レコードは、Route 53 がホストゾーンに関連付けた 4 つのネームサーバーを識別します。Route 53 をドメインの DNS サービスとして使用するには、これら 4 つのネームサーバーを使用するようにドメインの登録を更新します。
**重要**
ホストゾーンに追加のネームサーバー (NS) レコードまたは Start of Authority (SOA) レコードを作成しないでください。また、既存の NS レコードと SOA レコードを削除しないでください。
**ホストゾーンを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. Route 53 を初めて使用する場合、[**今すぐ始める**] を選択します。
既に Route 53 を利用している場合は、ナビゲーションペインの [**Hosted zones (ホストゾーン)**] を選択します。
1. [**ホストゾーンの作成**] を選択します。
1. **[Create hosted zone]** (ホストゾーンの作成) ペインで、ドメイン名とコメント (必要に応じて) を入力します。設定の詳細については、ラベルの上にマウスポインタを置いて、ツールヒントを表示してください。
a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。
1. **[Record type]** (レコードタイプ) では、デフォルト値の **[Public hosted zone]** (パブリックホストゾーン) をそのまま使用します。
1. [**ホストゾーンの作成**] を選択します。
## ステップ 3: レコードの作成 (非アクティブドメイン)
ホストゾーンを作成した後、ドメイン (example.com) またはサブドメイン (www.example.com) のトラフィックをルーティングする場所を定義するレコードをホストゾーンに作成します。例えば、example.com と www.example.com のトラフィックを、Amazon EC2 インスタンス上にあるウェブサーバーにルーティングする場合は、example.com という名前のレコードと www.example.com という名前のレコードを 2 つ作成します。各レコードでは、EC2 インスタンスの IP アドレスを指定します。
レコードはさまざまな方法で作成できます。
**ゾーンファイルをインポートする**
「[ステップ 1: 現在の DNS サービスプロバイダから現在の DNS 設定を取得する (非アクティブドメイン)](#migrate-dns-get-zone-file-domain-inactive)」で現在の DNS サービスからゾーンファイルを取得している場合には、これが最も簡単な方法となります。Amazon Route 53 では、エイリアスレコードを作成するタイミングや、加重やフェイルオーバーなどの特殊なルーティングタイプを使用するタイミングを予測できません。この理由から、インポートするゾーンファイルがある場合、Route 53 では、シンプルなルーティングポリシーを使用しながら標準的な DNS レコードが作成されます。
詳細については、「[ゾーンファイルをインポートしてレコードを作成する](resource-record-sets-creating-import.md)」を参照してください。
**コンソールで個別にレコードを作成する**
ゾーンファイルを取得しておらず、シンプルなルーティングポリシーを持つレコードをいくつか作成して使用を開始する場合には、Route 53 コンソールでレコードを作成します。エイリアスレコードと非エイリアスレコードの両方を作成できます。
詳細については、以下のトピックを参照してください。
+ [ルーティングポリシーの選択](routing-policy.md)
+ [エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)
+ [Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)
**プログラムでレコードを作成する**
レコードは、 AWS SDKs、、 AWS CLIまたは のいずれかを使用して作成できます AWS Tools for Windows PowerShell。詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/) を参照してください。
SDK を提供し AWS ないプログラミング言語を使用している場合は、Route 53 API を使用することもできます。詳細については、「[Amazon Route 53 API リファレンス](https://docs.aws.amazon.com/Route53/latest/APIReference/)」を参照してください。
## ステップ 4: Amazon Route 53 ネームサーバーを使用するようにドメイン登録を更新する (非アクティブドメイン)
ドメイン用にレコードを作成し終えたら、ドメインの DNS サービスを Amazon Route 53 に変更します。ドメインレジストラで設定を更新するには、以下の手順を実行します。
**ドメインのネームサーバーを更新するには**
1. Route 53 コンソールで、Route 53 ホストゾーンのネームサーバーを取得します。
1. Route 53 コンソール ([https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)) を開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. [**Hosted Zones (ホストゾーン)**] ページで、ホストゾーンのラジオボタン (名前ではない) を選択し、[**View details (詳細を表示)**] を選択します。
1. ホストゾーンの詳細ページで、[**Hosted zone details (ホストゾーンの詳細)**] を選択します。
1. **[Name Servers]** (ネームサーバー) で一覧表示されている 4 つのサーバー名を書き留めます。
1. ドメインのレジストラが提供する方法を使用して、この手順のステップ 2 で取得した 4 つの Route 53 ネームサーバーを使用するようにドメインのネームサーバーを変更します。
Route 53 に登録されているドメインに関しては、「[ドメインのネームサーバーおよびグルーレコードの追加あるいは変更](domain-name-servers-glue-records.md)」を参照してください。
# 新しいドメインの DNS ルーティングの設定
**Route 53 から購入した新しいドメイン**
ドメインを Route 53 に登録すると、そのドメインの DNS サービスとして、Route 53 が自動的に設定されます。Route 53 は、ドメインと同じ名前のホストゾーンを作成し、4 つのネームサーバーをホストゾーンに割り当て、それらのネームサーバーを使用するようにドメインを更新します。
**別のレジストラから購入した新しいドメイン**
例えば、最上位ドメイン (TLD) が Route 53 によって提供されていないため、別のレジストラからドメインを購入する場合、次の 2 つのオプションがあります。
+ **DNS ホスティングにのみ Route 53 を使用する:** 現在のレジストラは維持しますが、DNS 管理は Route 53 に委任します。以下の手順に従ってホストゾーンを作成し、レジストラのネームサーバーを更新します。
+ **ドメイン登録を Route 53 に移管する:** Route 53 をレジストラおよび DNS サービスにします。前提条件については「[ドメイン移管の移管前チェックリスト](domain-transfer-checklist.md)」、移管プロセスについては「[ドメイン登録の Amazon Route 53 への移管](domain-transfer-to-route-53.md)」を参照してください。
Route 53 でサポートされている TLD の詳細については、「[Amazon Route 53 に登録できる最上位ドメイン](registrar-tld-list.md)」を参照してください。
以下の手順に従ってパブリックホストゾーンを作成し、レジストラで作成されたネームサーバーを使用します。
**Route 53 ではないドメイン向けにホストゾーンを作成するには**
1. AWS マネジメントコンソール にサインインし、Route 53 コンソール ([https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)) を開きます。
1. ナビゲーションペインで、[**ホストゾーン**] を選択し、[**ホストゾーンの作成**] を選択します。
1. **[Name]** (名前) に、ホストゾーンを作成するドメインの名前を入力します。オプションの説明として `example.com` などです。**[Public hosted zone]** (パブリックホストゾーン) を選択し、**[Create hosted zone]** (ホストゾーンの作成) を選択します。
1. ホストゾーンを作成したら、作成された 4 つのネームサーバー (NS) レコードを書き留めます。それぞれが「ns-」で始まります。
ドメインレジストラで、上からネームサーバーを入力して、ドメイン管理を Route 53 ホストゾーンに委任します。
**DNS トラフィックをルーティングする**
Route 53 がドメインのインターネットトラフィックをルーティングする方法を指定するには、ホストゾーンにレコードを作成します。例えば、example.com のリクエストを Amazon EC2 インスタンスで実行されているウェブサーバーにルーティングする場合は、example.com のホストゾーンにレコードを作成し、EC2 インスタンスの Elastic IP アドレスを指定します。詳細については、以下のトピックを参照してください。
+ ホストゾーンでレコードを作成する方法については、「[レコードを使用する](rrsets-working-with.md)」を参照してください。
+ 選択した AWS リソースにトラフィックをルーティングする方法については、[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md) を参照してください。
+ DNS の仕組みについては、「[ウェブサイトやウェブアプリケーションへのインターネットトラフィックのルーティング](welcome-dns-service.md)」を参照してください。
+ DNS 安静を確認するには、「[Route 53 からの DNS 応答の確認](dns-test.md)」を参照してください。
# リソースへのトラフィックのルーティング
例えば、ユーザーがウェブブラウザにドメインの名前を入力して、ウェブサイトやウェブアプリケーションをリクエストした場合、そのユーザーは Amazon Route 53 により、Amazon S3 バケットやデータセンターのウェブサーバーなどのリソースにルーティングされます。リソースにトラフィックをルーティングするように Route 53 を設定するには、以下の操作を行います。
1. ホストゾーンの作成。パブリックホストゾーンまたはプライベートホストゾーンのいずれかを作成できます。
**パブリックホストゾーン**
インターネットトラフィックをリソースにルーティングする場合は、パブリックホストゾーンを作成します。例えば、顧客が EC2 インスタンスでホスティングしている会社のウェブサイトを表示できます。詳細については、「[パブリックホストゾーンの使用](AboutHZWorkingWith.md)」を参照してください。
**プライベートホストゾーン**
Amazon VPC 内でトラフィックをルーティングする場合は、プライベートホストゾーンを作成します。詳細については、「[プライベートホストゾーンの使用](hosted-zones-private.md)」を参照してください。
1. ホストゾーンにレコードを作成します。レコードは、各ドメイン名またはサブドメイン名のトラフィックをどこへルーティングするかを定義します。例えば、www.example.com のトラフィックをデータセンターのウェブサーバーにルーティングするには、通常 example.com ホストゾーンに www.example.com レコードを作成します。
詳細については、以下のトピックを参照してください。
+ [レコードを使用する](rrsets-working-with.md)
+ [サブドメインのトラフィックのルーティング](dns-routing-traffic-for-subdomains.md)
+ [インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)
# サブドメインのトラフィックのルーティング
acme.example.com や zenith.example.com などのサブドメインのリソースにトラフィックをルーティングする場合、次の 2 つの方法があります。
**ドメインのホストゾーンにレコードを作成します。**
通常、サブドメインのトラフィックをルーティングするには、ドメインと同じ名前のホストゾーンにレコードを作成します。例えば、acme.example.com のインターネットトラフィックをデータセンターのウェブサーバーにルーティングするには、example.com ホストゾーンに acme.example.com という名前のレコードを作成します。詳細については、トピック「[レコードを使用する](rrsets-working-with.md)」とそのサブトピックを参照してください。
**サブドメインのホストゾーンを作成し、新しいホストゾーンでレコードを作成する**
サブドメインのホストゾーンを作成することもできます。別のホストゾーンを使用してサブドメインのインターネットトラフィックをルーティングすることは、「サブドメインの責任をホストゾーンに委任する」、「サブドメインを他のネームサーバーに委任する」、またはその他類似の言い方で表現されることがあります。使用方法に関する概要は次のとおりです。
1. トラフィックをルーティングするサブドメインと同じ名前のホストゾーン (acme.example.com など) を作成します。
1. 新しいホストゾーンに、サブドメイン (acme.example.com) とそのサブドメイン (backend.acme.example.com など) のトラフィックをどのようにルーティングするかを定義するレコードを作成します。
1. 新しいホストゾーンの作成時に、Route 53 がそのゾーンに割り当てるネームサーバーを取得します。
1. ドメイン (example.com) のホストゾーンに新しい NS レコードを作成します。NS レコード名はサブドメイン名 (acme.example.com) でなければならず、ステップ 3 で取得した 4 つのネームサーバーをレコード値として指定します。
別のホストゾーンを使用してサブドメインのトラフィックをルーティングする場合、IAM のアクセス許可を使用してサブドメインのホストゾーンへのアクセスを制限できます 異なるグループによって管理されている複数のサブドメインがある場合は、各サブドメインのホストゾーンを作成すると、ドメインのホストゾーン内のレコードにアクセスする必要がある人の数を大幅に減らすことができます。
この委任プロセスを実装するには、次の IAM アクセス許可が必要です。Route 53 IAM ポリシーの詳細については、「」を参照してください[Amazon Route 53 での Identity and Access Management](security-iam.md)。
**親アカウント (example.com を所有)**
ユーザーまたはロールには、親ドメインのホストゾーンのレコードを変更するためのアクセス許可が必要です。
**子アカウント (acme.example.com を作成)**
ユーザーまたはロールには、サブドメインホストゾーンを作成および管理するためのアクセス許可が必要です。
サブドメインに別個のホストゾーンを使用することで、ドメインとサブドメインに異なる DNS サービスを使用することもできます。詳細については、「[親ドメインを移行しないで Amazon Route 53 をサブドメインの DNS サービスとして使用する](creating-migrating.md)」を参照してください。
この設定の各 DNS リゾルバーからの最初の DNS クエリに対するパフォーマンスの影響はわずかです。リゾルバーは、ルートドメインのホストゾーンから情報を取得し、次にサブドメインのホストゾーンから情報を取得する必要があります。サブドメインの最初の DNS クエリの後、リゾルバーは情報をキャッシュするため、TTL が期限切れになり、別のクライアントがそのリゾルバーからサブドメインをリクエストするまで、再度取得する必要はありません。詳細については、「[TTL (秒)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl)」セクションの「[Amazon Route 53 レコードの作成時または編集時に指定する値](resource-record-sets-values.md)」を参照してください。
**Topics**
+ [サブドメインのトラフィックをルーティングする別のホストゾーンの作成](#dns-routing-traffic-for-subdomains-new-hosted-zone)
+ [サブドメインの追加レベルのトラフィックのルーティング](#dns-routing-traffic-for-sub-subdomains)
## サブドメインのトラフィックをルーティングする別のホストゾーンの作成
サブドメインのトラフィックをルーティングする方法の 1 つは、サブドメインのホストゾーンを作成し、新しいホストゾーンに、サブドメインのレコードを作成することです。(より一般的なオプションは、ドメインのホストゾーン内にサブドメインのレコードを作成することです)。
**注記**
この手順では、サブドメインを Route 53 に委任する方法を示します。代わりにそれらのサービスのネームサーバーを指す NS レコードを作成することで、サブドメインを他の DNS サービスに委任することもできます。
プロセスの概要を次に示します。
1. サブドメインのホストゾーンを作成します。詳細については、「[サブドメインの新しいホストゾーンを作成する](#dns-routing-traffic-for-subdomains-creating-hosted-zone)」を参照してください。
1. ホストゾーンに、サブドメインのレコードを追加します。サブドメインのホストゾーンに属するレコードがドメインのホストゾーンに含まれている場合は、これらのレコードをサブドメインのホストゾーンに複製します。詳細については、「[サブドメインのホストゾーンでのレコードの作成](#dns-routing-traffic-for-subdomains-creating-records)」を参照してください。
1. ドメインのホストゾーンにサブドメインの NS レコードを作成します。これにより、サブドメインの責任を新しいホストゾーンのネームサーバーに委任します。サブドメインのホストゾーンに属するレコードがドメインのホストゾーンに含まれている場合は、これらのレコードをドメインのホストゾーンから削除します (ステップ 2 でサブドメインのホストゾーンに複製を作成しました)。詳細については、「[ドメインのホストゾーンの更新](#dns-routing-traffic-for-subdomains-delegating-responsibility)」を参照してください。
### サブドメインの新しいホストゾーンを作成する
Route 53 コンソールを使用してサブドメインのホストゾーンを作成するには、次の手順を実行します。
**サブドメインのホストゾーンを作成するには (コンソール)**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. Route 53 を初めて使用する場合、[**今すぐ始める**] を選択します。
既に Route 53 を利用している場合は、ナビゲーションペインの [**Hosted zones (ホストゾーン)**] を選択します。
1. [**ホストゾーンの作成**] を選択します。
1. 右側のペインでは、[acme.example.com] のようなサブドメイン名を入力します。オプションでコメントも入力できます。
a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。
1. **[Type]** (タイプ) では、デフォルト値の **[Public hosted zone]** (パブリックホストゾーン) をそのまま使用します。
1. 右ペインの下部にある **[Create Hosted Zone]** (ホストゾーンの作成) を選択します。
### サブドメインのホストゾーンでのレコードの作成
サブドメイン (acme.example.com) 、および、そのサブドメイン (backend.acme.example.com) のトラフィックを、Route 53 がどのようにルーティングするかは、サブドメインのホストゾーンにレコードを作成することで定義します。
サブドメインのホストゾーンにレコードを作成する場合は、以下の点に注意してください。
+ サブドメインのホストゾーンに追加のネームサーバー (NS) レコードまたは Start of Authority (SOA) レコードを作成しないでください。また、既存の NS レコードと SOA レコードを削除しないでください。
+ サブドメインのすべてのレコードは、当該サブドメインのホストゾーンに作成します。例えば、example.com ドメインと acme.example.com サブドメインの両方にホストゾーンがある場合、acme.example.com サブドメインのすべてのレコードは acme.example.com のホストゾーンに作成します。これには、backend.acme.example.com や beta.backend.acme.example.com などのレコードが含まれます。
+ サブドメイン (acme.example.com) のホストゾーンに属するレコードがドメイン (example.com) のホストゾーンに既に含まれている場合は、これらのレコードをサブドメインのホストゾーンに複製します。このプロセスの最後のステップとして、後でドメインのホストゾーンから重複するレコードを削除します。
**重要**
サブドメインの一部のレコードが、ドメインのホストゾーンとサブドメインのホストゾーンの両方にあると、DNS の動作が一貫しなくなります。動作は、DNS リゾルバーがキャッシュしたネームサーバー、ドメイン (example.com) のホストゾーンのネームサーバー、またはサブドメイン (acme.example.com) のホストゾーンのネームサーバーに応じて異なります。レコードが存在していても、そのレコードが DNS リゾルバーがクエリを送信する先のホストゾーンにない場合、Route 53 から NXDOMAIN (存在しないドメイン) が返されることがあります。
詳細については、「[レコードを使用する](rrsets-working-with.md)」を参照してください。
### ドメインのホストゾーンの更新
ホストゾーンを作成する際、Route 53 は、そのゾーンに対し 4 つのネームサーバーを自動的に割り当てます。ホストゾーンの NS レコードは、ドメインまたはサブドメインの DNS クエリに応答するネームサーバーを特定します。サブドメインのホストゾーンのレコードを使用してインターネットトラフィックのルーティングを開始するには、ドメイン (example.com) のホストゾーンに新しい NS レコードを作成し、これにサブドメイン (acme.example.com) の名前を渡します。NS レコードの値として、サブドメインのホストゾーンのネームサーバーの名前を指定します。
Route 53 が、DNS リゾルバーからサブドメイン acme.example.com (またはそのサブドメインの 1 つ) に対する DNS クエリを受け取ると、以下のことが発生します。
1. Route 53 は、ドメインのホストゾーン内で (example.com) を調べ、サブドメイン (acme.example.com) のための NS レコードを検出します。
1. Route 53 は、ドメイン (example.com) のホストゾーン内で、acme.example.com の NS レコードからネームサーバーを取得し、それを DNS リゾルバーに返します。
1. リゾルバーは、acme.example.com のクエリを acme.example.com ホストゾーンのネームサーバーに再送信します。
1. Route 53 は、acme.example.com ホストゾーンのレコードを使用してクエリに応答します。
サブドメインのホストゾーンを使用してサブドメインのトラフィックをルーティングし、ドメインのホストゾーンから重複するレコードを削除するように Route 53 を設定するには、次の手順を実行します。
**サブドメインのホストゾーンを使用するように Route 53 を設定するには (コンソール)**
1. Route 53 コンソールで、サブドメインのホストゾーンのネームサーバーを取得します。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. **[Hosted Zones]** (ホストゾーン) ページで、サブドメインのホストゾーンの名前を選択します。
1. 右ペインにある **[Hosted zones details]** (ホストゾーンの詳細) セクションの **[Name Servers]** (ネームサーバー) に、一覧表示されている 4 つのサーバーの名前をコピーします。
1. サブドメインではなくドメイン (example.com) のホストゾーンの名前を選択します。
1. [**Create record (レコードを作成)**] を選択します。
1. [**Simple routing (シンプルルーティング)**]、[**Next (次へ)**] の順に選択します。
1. [**Define simple record (シンプルなレコードを定義)**] を選択します。
1. 次の値を指定します。
**名前**
サブドメインの名前を入力します (例: `acme.example.com`)。これは、作成したサブドメインホストゾーンの名前と完全に一致する必要があります。
**値/トラフィックのルーティング先**
**[IP address or another value depending on the record type]** (IP アドレスまたはレコードタイプに応じた別の値) を選択し、ステップ 1 でコピーしたネームサーバーの名前を貼り付けます。
**レコードタイプ**
**[NS – Name servers for a hosted zone]** (NS — ホストゾーンのネームサーバー) を選択します。
**TTL (秒)**
NS レコードの、より一般的な値 (172800 秒など) に変更します。
1. **[Define simple record]** (シンプルなレコードを定義)、**[Create records]** (レコードを作成) の順に選択します。
1. サブドメインのホストゾーンに再作成したレコードがドメインのホストゾーンに含まれている場合は、これらのレコードをドメインのホストゾーンから削除します。詳細については、「[レコードの削除](resource-record-sets-deleting.md)」を参照してください。
完了すると、サブドメインのすべてのレコードがサブドメインのホストゾーンに含まれます。
## サブドメインの追加レベルのトラフィックのルーティング
acme.example.com などのサブドメインのサブドメインにトラフィックをルーティングするのと同じ方法で、トラフィックを backend.acme.example.com などのサブドメインにルーティングします。ドメインのホストゾーンにレコードを作成するか、低いレベルのサブドメインのホストゾーンを作成してから、その新しいホストゾーンにレコードを作成します。
下位レベルのサブドメインに別のホストゾーンを作成することにした場合、ドメイン名に 1 つ近いレベルにあるサブドメインのホストゾーン内にある、下位レベルのサブドメイン用に NS レコードを作成します。これにより、トラフィックがリソースに正しくルーティングされます。例えば、次のサブドメインのトラフィックをルーティングするとします。
+ subdomain1.example.com
+ subdomain2.subdomain1.example.com
別のホストゾーンを使用して subdomain2.subdomain1.example.com のトラフィックをルーティングするには、次の操作を行います。
1. subdomain2.subdomain1.example.com という名前のホストゾーンを作成します。
1. subdomain2.subdomain1.example.com ホストゾーンにレコードを作成します。詳細については、「[サブドメインのホストゾーンでのレコードの作成](#dns-routing-traffic-for-subdomains-creating-records)」を参照してください。
1. subdomain2.subdomain1.example.com ホストゾーンのネームサーバーの名前をコピーします。
1. subdomain1.example.com ホストゾーンで、subdomain2.subdomain1.example.com という NS レコードを作成し、subdomain2.subdomain1.example.com ホストゾーンのネームサーバーの名前に貼り付けます。
さらに、subdomain1.example.com から重複するレコードを削除します。詳細については、「[ドメインのホストゾーンの更新](#dns-routing-traffic-for-subdomains-delegating-responsibility)」を参照してください。
この NS レコードの作成を完了すると、subdomain2.subdomain1.example.com のホストゾーンを使用した、subdomain2.subdomain1.example.com サブドメインへのトラフィックのルーティングが、Route 53 により開始されます。
# ホストゾーンの使用
ホストゾーンはレコードのコンテナであり、レコードには example.com やそのサブドメイン (acme.example.com や zenith.example.com) の特定のドメインのトラフィックをどのようにルーティングするかに関する情報を保持します。ホストゾーンの名前と対応するドメインの名前は同じです。ホストゾーンには次の 2 つのタイプがあります。
+ *パブリックホストゾーン*には、トラフィックをインターネットでどのようにルーティングするかを指定するレコードが含まれています。詳細については、「[パブリックホストゾーンの使用](AboutHZWorkingWith.md)」を参照してください。
+ *プライベートホストゾーン*には、トラフィックを Amazon VPC でどのようにルーティングするかを指定するレコードが含まれています。詳細については、「[プライベートホストゾーンの使用](hosted-zones-private.md)」を参照してください。
# パブリックホストゾーンの使用
パブリックホストゾーンは、あるドメイン、例えば 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)
# パブリックホストゾーンを使用する場合の考慮事項
パブリックホストゾーンを使用する場合は、以下の点を考慮してください。
**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*」を参照してください。
# パブリックホストゾーンの作成
パブリックホストゾーンは、あるドメイン、例えば 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)」を参照してください。
# パブリックホストゾーンに対するネームサーバーの取得
ドメイン登録の 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 つのサーバー名を書き留めます。
# パブリックホストゾーンの一覧表示
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 クエリメトリクスの表示
指定したパブリックホストゾーン、またはパブリックホストゾーンの組み合わせについて、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 クエリメトリクスの表示
CloudWatch コンソールでパブリックホストゾーンの DNS クエリメトリクスを表示するには、以下の手順を実行します。
**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
を使用して 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"
]
}
]
}
```
# パブリックホストゾーンの削除
このセクションでは、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)
## トラフィックがドメインにルーティングされないようにする
ドメイン登録は維持するものの、ウェブサイトやウェブアプリケーションへのインターネットトラフィックのルーティングを停止する場合、ホストゾーンを削除する代わりに、ホストゾーン内の*レコード*を削除することをお勧めします。
**重要**
ホストゾーンを削除した場合、復元することはできません。新しいホストゾーンを作成して、ドメイン登録のネームサーバーを更新する必要があります。更新が有効になるには、最大 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 サービス」についてインターネットで検索してください。
## 別のサービスによって作成されたパブリックホストゾーンを削除する
ホストゾーンが別のサービスで作成されている場合、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 コンソールを使用してのパブリックホストゾーンの削除
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 応答の確認
ドメインに 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 の応答の確認
ツールを使用して、レコードに対する DNS クエリへの応答として Amazon Route 53 が返すレスポンスを確認できます。
**チェックツールを使用して、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 アドレスからのクエリのシミュレート (位置情報およびレイテンシーレコードのみ)
レイテンシーまたは位置情報レコードを作成した場合、チェックツールを使用して DNS リゾルバーおよびクライアントの IP アドレスからのクエリをシミュレートできます。
**チェックツールを使用して、指定された 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 アドレスまたはドメイン名が含まれます。
+ 他のレコードを参照するエイリアスレコードの場合、レスポンスには参照されるレコードの値が含まれています。
# ホワイトラベルネームサーバーの設定
各 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 の委任セットを作成する
ホワイトラベルネームサーバーは、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 を変更する
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: ホストゾーンにレコードを再作成する
ステップ 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 アドレスを取得します
再利用可能な委託セット内のネームサーバーの 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: ホワイトラベルネームサーバーにレコードを作成する
ホワイトラベルネームサーバーのドメイン名 (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 レコードを更新します
ホワイトラベルネームサーバーに使用するホストゾーンの 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: グルーレコードを作成し、レジストラの名前サーバーを変更します。
レジストラが用意している方法を使って、グルーレコードを作成し、レジストラのネームサーバーを変更します。
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: ウェブサイトまたはアプリケーションのトラフィックをモニタリングします。
ステップ 7 でグルーレコードを作成しネームサーバーを変更したウェブサイトまたはアプリケーションのトラフィックをモニタリングします。
+ **トラフィックが停止している場合** – レジストラから提供される方法を使って、ドメインのネームサーバーを以前の Route 53 ネームサーバーに戻します。これはステップ 6b でメモしたネームサーバーです。その後、何が悪かったのかを見極めます。
+ **トラフィックに影響がない場合** – 同じホワイトラベルネームサーバーを使用する残りのホストゾーンに対して、ステップ 6 ～ 8 を繰り返します。
## ステップ 9: TTL を元の値に戻す
ホワイトラベルネームサーバーを使用するようになったすべてのホストゾーンについて、以下の値を変更します。
+ ホストゾーンの NS レコードの TTL を、NS レコードでもっと一般的な値、例えば 172800 秒 (2 日) に変更します。
+ ホストゾーンの SOA レコードの最小 TTL を、SOA レコードでもっと一般的な値、例えば 900 秒に変更します。これは SOA レコードの最後の値です。
## ステップ 10: (オプション) 再帰的な DNS サービスへのお問い合わせ
*オプション* Amazon Route 53 の位置情報ルーティングを使用している場合は、EDNS0 の edns-client-subnet 拡張をサポートする再帰的 DNS サービスに連絡して、ホワイトラベルネームサーバーの名前を伝えます。こうすることで、この DNS サービスは、クエリが発信されたおおよその地理的場所に基づいて、最適な場所にある Route 53 に対し DNS クエリをルーティングし続けることができます。
# Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード
作成したパブリックホストゾーンごとに、Amazon Route 53 はネームサーバー (NS) レコードと Start of Authority (SOA) レコードを自動的に作成します。これらのレコードを変更する必要はほとんどありません。
**Topics**
+ [ネームサーバー (NS) レコード](#NSrecords)
+ [Start of Authority (SOA) レコード](#SOArecords)
## ネームサーバー (NS) レコード
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) レコード
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 サーバーなど) にアクセスできない時間が長くなります。
**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 レコードを管理するための高速リカバリの有効化
パブリック 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 レコードの高速復旧の仕組み
高速復旧が有効になっている場合、Route 53 はパブリックホストゾーンのコピーを米国西部 (オレゴン) リージョンに保持します。米国東部 (バージニア北部) リージョンのサービスが長期間使用できなくなった場合、Route 53 は 60 分以内にフェイルオーバーを実行し、高速復旧が有効なパブリックホストゾーンのコントロールプレーンオペレーションを米国西部 (オレゴン) リージョンに自動的にリダイレクトします。その後、CLI、SDK、API を使用してプログラムで DNS の変更を続行できます。フェイルオーバー中は、限られた API メソッドのセットが使用できることに注意してください。詳細については、「その他の考慮事項」セクションを参照してください。リージョンが回復すると、Route 53 はフェイルバック手順を実行し、コントロールプレーンオペレーションを自動的に米国東部 (バージニア北部) リージョンに戻します。
**注記**
米国東部 (バージニア北部) リージョンに障害が発生する前に、まず、パブリックホストゾーンでパブリック DNS レコードを管理するための高速復旧を有効にする必要があります。これは、コンソール、CLI、SDK、または API を介して行うことができます (このページの*「パブリック DNS レコードを管理するための高速復旧を有効にする方法*」セクションを参照してください）。フェイルオーバーの発生後にパブリック DNS レコードを管理するための高速復旧を有効にすることはできません。
## フェイルオーバー後の DNS 変更の再送信
通常の条件下では、高速復旧が有効になっているパブリックホストゾーンへの変更は、米国東部 (バージニア北部) リージョンで受け入れられ、米国西部 (オレゴン) リージョンに正常にレプリケートされます。ただし、米国東部 (バージニア北部) リージョンでサービスの中断が発生した場合、一部の変更は米国東部 (バージニア北部) リージョンで受け入れられますが、米国西部 (オレゴン) リージョンにレプリケートできない場合があります。これらの進行中の変更は、「ストランド変更」と呼ばれます。フェイルオーバーが完了すると、Route 53 では、DNS ワークフローを再開する前に、ストランドされた変更を再送信することをお勧めします。これを実現するには、 API を使用するか、以下で説明する AWS CloudFormation を使用します。
### API を使用して DNS の変更を追跡および送信する
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 を使用した変更の追跡と送信
AWS CloudFormation は、GetChange API を使用して DNS 変更のレプリケーションステータスを自動的に追跡し、DNS 変更が INSYNC と確認された後にのみ更新を完了します。CloudFormation を使用して DNS レコードを管理し、米国東部 (バージニア北部) リージョンが使用できなくなった場合、CloudFormation を使用して実行するアクションは、使用不可の期間中に正常に完了しません。ただし、Route 53 フェイルオーバープロセスが完了すると、CloudFormation が DNS の変更を再送信できるように、同じアクションを再試行するだけで済みます。
## 米国東部 (バージニア北部) リージョンへのフェイルバック
Route 53 は、リージョンが回復すると、パブリックホストゾーンのコントロールプレーンオペレーションを米国東部 (バージニア北部) リージョンにフェイルバックします。このプロセス中にストランド変更が導入されないため、フェイルバック中に DNS 変更を再送信する必要はありません。
## その他の考慮事項
高速復旧機能に関連して注意すべき追加の考慮事項がいくつかあります。
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 レコードを管理するための高速復旧を有効にする方法
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
```
# プライベートホストゾーンの使用
*プライベートホストゾーン*は、Amazon VPC サービスで作成する 1 つ以上の VPC 内のドメインとそのサブドメインへの DNS クエリに対し、Amazon Route 53 がどのように応答するかに関する情報を保持するコンテナです。プライベートホストゾーンの動作は次のとおりです。
1. example.com などのプライベートホストゾーンを作成して、ホストゾーンに関連付ける VPC を指定します。ホストゾーンを作成すると、さらに多くの VPC をそのゾーンに関連付けることができます。
1. VPC 内および VPC 間でドメインとサブドメインへの DNS クエリに Route 53 が応答する方法を決定するホストゾーンに、レコードを作成します。例えば、プライベートホストゾーンに関連付けた VPC に、EC2 インスタンスで実行されるデータベースサーバーがあるとします。A または AAAA レコードを作成し (例: db.example.com)、データベースサーバーの IP アドレスを指定します。
レコードの詳細については、「[レコードを使用する](rrsets-working-with.md)」を参照してください。プライベートホストゾーンを使用する際の Amazon VPC の要件については、*Amazon VPC ユーザーガイド*の[「プライベートホストゾーンの使用](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) 」を参照してください。
1. アプリケーションが db.example.com への DNS クエリを送信すると、Route 53 は対応する IP アドレスを返します。プライベートホストゾーンから回答を得るには、関連する VPC のいずれかで EC2 インスタンスを実行している (またはハイブリッド環境のインバウンドエンドポイントがある) 必要があります。VPC またはハイブリッド環境の外部からプライベートホストゾーンにクエリを実行しようとすると、クエリはインターネット上で再帰的に解決されます。
1. アプリケーションは、Route 53 から取得した IP アドレスを使用して、データベースサーバーとの接続を確立します。
プライベートホストゾーンを作成すると以下のネームサーバーが使用されます。
+ ns-0.awsdns-00.com
+ ns-512.awsdns-00.net
+ ns-1024.awsdns-00.org
+ ns-1536.awsdns-00.co.uk
DNS プロトコルは、すべてのホストゾーンに NS レコードを設定する必要があるため、これらのネームサーバーが使用されます。これらのネームサーバーは予約済みであり、Route 53 パブリックホストゾーンでは使用されません。これらのゾーンは、プライベートホストゾーンで指定された VPC に接続されたインバウンドエンドポイントを使用して、ホストゾーンに関連付けられた VPC の VPCs Resolver を介してのみクエリできます。
ネームサーバーはインターネットに表示されますが、VPC Resolver はネームサーバーアドレスに接続しません。さらに、インターネット経由でネームサーバーへのクエリを直接実行しても、プライベートホストゾーンの情報は返されません。代わりに、VPC リゾルバーは、VPC からホストゾーンへの関連付けに基づくプライベート名前空間内にクエリがあることを検出し、直接のプライベート接続を使用してプライベート DNS サーバーに到達します。
**注記**
プライベートホストゾーンの NS レコードセットは必要に応じて変更できますが、プライベートな DNS 解決は引き続き機能します。この方法は推奨できませんが、希望する場合は、パブリック DNS サーバーでは使用されない予約済みのドメイン名を使用してください。
インターネットでドメインへのトラフィックをルーティングする場合は、Route 53 の*パブリック*ホストゾーンを使用します。詳細については、「[パブリックホストゾーンの使用](AboutHZWorkingWith.md)」を参照してください。
**Topics**
+ [プライベートホストゾーンを使用する場合の考慮事項](hosted-zone-private-considerations.md)
+ [プライベートホストゾーンの作成](hosted-zone-private-creating.md)
+ [プライベートホストゾーンの一覧表示](hosted-zone-private-listing.md)
+ [プライベートホストゾーンにさらに VPC を関連付ける](hosted-zone-private-associate-vpcs.md)
+ [Amazon VPC と、作成したプライベートホストゾーンを異なる AWS アカウントに関連付ける](hosted-zone-private-associate-vpcs-different-accounts.md)
+ [プライベートホストゾーンから VPC の関連付けを解除する](hosted-zone-private-disassociate-vpcs.md)
+ [プライベートホストゾーンの削除](hosted-zone-private-deleting.md)
+ [VPC アクセス許可](hosted-zone-private-vpc-permissions.md)
# プライベートホストゾーンを使用する場合の考慮事項
プライベートホストゾーンを使用する場合は、以下の点を考慮してください。
+ [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings)
+ [Route 53 health checks](#hosted-zone-private-considerations-health-checks)
+ [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies)
+ [Split-view DNS](#hosted-zone-private-considerations-split-view-dns)
+ [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping)
+ [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping)
+ [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)
+ [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain)
+ [Custom DNS servers](#hosted-zone-private-considerations-custom-dns)
+ [Required IAM permissions](#hosted-zone-private-considerations-required-permissions)
**Amazon VPC の設定**
プライベートホストゾーンを使用するには、次の Amazon VPC 設定で `true` を指定する必要があります：
+ `enableDnsHostnames`
+ `enableDnsSupport`
詳細については「*Amazon VPC ユーザーガイド*」の「[VPC の DNS 属性の表示と更新](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html)」を参照してください。
**Route 53 ヘルスチェック**
プライベートホストゾーンの Route 53 ヘルスチェックでは、フェイルオーバー、複数値レスポンス、加重、レイテンシー、位置情報、地理的近接性レコードのみへの関連付けが可能です。ヘルスチェックとフェイルオーバーレコードの関連付けの詳細については、「[プライベートホストゾーンのフェイルオーバーの設定](dns-failover-private-hosted-zones.md)」を参照してください。
**プライベートホストゾーンのレコードでサポートされるルーティングポリシー**
プライベートホストゾーンにレコードを作成すると、次のルーティンポリシーを使用できます。
+ [シンプルルーティング](routing-policy-simple.md)
+ [フェイルオーバールーティング](routing-policy-failover.md)
+ [複数値回答ルーティング](routing-policy-multivalue.md)
+ [加重ルーティング](routing-policy-weighted.md)
+ [レイテンシーに基づくルーティング](routing-policy-latency.md)
+ [位置情報ルーティング](routing-policy-geo.md)
+ [地理的近接性ルーティング](routing-policy-geoproximity.md)
その他のルーティングポリシーを使用してプライベートホストゾーンでレコードを作成することはサポートされていません。
**スプリットビュー DNS**
Route 53 を使用して、スプリットビュー DNS (別名、スプリットホライズン DNS) を設定できます。スプリットビュー DNS では、内部使用 (accounting.example.com) とパブリックウェブサイト (www.example.com) などの外部使用で同じドメイン名 (example.com) を使用します。内部および外部で同じサブドメイン名を使用したいが、内部ユーザーと外部ユーザーに対して、異なるコンテンツを供給したり、異なる認証を要求したりする場合もあります。
スプリットビュー DNS を設定するには、以下の手順を実行します。
1. 同じ名前を持つパブリックホストゾーンおよびプライベートホストゾーンを作成します。(スプリットビュー DNS は、パブリックホストゾーンに別の DNS サービスを使用している場合でも機能します)。
1. 1 つ以上の Amazon VPC をプライベートホストゾーンに関連付けます。Route 53 VPC Resolver は、プライベートホストゾーンを使用して、指定された VPCs。
1. 各ホストゾーンにレコードを作成します。パブリックホストゾーンのレコードはインターネットトラフィックのルーティング方法を制御し、プライベートホストゾーンのレコードは Amazon VPC でのトラフィックのルーティング方法を制御します。
VPC とオンプレミスの両方のワークロードの名前解決を実行する必要がある場合は、Route 53 VPC Resolver を使用できます。詳細については、「[Route 53 VPC Resolver とは](resolver.md)」を参照してください。
**名前空間が重複するパブリックホストゾーンとプライベートホストゾーン**
や example.com など、名前空間が重複するプライベートホストゾーンとパブリックホストゾーンがある場合 accounting.example.com 、VPC Resolver は最も具体的な一致に基づいてトラフィックをルーティングします。ユーザーがプライベートホストゾーンに関連付けられている Amazon VPC の EC2 インスタンスにログインすると、Route 53 VPC Resolver が DNS クエリを処理する方法は次のとおりです。
1. VPC Resolver は、プライベートホストゾーンの名前が accounting.example.com などのリクエストのドメイン名と一致するかどうかを評価します。次のいずれかに該当すると、一致したとみなされます。
+ 完全な一致
+ プライベートホストゾーンの名前がリクエスト内のドメイン名の親である。例えば、リクエスト内のドメイン名が次のような名前であるとします。
**seattle.accounting.example.com**
次のホストゾーンは seattle.accounting.example.com の親であるため、これらが一致します。
+ **accounting.example.com**
+ **example.com**
一致するプライベートホストゾーンがない場合、VPC Resolver はリクエストをパブリック DNS リゾルバーに転送し、リクエストは通常の DNS クエリとして解決されます。
1. リクエスト内のドメイン名と一致するプライベートホストゾーンの名前がある場合は、リクエスト内のドメイン名と DNS タイプと一致するレコードが検索されます (例: accounting.example.com の A レコード)。
**注記**
一致するプライベートホストゾーンがあっても、リクエストのドメイン名とタイプに一致するレコードがない場合、VPC リゾルバーはリクエストをパブリック DNS リゾルバーに転送しません。代わりに、NXDOMAIN (存在しないドメイン) をクライアントに返します。
**名前空間が重複する複数のプライベートホストゾーン**
や example.com など、名前空間が重複するプライベートホストゾーンが 2 つ以上ある場合 accounting.example.com 、VPC Resolver は最も具体的な一致に基づいてトラフィックをルーティングします。
プライベートホストゾーン (example.com) と、同じドメイン名のネットワークにトラフィックをルーティングする Route 53 VPC Resolver ルールがある場合、VPC Resolver ルールが優先されます。「[Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)」を参照してください。
ユーザーがすべてのプライベートホストゾーンに関連付けられている Amazon VPC の EC2 インスタンスにログインすると、VPC Resolver が DNS クエリを処理する方法は次のとおりです。
1. VPC Resolver は、accounting.example.com などのリクエスト内のドメイン名がプライベートホストゾーンのいずれかの名前と一致するかどうかを評価します。
1. リクエスト内のドメイン名と正確に一致するホストゾーンがない場合、VPC Resolver はリクエスト内のドメイン名の親である名前を持つホストゾーンをチェックします。例えば、リクエスト内のドメイン名が次のような名前であるとします。
`seattle.accounting.example.com`
次のホストゾーンは `seattle.accounting.example.com` の親であるため、一致します。
+ `accounting.example.com`
+ `example.com`
VPC Resolver は よりも具体的`accounting.example.com`であるため、 を選択します`example.com`。
1. VPC Resolver は、 の A レコードなど、リクエスト内のドメイン名と DNS タイプに一致するレコードを`accounting.example.com`ホストゾーンで検索します`seattle.accounting.example.com`。
リクエストのドメイン名とタイプに一致するレコードがない場合、VPC Resolver は NXDOMAIN (存在しないドメイン) をクライアントに返します。
**プライベートホストゾーンと Route 53 VPC リゾルバールール**
プライベートホストゾーン (example.com) と、同じドメイン名のネットワークにトラフィックをルーティングする VPC Resolver ルールがある場合、VPC Resolver ルールが優先されます。
例えば、次の設定があるとします。
+ example.com というプライベートホストゾーンがあり、それを VPC に関連付けます。
+ example.com のトラフィックをネットワークに転送する Route 53 VPC Resolver ルールを作成し、そのルールを同じ VPC に関連付けます。
この設定では、VPC リゾルバールールがプライベートホストゾーンよりも優先されます。DNS クエリは、プライベートホストゾーンのレコードに基づいて解決されるのではなく、ネットワークに転送されます。
**サブドメインの責任の委任**
サブドメインの責任を委任する NS レコードをプライベートホストゾーンに作成できるようになりました。詳細については、「[リゾルバーの委任ルールのチュートリアル](outbound-delegation-tutorial.md)」を参照してください。
**カスタム DNS サーバー**
VPC 内の Amazon EC2 インスタンスでカスタム DNS サーバーを設定した場合、プライベート DNS クエリを VPC 用に Amazon が提供する DNS サーバーの IP アドレスにルーティングするようにそれらの DNS サーバーを設定する必要があります。この IP アドレスは、VPC ネットワーク範囲のベースに「プラス 2」した IP アドレスです。例えば、VPC の CIDR 範囲が 10.0.0.0/16 である場合、DNS サーバーの IP アドレスは 10.0.0.2 です。
VPCs とネットワーク間で DNS クエリをルーティングする場合は、VPC Resolver を使用できます。詳細については、「[Route 53 VPC Resolver とは](resolver.md)」を参照してください。
**必要な IAM アクセス許可**
プライベートホストゾーンを作成するには、Route 53 アクションのアクセス許可に加えて、Amazon EC2 アクションのアクセス許可を IAM に付与する必要があります。詳細については、「*サービス承認リファレンス*」の「[Actions, resources, and condition keys for Route 53](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html)」を参照してください。
# プライベートホストゾーンの作成
プライベートホストゾーンは、1 つ以上の Amazon Virtual Private Cloud (VPC) でホストするドメインを対象としたレコードのコンテナです。ドメイン (例えば、example.com) のホストゾーンを作成した後、VPC 内および VPC 間でそのドメインへのトラフィックをルーティングする方法を Amazon Route 53 に伝えるレコードを作成します。
**重要**
プライベートホストゾーンを作成する際、VPC とホストゾーンを関連付ける必要があります。VPC は、必ずホストゾーン作成時と同一のアカウントを使用して作成します。ホストゾーンを作成したら、別の AWS アカウントを使用して作成した VPCs など、追加の VPCs をホストゾーンに関連付けることができます。
あるアカウントを使用して作成した VPC と、別のアカウントを使用して作成したプライベートホストゾーンを関連付けるには、関連付けを許可してから、その関連付けをプログラム的にする必要があります。詳細については、「[Amazon VPC と、作成したプライベートホストゾーンを異なる AWS アカウントに関連付ける](hosted-zone-private-associate-vpcs-different-accounts.md)」を参照してください。
Route 53 API を使用してのプライベートホストゾーンの作成については、［[Amazon Route 53 API リファレンス](https://docs.aws.amazon.com/Route53/latest/APIReference/)］を参照してください。
**Route 53 コンソールを使用してプライベートホストゾーンを作成するには**
1. Route 53 ホストゾーンに関連付ける各 VPC について、次の VPC 設定を `true` に変更します。
+ `enableDnsHostnames`
+ `enableDnsSupport`
詳細については、*Amazon VPC ユーザーガイド*の「[VPC の DNS サポートを更新する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)」を参照してください。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. Route 53 を初めて使用する場合は、[**今すぐ始める**] を選択します。
既に Route 53 を利用している場合は、ナビゲーションペインの [**Hosted zones (ホストゾーン)**] を選択します。
1. [**ホストゾーンの作成**] を選択します。
1. [**Create Private Hosted Zone**] ペインで、ドメイン名を入力し、必要に応じてコメントも入力します。
a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。
1. [**Type (タイプ)**] リストから、[**Private Hosted Zone (プライベートホストゾーン**)] を選択します。
1. [**VPC ID**] リストで、このプライベートホストゾーンに関連付ける VPC を選択します。
**注記**
コンソールに次のメッセージが表示されている場合、ホストゾーンを、同じ VPC 内にあり同じ名前空間を持つ別のホストゾーンと関連付けようとしています。
「競合中のドメインは、特定の VPC または委託セットと既に関連付けられています」
例えば、ホストゾーン A とホストゾーン B の両方で、`example.com`のように同じドメインネームとなっている場合は、両方のホストゾーンを共通の VPC に関連付けることはできません。
1. [**ホストゾーンの作成**] を選択します。
# プライベートホストゾーンの一覧表示
Amazon Route 53 コンソールを使用して、現在の AWS アカウントで作成したすべてのホストゾーンを一覧表示できます。Route 53 API を使用してホストゾーンを一覧表示する方法については、*Amazon Route 53 API リファレンス*の「[ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)」を参照してください。
**AWS アカウントに関連付けられているホストゾーンを一覧表示するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
**ホストゾーン**ページには、現在の AWS アカウントを使用して作成されたすべてのホストゾーンのリストが自動的に表示されます。[**Type**] 列は、ホストゾーンがプライベートかパブリックかを示しています。列見出しを選択すると、プライベートホストゾーンとパブリックホストゾーンがグループ分けされます。
# プライベートホストゾーンにさらに VPC を関連付ける
同じ AWS アカウントを使用してホストゾーンと VPCs を作成した場合は、Amazon Route 53 コンソールを使用して、より多くの VPCs をプライベートホストゾーンに関連付けることができます。
**重要**
あるアカウントを使用して作成した VPC と、別のアカウントを使用して作成したプライベートホストゾーンを関連付ける場合は、まず関連付けを許可する必要があります。また、関連付けを許可する場合や VPC をホストゾーンに関連付ける場合はいずれも、 AWS コンソールを使用することはできません。詳細については、「[Amazon VPC と、作成したプライベートホストゾーンを異なる AWS アカウントに関連付ける](hosted-zone-private-associate-vpcs-different-accounts.md)」を参照してください
Route 53 API を使用して、より多くの VPC をプライベートホストゾーンに関連付ける方法については、*Amazon Route 53 API リファレンス*の「[AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html)」を参照してください。
**Route 53 コンソールを使用してプライベートホストゾーンに VPC をさらに関連付けるには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. さらに VPC を関連付けるプライベートホストゾーンのラジオボタンを選択します。
1. **[編集]** を選択します。
1. [**Add VPC (VPC を追加)**] を選択します。
1. このホストゾーンに関連付けるリージョンと VPC の ID を選択します。
1. さらに VPC をこのホストゾーンに関連付けるには、ステップ 5 と 6 を繰り返します。
1. **[Save changes]** (変更の保存) をクリックします。
# Amazon VPC と、作成したプライベートホストゾーンを異なる AWS アカウントに関連付ける
1 つの AWS アカウントで作成した VPC を、別のアカウントで作成したプライベートホストゾーンに関連付ける場合は、次の手順を実行します。
**Amazon VPC と、作成したプライベートホストゾーンを異なる AWS アカウントに関連付けるには**
1. ホストゾーンを作成したアカウントを使用して、次のいずれかの方法で VPC とプライベートホストゾーンの関連付けを許可します。
+ **AWS CLI** – *AWS CLI コマンドリファレンス*の [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html) を参照してください。
+ ** AWS SDK** または **AWS Tools for Windows PowerShell** – ドキュメントページの該当する[AWSドキュメント](https://docs.aws.amazon.com/)を参照してください。
+ **Amazon Route 53 API** – ［*Amazon Route 53 API リファレンス*］の「[CreateVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html)」を参照してください。
次の点に注意してください。
+ あるアカウントで作成した複数の VPC と別のアカウントで作成したホストゾーンを関連付ける場合は、VPC ごとに認可リクエストを送信する必要があります。
+ 関連付けを許可する際、ホストゾーン ID を指定する必要があるため、プライベートホストゾーンが存在している必要があります。
+ VPC とプライベートホストゾーンの関連付けを許可する場合や、関連付けを作成する場合はいずれも、Route 53 コンソールを使用することはできません。
1. VPC を作成したアカウントを使用して、VPC をこのホストゾーンと関連付けます。関連付けの承認と同様に、 AWS SDK、Tools for Windows PowerShell、、 AWS CLIまたは Route 53 API を使用できます。この API を使用している場合は、「[AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html)」アクションを使用します。
1. *推奨* – VPC をホストゾーンと関連付けるために、ここでの許可を削除します。許可を削除しても関連付けには影響しませんが、今後 この VPC とホストゾーンを再度関連付けることはできません。ホストゾーンと VPC を再関連付けしたい場合は、この手順のステップ 1 および 2 を繰り返します。
**重要**
`ListHostedZonesByVPC` は VPC を指定したホストゾーンを返し、`GetHostedZone` API はホストゾーンに関連付けられた VPC を返します。これらの API は、`AssociateVPCWithHostedZone` API によって作成されるホストゾーンと VPC の関連付け、またはプライベートホストゾーンの作成時のみを考慮します。VPC へのホストゾーンの関連付けの完全なリストが必要な場合は、[ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html) も呼び出してください。
**注記**
作成できる許可の最大数については、「[エンティティのクォータ](DNSLimitations.md#limits-api-entities)」を参照してください。
# プライベートホストゾーンから VPC の関連付けを解除する
Amazon Route 53 コンソールを使用して、プライベートホストゾーンから VPC の関連付けを解除できます。これにより Route 53 は、VPC から DNS クエリが送られたホストゾーン内のレコードを使用する、トラフィックのルーティングを停止します。例えば、example.com ホストゾーンと VPC を関連付けた後に、その VPC とホストゾーンの関連付けを解除すると、Route 53 は、example.com または example.com ホストゾーン内の他のレコードの DNS クエリの解決を停止します。
**注記**
最後の VPC とプライベートホストゾーンの関連付けを解除することはできません。その VPC の関連付けを解除するには、まず別の VPC をホストゾーンに関連付ける必要があります。
**プライベートホストゾーンから VPC の関連付けを解除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. 1 つ以上のVPC の関連付けを解除する、プライベートホストゾーンに対応しているラジオボタンをオンにします。
1. [**Edit**] を選択します。
1. [**Remove VPC (VPC を削除)**] を選択します。このホストゾーンから関連付けを解除する VPC の横にあります。
1. **[Save changes]** (変更の保存) をクリックします。
# プライベートホストゾーンの削除
このセクションでは、Amazon Route 53 コンソールを使用してプライベートホストゾーンを削除する方法を説明します。
デフォルトの SOA レコードと NS レコード以外のレコードがない場合にのみ、プライベートホストゾーンを削除できます。ホストゾーンに他のレコードが含まれる場合、ホストゾーンを削除する前にそれらを削除する必要があります。これによって、レコードが含まれているホストゾーンを誤って削除するのを防ぎます。
**Topics**
+ [別のサービスによって作成されたプライベートホストゾーンを削除する](#delete-private-hosted-zone-created-by-another-service)
+ [Route 53 コンソールを使用してプライベートホストゾーンを削除する](#delete-private-hosted-zone-procedure)
## 別のサービスによって作成されたプライベートホストゾーンを削除する
プライベートホストゾーンが別のサービスで作成されている場合、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 コンソールを使用してプライベートホストゾーンを削除する
Route 53 コンソールを使用してプライベートホストゾーンを削除するには、以下の手順を実行します。
**Route 53 コンソールを使用してプライベートホストゾーンを削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. 削除するホストゾーンに NS と SOA のレコードのみが含まれていることを確認します。追加レコードが含まれている場合、それを削除します。
1. 削除するホストゾーンの名前を選択します。
1. [**Record (レコード)**] ページで、レコードのリストに [**Type (タイプ)**] 列の値が [**NS**] または [**SOA**] 以外に設定されたレコードが含まれている場合、その行を選択して、[**Delete (削除)**] を選択します。
複数の連続するレコードを選択するには、最初の行を選択し、[**Shift**] (シフト) キーを押したまま最後の行を選択します。複数の連続していないレコードを選択するには、最初の行を選択し、**Ctrl** キーを押したまま、残りの行を選択します。
1. [Hosted Zones (ホストゾーン)] ページで、削除するホストゾーンの行を選択します。
1. **[削除]** を選択します。
1. 確認キーを入力し、[**Delete (削除)**] を選択します。
# VPC アクセス許可
VPC アクセス許可は Identity and Access management (IAM) ポリシー条件を使用して、[AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html)、[DisassociateVPCFromHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisassociateVPCFromHostedZone.html)、[CreateVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html)、[DeleteVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html)、[CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)、[ListHostedZonesByVPC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZonesByVPC.html) の API を使用する際に VPC の細かいアクセス許可を設定できます。
IAM ポリシー条件 を使用すると`route53:VPCs`、他のユーザーにきめ細かな管理権限を付与できます AWS 。これにより、ホストゾーンに関連付ける、ホストゾーンの関連付けを解除する、VPC 関連付け認可を作成する、VPC 関連付け認可を削除する、ホストゾーンを作成する、または次のホストゾーンを一覧表示するアクセス許可をユーザーに付与できます。
+ 単一の VPC。
+ 同じリージョン内のすべての VPC。
+ 複数の VPC。
VPC アクセス許可の詳細については、「[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions-route53.md)」を参照してください。
AWS ユーザーを認証する方法については、[アイデンティティを使用した認証](security-iam.md#security_iam_authentication)「」を参照してください。Route 53 リソースへのアクセスを制御する方法については、「」を参照してください[アクセスコントロール](security-iam.md#access-control)。
# ホストゾーンを別の AWS アカウントに移行する
ホストゾーンを別のホストゾーンに移行する場合は AWS アカウント、以下の推奨ステップに従います。
これらのステップは、レコードの変更頻度が低いホストゾーンに最適です。頻繁にレコードが更新されるホストゾーンの場合は、次の点を考慮してください。
+ 移行中にリソースレコードを更新しないでください。
+ 委任が移管された後、古いホストゾーンと新しいホストゾーンの両方でリソースレコードの変更を公開します。
**前提条件**
AWS CLI をインストールまたはアップグレードする:
のダウンロード、インストール、設定については AWS CLI、 [AWS Command Line Interface ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/)を参照してください。
**注記**
CLI を設定し、ホストゾーンを作成したアカウントと、ホストゾーンの移行先アカウントの両方を使用中に CLI を使用できるようにします。詳細については、*AWS Command Line Interface ユーザーガイド*の[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)を参照してください。
を既に使用している場合は AWS CLI、CLI コマンドが最新の Route 53 機能をサポートするように、最新バージョンの CLI にアップグレードすることをお勧めします。
**Topics**
+ [ステップ 1: 移行の準備をする](#hosted-zones-migrating-prepare)
+ [ステップ 2: 新しいホストゾーンを作成する](#hosted-zones-migrating-create-hosted-zone)
+ [ステップ 3: (オプション) ヘルスチェックを移行する](#hosted-zones-migrating-health-checks)
+ [ステップ 4: 古いホストゾーンから新しいホストゾーンにレコードを移行する](#hosted-zones-migrating-old-to-new)
+ [ステップ 5: 古いホストゾーンと新しいホストゾーンのレコードを比較する](#hosted-zones-migrating-compare)
+ [ステップ 6: ドメイン登録を更新して新しいホストゾーンのネームサーバーを使用する](#hosted-zones-migrating-update-domain)
+ [ステップ 7: NS レコードの TTL をより高い値に戻す](#hosted-zones-migrating-change-ttl)
+ [ステップ 8: DNSSEC 署名を再度有効にし、信頼チェーンを確立する (必要な場合)](#hosted-zones-migrating-enable-dnssec)
+ [ステップ 9: (オプション) 古いホストゾーンを削除する](#hosted-zones-migrating-delete-old-hosted-zone)
## ステップ 1: 移行の準備をする
準備ステップは、ホストゾーンの移行に関連するリスクを最小限に抑える上で役立ちます。
**1. ゾーンの可用性を監視する**
ドメイン名の可用性をゾーンで監視できます。これにより、移行のロールバックにつながる可能性のある問題に対処できます。CloudWatch またはクエリログを使用してトラフィックが最も多いドメイン名を監視できます。クエリログのセットアップの詳細については、「[Amazon Route 53 のモニタリング](monitoring-overview.md)」を参照してください。
監視はシェルスクリプトまたはサードパーティサービスを通じて実行できます。ただし、ドメインが利用できないために顧客からフィードバックを得る可能性もあるため、ロールバックが必要かどうかを判断する唯一のシグナルではありません。
**2. TTL 設定を下げる**
レコードの TTL (有効期限) 設定は、DNS リゾルバーがレコードをキャッシュし、キャッシュされた情報を使用する期間を指定します。TTL が期限切れになると、リゾルバーはドメインの DNS サービスプロバイダに別のクエリを送信し、最新の情報を取得します。
NS レコードの一般的な TTL 設定は 172800 秒、つまり 2 日です。NS レコードには、ドメインネームシステム (DNS) がドメインのトラフィックをルーティングする方法に関する情報を得るために使用できるネームサーバーがリストされています。現在の DNS サービスプロバイダーと Route 53 の両方で NS レコードの TTL を下げることで、DNS を Route 53 に移行している際に問題が検出された場合のドメインのダウンタイムを短縮できます。TTL を下げないと、何か問題が発生した場合、ドメインはインターネット上で最大 2 日間使用できなくなる可能性があります。
**TTL を下げるには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted Zones**] (ホストゾーン) を選択します。
1. ホストゾーンの名前を選択します。
1. NS レコードを選択し、**[Record details]** (レコードの詳細) ペインで **[Edit record]** (レコードの編集) を選択します。
1. [**TTL (Seconds)**] の値を変更します。60 秒から 900 秒 (15 分) の間の値を指定することをお勧めします。
1. **[保存]** を選択します。
**3. (DNSSEC を構成している場合) 親ゾーンから DS レコードを削除する**
ドメインで DNSSEC を設定している場合は、ドメインを Route 53 に移行する前に、親ゾーンから Delegation Signer (DS) レコードを削除します。
親ゾーンが Route 53 を介してホストされている場合、詳細については「[ドメインのパブリックキーの削除](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys)」を参照してください。別のレジストラが親ゾーンをホストしている場合は、それらのホストに対し DS レコードの削除を依頼します。
Route 53 は現在、DNSSEC 設定の移行をサポートしていません。そのため、親ゾーンから DS レコードを削除して、移行前にドメインに対して実行された DNSSEC 検証を無効にする必要があります。移行後、新しいホストゾーンで DNSSEC を設定し、それぞれの DS レコードを親ゾーンに追加することで、DNSSEC 検証を再度有効化できます。
**4. 移行ホストゾーンに依存する他の進行中のオペレーションがないことを確認します。**
一部のオペレーションは、移行ホストゾーンの DNS 解決に依存します。例えば、TLS/SSL 証明書の更新プロセスでは DNS レコードの変更が必要になる場合があり、プロバイダーは検証方法として DNS レコードの解決を試みます。移行前に、ホストゾーンの移行による予期しない影響を避けるために、他のオペレーションが行われていないことを確認する必要があります。
## ステップ 2: 新しいホストゾーンを作成する
ホストゾーンを移行するアカウントに新しいホストゾーンを作成します。
AWS CLI または コンソールの手順のタブを選択します。
+ [CLI](#migrate-hz-cli)
+ [コンソール](#migrate-hz-console)
------
#### [ CLI ]
次のコマンドを入力します。
```
aws route53 create-hosted-zone \
--name $hosted_zone_name \
--caller-reference $unique_string
```
詳細については、「[create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html)」を参照してください。
------
#### [ Console ]
**別のアカウントを使用して新しいホストゾーンを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
ホストゾーンの移行先となるアカウントのアカウント認証情報を使用してサインインします。
1. ホストゾーンの作成。詳細については、「[パブリックホストゾーンの作成](CreatingHostedZone.md)」を参照してください。
1. ホストゾーン ID を書き留めます。この情報は、プロセス中に後で必要になる場合があります。
1. Route 53 コンソールからログアウトします。
「準備ステップ 1 の TTL 設定を下げる」の「TTL 設定を下げる」と同様、新しいゾーンの NS TTL も下げます。
------
## ステップ 3: (オプション) ヘルスチェックを移行する
新しいアカウントの DNS レコードを、移行元のアカウントの Route 53 ヘルスチェックに関連付けることができます。Route 53 ヘルスチェックを移行するには、既存のヘルスチェックと同じ設定で新しいアカウントに新しいヘルスチェックを作成する必要があります。詳細については、「[Amazon Route 53 ヘルスチェックの作成](dns-failover.md)」を参照してください。
## ステップ 4: 古いホストゾーンから新しいホストゾーンにレコードを移行する
コンソールまたは を使用して、 から別の AWS アカウント にレコードを移行できます AWS CLI。
------
#### [ Console ]
ゾーンに少数のレコードしか含まれていない場合は、Route 53 コンソールを使用して古いゾーンのレコードを一覧表示し、メモして、新しいゾーンに作成することを検討できます。[ステップ 3: (オプション) ヘルスチェックを移行する](#hosted-zones-migrating-health-checks) でヘルスチェックを移行した場合は、新しいホストゾーンにレコードを作成するときに、新しいヘルスチェック ID を指定する必要があります。詳細については、以下の各トピックを参照してください。
+ [レコードの一覧表示](resource-record-sets-listing.md)
+ [Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)
+ [DNS フェイルオーバーの設定](dns-failover-configuring.md)
「ステップ 1 の TTL を下げる設定」と同様に、新しいゾーンでも NS TTL を下げる必要があります。
------
#### [ CLI ]
ゾーンに多数のレコードが含まれている場合は、移行するレコードをエクスポートしてファイルにし、そのファイルを編集し、編集したファイルを使用して新しいホストゾーンにレコードを作成します。以下の手順では AWS CLI コマンドを使用しますが、この目的ではサードパーティー製ツールも使用できます。
****
1. 次のコマンドを実行します。
```
aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file
```
次の点に注意してください。
+ *hosted-zone-id* には、移行するレコードを含む古いホストゾーンの ID を指定します。
+ *path-to-output-file* に、出力を保存するディレクトリのパスとファイル名を指定します。
+ `>` 文字を指定すると、指定されたファイルに出力が送信されます。
+ は、100 を超えるレコードを含むホストゾーンのページ分割 AWS CLI を自動的に処理します。詳細については、「 *AWS Command Line Interface ユーザーガイド*[」の AWS 「コマンドラインインターフェイスのページ分割オプションの使用](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html)」を参照してください。
別のプログラムメソッドを使用して AWS SDKs の 1 つなどのレコードを一覧表示する場合、結果のページあたり最大 100 個のレコードを取得できます。100 個を超えるレコードがホストゾーンに含まれている場合は、すべてのレコードをリストするために複数のリクエストを送信する必要があります。
この出力のコピーを作成します。新しいホストゾーンにレコードを作成したら、新しいホストゾーンで コマンドを実行し AWS CLI `list-resource-record-sets`、2 つの出力を比較して、すべてのレコードが作成されていることを確認することをお勧めします。
1. 移行するレコードを編集する
`change-resource-record-sets` コマンドで使用する前に、エクスポートしたファイルを編集します。テキストエディターの検索と置き換え機能を使用して、これらの変更を行うことができます。
**注記**
次の手順では、テキストエディターを使用した手動編集について説明します。上級ユーザーは、jq、Python、またはその他のスクリプト言語などのプログラムツールを使用して、これらの変換を自動化できます。
移行するレコードを含むこの手順のステップ 1 で作成したファイルのコピーを開き、次の変更を行います。
+ ファイルの上部にある ResourceRecordSets 要素を `Changes` 要素に置き換えます。
+ オプション – `Comment` 要素を追加します。
+ ホストゾーン名の NS レコードと SOA レコードに関連する行を削除します。新しいホストゾーンには既にそれらのレコードがあります。
+ レコードごとに、`Action` と `ResourceRecordSets` 要素を追加し、必要に応じて括弧 ( `{ }` ) を追加して JSON コードを有効にします。
**注記**
JSON 検証ツールを使用して、すべての中括弧と角括弧が正しい場所に配置されていることを確認します。オンライン JSON 検証ツールを検索するには、ブラウザで「JSON 検証ツール」を検索します。
+ ホストゾーンに、同じホストゾーンで他のレコードを参照するエイリアスが含まれている場合は、以下の変更を行います。
+ ホストゾーン ID を、新しいホストゾーンの ID に変更します。
**重要**
エイリアスレコードが他のリソース (ロードバランサーなど) を指している場合は、ホストゾーン ID を、ドメインのホストゾーン ID に変更しないでください。ホストゾーン ID を誤って変更した場合は、ホストゾーン ID をドメインのホストゾーン ID ではなく、リソース自体のホストゾーン ID にロールバックしてください。リソースホストゾーン ID は、リソースが作成された AWS コンソールにあります。
+ エイリアスレコードをファイルの末尾に移動します。Route 53 は、エイリアスレコードを作成する前に、エイリアスレコードが参照するレコードを作成する必要があります。
**重要**
1 つ以上のエイリアスレコードが他のエイリアスレコードを参照している場合、エイリアスターゲットであるレコードは、エイリアスレコードを参照する前にファイルに表示される必要があります。たとえば、`alias.example.com` が `alias.alias.example.com` のエイリアスターゲットである場合、`alias.example.com` がファイルの先頭に表示される必要があります。
+ トラフィックをトラフィックポリシーインスタンスにルーティングするエイリアスレコードを削除します。レコードをメモし、後で再作成できるようにします。
+ [ステップ 3: (オプション) ヘルスチェックを移行する](#hosted-zones-migrating-health-checks) でヘルスチェックを移行した場合は、新しく作成されたヘルスチェック ID に関連付けるようにレコードを変更します。
次の例に示すのは、example.com のホストゾーンのレコードの編集されたバージョンです。赤の斜体で示されているテキストが新しい部分です。
```
{
"Comment": "string",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet":{
"ResourceRecords": [
{
"Value": "192.0.2.4"
},
{
"Value": "192.0.2.5"
},
{
"Value": "192.0.2.6"
}
],
"Type": "A",
"Name": "route53documentation.com.",
"TTL": 300
}
},
{
"Action": "CREATE",
"ResourceRecordSet":{
"AliasTarget": {
"HostedZoneId": "Z3BJ6K6RIION7M",
"EvaluateTargetHealth": false,
"DNSName": "s3-website-us-west-2.amazonaws.com."
},
"Type": "A",
"Name": "www.route53documentation.com."
}
}
]
}
```
1. 大きなファイルを小さなファイルに分割する
レコードが多数ある場合や、多くの値 (多数の IP アドレスなど) を含むレコードがある場合は、ファイルをより小さなファイルに分割しなければならないことがあります。最大値は以下のとおりです。
+ 各ファイルには、最大 1,000 件のレコードを含めることができます。
+ すべての `Value` 要素での結合された値の最大の長さは 32,000 バイトです。
1. 新しいホストゾーンにレコードを作成する
次の CLI を入力します。
```
aws route53 change-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--change-batch file://path-to-file-that-contains-records
```
次の値を指定します。
+ `new-hosted-zone-id` で、新しいホストゾーンの ID を指定します。
+ `path-to-file-that-contains-records` で、前のステップで編集したディレクトリのパスとファイル名を指定します。
トラフィックポリシーインスタンスにトラフィックをルーティングするエイリアスレコードを削除している場合は、Route 53 コンソールを使用して、それらを再作成します。詳細については、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。
------
## ステップ 5: 古いホストゾーンと新しいホストゾーンのレコードを比較する
新しいホストゾーンですべてのレコードを正常に作成したことを確認するには、以下の CLI コマンドを入力して新しいホストゾーンのレコードをリストし、その出力を、古いホストゾーンからのレコードのリストと比較することをお勧めします。
```
aws route53 list-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--output json > path-to-output-file
```
次の値を指定します。
+ `new-hosted-zone-id` で、新しいホストゾーンの ID を指定します。
+ `path-to-output-file` で、出力を保存するディレクトリのパスとファイル名を指定します。ステップ 4 で使用したファイル名とは異なるファイル名を使用します。
`>` 文字を指定すると、指定されたファイルに出力が送信されます。
出力をステップ 4 の出力と比較します。NS レコードと SOA レコードの値、およびステップ 4 で行った変更 (異なるホストゾーン ID やドメイン名など) を除いて、2 つの出力は同じになるはずです。
新しいホストゾーンのレコードが古いホストゾーンのレコードに一致しない場合は、次のいずれかの操作を実行します。
+ Route 53 コンソールを使用してマイナーな修正を行います。詳細については、「[レコードの編集](resource-record-sets-editing.md)」を参照してください。
+ 新しいホストゾーンで NS レコードと SOA レコードを除くすべてのレコードを削除し、ステップ 4 の手順を繰り返します。
## ステップ 6: ドメイン登録を更新して新しいホストゾーンのネームサーバーを使用する
新しいホストゾーンでレコードの移行が終了したら、ドメイン登録のネームサーバーを変更し、新しいホストゾーンのネームサーバーを使用します。詳細については、「Amazon Route 53 を既存ドメインの DNS サービスにする」を参照してください。
ホストゾーンが使用中の場合、例えばユーザーがドメイン名を使用してウェブサイトを参照したり、ウェブアプリケーションにアクセスしたりしている場合、ウェブサイトやアプリケーションのトラフィック、E メールなど、ホストゾーンのトラフィックと可用性を引き続きモニタリングする必要があります。
+ **トラフィックが遅くなったり停止したりした場合** — ドメイン登録のネームサービスを古いホストゾーンの以前のネームサーバーに戻します。その後、何が悪かったのかを見極めます。
+ **トラフィックに影響がない場合** – 次のステップに進みます。
## ステップ 7: NS レコードの TTL をより高い値に戻す
新しいホストゾーンで、NS レコードの TTL をより一般的な値、例えば 172800 秒 (2 日) に変更します。これにより、DNS リゾルバーがドメインのネームサーバーのクエリを送信するのを頻繁に待つ必要がないため、ユーザーのレイテンシーが改善されます。
**TTL を変更するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted Zones**] (ホストゾーン) を選択します。
1. ホストゾーンの名前を選択します。
1. NS レコードを選択し、**[Record details]** (レコードの詳細) ペインで **[Edit record]** (レコードの編集) を選択します。
1. [**TTL (Seconds)**] の値を、DNS リゾルバーがドメインのネームサーバーの名前をキャッシュする秒数に変更します。172800 秒の値を推奨します。
1. **[保存]** を選択します。
## ステップ 8: DNSSEC 署名を再度有効にし、信頼チェーンを確立する (必要な場合)
2 つのステップで DNSSEC 署名を再度有効にできます。
1. Route 53 の DNSSEC 署名を有効にし、 AWS Key Management Serviceのカスタマー管理キーに基づいたキー署名キー (KSK) を Route 53 が作成するようにリクエストします。
1. Delegation Signer (DS) レコードを親ゾーンに追加して、ホストゾーンの信頼チェーンを作成します。これにより、信頼された暗号化署名を使用して DNS 応答を認証できます。
手順については、「[DNSSEC 署名を有効にし、信頼チェーンを確立します。](dns-configuring-dnssec-enable-signing.md)」を参照してください。
## ステップ 9: (オプション) 古いホストゾーンを削除する
古いホストゾーンが不要であることが明らかな場合は、オプションで削除できます。手順については、「[パブリックホストゾーンの削除](DeleteHostedZone.md)」を参照してください。
**重要**
新しいホストゾーンのネームサーバーを使用するようにドメイン登録を更新してから少なくとも 48 時間は、古いホストゾーンもこのホストゾーン内のレコードも削除しないでください。DNS リゾルバーがそのホストゾーンのレコードの使用を停止する前に古いホストゾーンを削除した場合、リゾルバーで新しいホストゾーンの使用を開始するまでドメインはインターネットで利用できないおそれがあります。
# レコードを使用する
ドメイン (例えば、example.com) のホストゾーンを作成した後、そのドメインへのトラフィックをルーティングする方法をドメインネームシステム (DNS) に指定するレコードを作成します。
例えば、DNS が以下のように動作するレコードを作成することができます。
+ example.com のインターネットトラフィックをデータセンター内のホストの IP アドレスにルーティングします。
+ そのドメイン宛のメール (ichiro@example.com) をメールサーバー (mail.example.com) にルーティングします。
+ operations.tokyo.example.com というサブドメインのトラフィックを異なるホストの IP アドレスにルーティングします。
それぞれのレコードには、ドメインまたはサブドメインの名前、レコードタイプ (例えば、タイプが MX のレコードは E メールをルーティングします)、およびレコードタイプに適用可能なその他の情報 (MX レコードの場合、1 つ以上のメールサーバーのホスト名と各サーバーの優先順位) が含まれます。各種レコードについては、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
ホストゾーン内の各レコードの名前は、ホストゾーンの名前で終わる要があります。例えば、example.com ホストゾーンには、サブドメイン www.example.com と accounting.tokyo.example.com のレコードを含めることができますが、サブドメイン www.example.ca のレコードを含めることはできません。
**注記**
複雑なルーティング設定のレコードを作成するには、Traffic Flow ビジュアルエディターを使用して、設定をトラフィックポリシーとして保存することができます。その後、トラフィックポリシーを、同じホストゾーンまたは複数のホストゾーンで 1 つ以上のドメイン名 (example.com など) またはサブドメイン名 (www.example.com など) に関連付けることができます。さらに、新しい設定が期待どおりに機能していない場合は、更新を元に戻すことができます。詳細については、「[DNS トラフィックのルーティングにトラフィックフローを使用する](traffic-flow.md)」を参照してください
Amazon Route 53 では、ホストゾーンに追加したレコードには課金されません。ホストゾーンで作成できるレコードの最大数については、「[クォータ](DNSLimitations.md)」を参照してください。
**Topics**
+ [ルーティングポリシーの選択](routing-policy.md)
+ [エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)
+ [サポートされる DNS レコードタイプ](ResourceRecordTypes.md)
+ [Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)
+ [リソースレコードセットのアクセス許可](resource-record-sets-permissions.md)
+ [Amazon Route 53 レコードの作成時または編集時に指定する値](resource-record-sets-values.md)
+ [ゾーンファイルをインポートしてレコードを作成する](resource-record-sets-creating-import.md)
+ [レコードの編集](resource-record-sets-editing.md)
+ [レコードの削除](resource-record-sets-deleting.md)
+ [レコードの一覧表示](resource-record-sets-listing.md)
# ルーティングポリシーの選択
レコードを作成するときは、Amazon Route 53 がクエリに応答する方法を決定するルーティングポリシーを選択します。
+ **シンプルルーティングポリシー** – ドメインで特定の機能を実行する単一のリソースがある場合に使用します。例えば、example.com ウェブサイトにコンテンツを提供する 1 つのウェブサーバーなどです。シンプルルーティングは、プライベートホストゾーンにレコードを作成するために使用できます。
+ **フェイルオーバールーティングポリシー** – アクティブ/パッシブフェイルオーバーを構成する場合に使用します。フェイルオーバールーティングは、プライベートホストゾーンにレコードを作成するために使用できます。
+ **位置情報ルーティングポリシー** – ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。位置情報ルーティングは、プライベートホストゾーンにレコードを作成するために使用できます。
+ **地理的近接性ルーティングポリシー** – リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用します。地理的近接性ルーティングは、プライベートホストゾーンにレコードを作成するために使用できます。
+ **レイテンシールーティングポリシー** – 複数の にリソースがあり AWS リージョン 、レイテンシーが最も高いリージョンにトラフィックをルーティングする場合に使用します。レイテンシールーティングは、プライベートホストゾーンにレコードを作成するために使用できます。
+ **IP ベースのルーティングポリシー** – トラフィックの送信元の IP アドレスがわかっており、ユーザーの位置に基づいてトラフィックをルーティングする際に使用します。
+ **複数値回答ルーティングポリシー** – ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。複数値回答ルーティングは、プライベートホストゾーンにレコードを作成するために使用できます。
+ **加重ルーティングポリシー**– 指定した比率で複数のリソースにトラフィックをルーティングする場合に使用します。加重ルーティングポリシーは、プライベートホストゾーンにレコードを作成するために使用できます。
**Topics**
+ [シンプルルーティング](routing-policy-simple.md)
+ [フェイルオーバールーティング](routing-policy-failover.md)
+ [位置情報ルーティング](routing-policy-geo.md)
+ [地理的近接性ルーティング](routing-policy-geoproximity.md)
+ [レイテンシーに基づくルーティング](routing-policy-latency.md)
+ [IP ベースルーティング](routing-policy-ipbased.md)
+ [複数値回答ルーティング](routing-policy-multivalue.md)
+ [加重ルーティング](routing-policy-weighted.md)
+ [Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法](routing-policy-edns0.md)
# シンプルルーティング
シンプルルーティングでは、Route 53 の特殊な加重ルーティングやレイテンシールーティングを使用せずに、標準の DNS レコードを設定できます。シンプルルーティングでは、通常、1 つのリソース (ウェブサイトのウェブサーバーなど) にトラフィックをルーティングします。
プライベートホストゾーンのレコードに、シンプルルーティングポリシーを使用できます。
Route 53 コンソールでシンプルルーティングポリシーを選択した場合は、複数のレコードを同じ名前と型で作成することはできませんが、同一レコードに複数の値 (複数の IP アドレスなど) を指定することができます (エイリアスレコードのシンプルなルーティングポリシーを選択した場合は、現在のホストゾーンで 1 つの AWS リソースまたは 1 つのレコードのみを指定できます）。複数の値を 1 つのレコードに指定すると、Route 53 はすべての値をランダムな順序で再帰的リゾルバーに返し、リゾルバーはこれらの値を DNS クエリを送信したクライアント (ウェブブラウザなど) に返します。次に、クライアントは 1 つの値を選択してクエリを再送信します。シンプルルーティングポリシーでは複数の IP アドレスを指定できますが、これらの IP アドレスのヘルスチェックは行われません。
シンプルルーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。
+ [シンプルなレコードに固有の値](resource-record-sets-values-basic.md)
+ [シンプルなエイリアスレコードに固有の値](resource-record-sets-values-alias.md)
+ [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
# フェイルオーバールーティング
フェイルオーバーのルーティングにより、リソースが正常な場合にリソースにトラフィックをルーティングできます。また、最初のリソースが正常でない場合は別のリソースにルーティングできます。プライマリレコードとセカンダリレコードのトラフィックのルーティング先は、ウェブサイトとして設定されている Amazon S3 バケットから、複雑なレコードのツリーまで、何でも構いません。詳細については、「[アクティブ/パッシブ (フェイルオーバー)。](dns-failover-types.md#dns-failover-types-active-passive)」を参照してください。
フェイルオーバールーティングポリシーは、プライベートホストゾーンのレコードに使用できます。
フェイルオーバールーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。
+ [フェイルオーバーレコードに固有の値](resource-record-sets-values-failover.md)
+ [フェイルオーバーエイリアスレコードに固有の値](resource-record-sets-values-failover-alias.md)
+ [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
# 位置情報ルーティング
位置情報ルーティングでは、ユーザーの地理的場所、つまり DNS クエリの送信元の場所に基づいて、トラフィックを処理するリソースを選択できます。例えば、ヨーロッパからのすべてのクエリをフランクフルトリージョンの Elastic Load Balancing ロードバランサーにルーティングしなければならない場合があります。
位置情報ルーティングを使用する場合は、コンテンツをローカライズし、ウェブサイトの一部またはすべてをユーザーの言語で表示できます。また、位置情報ルーティングを使用して、コンテンツの配布を、配布の権利がある場所だけに制限することもできます。もう 1 つの考えられる使用方法は、予測可能な管理しやすい方法で、複数のエンドポイントにわたって負荷を分散することです。この場合、各ユーザーの場所は、一貫して同じエンドポイントにルーティングされます。
地理的場所は、大陸別、国別、米国の州別に指定できます。重なり合う地理的リージョンについて別々のレコードを作成した場合は (例えば、北米用のレコードが 1 つ、カナダ用のレコードが 1 つ)、最も小さい地理的リージョンが優先されます。これにより、大陸のクエリを 1 つのリソースにルーティングし、その大陸の一部の国のクエリを異なるリソースにルーティングすることができます (各大陸の国の一覧については、「[ロケーション](resource-record-sets-values-geo.md#rrsets-values-geo-location)」を参照してください)。
位置情報は、IP アドレスを場所にマッピングすることで動作します。しかし、一部の IP アドレスは地理的場所にマッピングされません。そのため 7 つの大陸をすべて網羅した位置情報レコードセットを作成した場合でも、Amazon Route 53 が受け取る DNS クエリには場所を識別できないものがあります。デフォルトリソースレコードセットを作成して、どの場所にもマッピングされない IP アドレスからのクエリと、位置情報レコードを作成していない場所からのクエリの両方を処理することができます。デフォルトレコードを作成しない場合、Route 53 はそのような場所からのクエリに対して "応答なし" という応答を返します。
位置情報ルーティングは、パブリックホストゾーンとプライベートホストゾーンの両方のレコードに使用できます。
詳細については、「[Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法](routing-policy-edns0.md)」を参照してください。
位置情報ルーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。
+ [位置情報レコードに固有の値](resource-record-sets-values-geo.md)
+ [位置情報エイリアスレコードに固有の値](resource-record-sets-values-geo-alias.md)
+ [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
# プライベートホストゾーンのジオロケーションルーティング
プライベートホストゾーンの場合、Route 53 はクエリの送信元の VPC AWS リージョン の に基づいて DNS クエリに応答します。のリストについては AWS リージョン、*Amazon EC2 ユーザーガイド*[」の「リージョンとゾーン](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)」を参照してください。
DNS クエリがハイブリッドネットワークのオンプレミス部分から発信された場合は、VPC が配置されている AWS リージョン から発信されたと見なされます。
ヘルスチェックを含めると、次のデフォルトレコードを作成できます。
+ 地理的な場所にマップされていない IP アドレス。
+ 位置情報レコードを作成していない場所からの DNS クエリ。
DNS クエリのリージョンの位置情報レコードが正常でない場合、デフォルトのレコードが返されます (正常である場合)。
次の図の設定例では、us-east-1 AWS リージョン (バージニア) からの DNS クエリは 1.1.1.1 エンドポイントにルーティングされます。
![\[プライベートホストゾーンの位置情報レコードを示すスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/geolocation-phz.png)
# 地理的近接性ルーティング
地理的近接性ルーティングでは、Amazon Route 53 はユーザーとリソースの地理的場所に基づいてリソースのトラフィックをルーティングします。利用可能な最も近いリソースにトラフィックをルーティングします。また、必要に応じて、*「バイアス」*という値を指定することによって特定のリソースにルーティングするトラフィックの量を変更できます。バイアスは、リソースにルーティングされるトラフィックのルーティング元である地理的リージョンのサイズを拡大または縮小します。
リソースで地理的近接性ルールを作成し、各ルールに次の値のいずれかを指定します。
+ AWS リソースを使用している場合は、リソースを作成した AWS リージョン またはローカルゾーングループを指定します。
+ AWS リソース以外の を使用している場合は、リソースの緯度と経度を指定します。
AWS ローカルゾーンを使用するには、まずローカルゾーンを有効にする必要があります。詳細については、「*AWS Local Zones ユーザーガイド*」の「[Getting started with Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html)」を参照してください。
AWS リージョン とローカルゾーンの違いについては、*Amazon EC2 ユーザーガイド*[」の「リージョンとゾーン](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)」を参照してください。
Route 53 がリソースにルーティングするトラフィックの発信元の地理的リージョンのサイズを必要に応じて変更するには、バイアスに適切な値を指定します。
+ Route 53 がリソースにルーティングするトラフィックの発信元の地理的リージョンのサイズを拡大するには、バイアスに 1 から 99 までの正の整数を指定します。Route 53 は隣接するリージョンのサイズを縮小します。
+ Route 53 がリソースにルーティングするトラフィックの発信元の地理的リージョンのサイズを縮小するには、-1 から -99 までの負のバイアスを指定します。Route 53 は隣接するリージョンのサイズを拡大します。
**注記**
Route 53 の Traffic Flow コンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。
お使いのコンソールのタブを選択します。
+ [新しいコンソール](#traffic-flow-geoprox-routing-map-new)
+ [旧コンソール](#traffic-flow-geoprox-routing-map-old)
------
#### [ New console ]
次のマップは 4 AWS リージョン (1～5 の番号) を示しています。
1. 米国西部 (オレゴン)
1. 欧州 (フランクフルト)
1. アジアパシフィック (東京)
1. アフリカ (ケープタウン)
1. 中東 (バーレーン)
**注記**
マップは Traffic Flow でのみ使用できます。
![\[米国西部 (オレゴン)、欧州 (フランクフルト)、アジアパシフィック (東京)、アフリカ (ケープタウン)、中東 (バーレーン) の AWS リージョン のリソースの地理的近接性レコードがある場合の、トラフィックがどのようにルーティングされるかを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png)
次のマップでは、米国西部 (オレゴン) リージョン (マップ上の **1**) に \$125 のバイアスが追加されています。北米ではそれまでより広範囲から、さらに南米全域からもトラフィックがそのリージョンにルーティングされるようになっています。
![\[米国東部 (バージニア北部) リージョンに +25 のバイアスを追加した場合のトラフィックのルーティングを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png)
次のマップでは、米国西部 (オレゴン) リージョンのバイアスが -25 に変更されています。トラフィックは、以前よりも北米と南米の小さな部分からそのリージョンのリソースにルーティングされ、隣接するリージョン **2**、**3**、**4** のリソースにルーティングされるトラフィックが増えます。
![\[米国西部 (オレゴン) リージョンに -25 のバイアスを追加した場合のトラフィックのルーティングを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png)
------
#### [ Old console ]
次のマップは、4 AWS リージョン (番号 1～4) と、緯度と経度で指定された南アフリカのヨハネスブルグ (5) の場所を示しています。
**注記**
マップは Traffic Flow でのみ使用できます。
![\[米国西部 (オレゴン）、米国東部 (バージニア北部）、欧州 (パリ）、アジアパシフィック (東京) AWS リージョン の リソースの地理的近接性レコードがあり、南アフリカのヨハネスブルクでAWS 非リソースのレコードがある場合に、トラフィックがどのようにルーティングされるかを示す世界のマップ。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png)
次のマップでは、米国東部 (バージニア北部) リージョン (マップ上の **2**) に \$125 のバイアスが追加されています。北米ではそれまでより広範囲から、さらに南米全域からもトラフィックがそのリージョンにルーティングされるようになっています。
![\[米国東部 (バージニア北部) リージョンに +25 のバイアスを追加した場合のトラフィックのルーティングを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png)
次のマップでは、米国東部 (バージニア北部) リージョンのバイアスが -25 に変更されています。北米および南米では、より狭い範囲からのトラフィックがそのリージョンのリソースにルーティングされ、隣接するリージョン (**1**、**3**、**5**) のリソースにルーティングされるトラフィックが増えています。
![\[米国東部 (バージニア北部) リージョンに -25 のバイアスを追加した場合のトラフィックのルーティングを示す世界地図。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png)
------
リソースのバイアスを変更する効果は、以下を含む多くの要素によって決まります。
+ 所有するリソース数。
+ リソースの相互の距離。
+ 地理的地域の境界地域のユーザー数。たとえば、 AWS リージョン 米国東部 (バージニア北部) と米国西部 (オレゴン) にリソースがあり、米国テキサス州ダラス、オースティン、サンアントニオに多数のユーザーがいるとします。これらの都市はリソース間でほぼ等しいため、バイアスのわずかな変化により、リソース間のトラフィックが大きく変動する可能性があります AWS リージョン 。
予期しないトラフィックの移動によりリソースに過度の負担がかからないように、バイアスの変更は小規模にすることをお勧めします。
詳細については、「[Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法](routing-policy-edns0.md)」を参照してください。
## Amazon Route 53 がバイアスを使用してトラフィックをルーティングする方法
以下は、Amazon Route 53 がトラフィックをルーティングする方法を決定するのに使用する式です。
**Bias (バイアス)**
`Biased distance = actual distance * [1 - (bias/100)]`
バイアスの値が正の場合、Route 53 は DNS クエリのソースと地理的近接性レコードで指定したリソース ( の EC2 インスタンスなど AWS リージョン) を、実際よりも近くにあるものとして扱います。例えば、以下の地理的近接性のレコードがあるとします。
+ ウェブサーバー A のレコード、正のバイアスは 50
+ ウェブサーバー B のレコード、バイアスなし
地理的近接性のレコードで正のバイアスが 50 ある場合、Route 53 はクエリのソースとそのレコードのリソース間の距離を半分にします。次に、Route 53 はクエリのソースに近いのはどのリソースかを計算します。ウェブサーバー A はクエリのソースから 150 km の距離にあり、ウェブサーバー B はクエリのソースから 100 km の距離にあるとします。どちらのレコードにもバイアスがない場合、Route 53 はクエリをより近くにあるウェブサーバー B にルーティングします。ただし、ウェブサーバー A のレコードには正のバイアス 50 があるので、Route 53 はウェブサーバー A をクエリのソースから 75 km の距離にあるものとして扱います。その結果、Route 53 はクエリをウェブサーバー A にルーティングします。
以下に、正のバイアス 50 の計算を示します。
```
Bias = 50
Biased distance = actual distance * [1 - (bias/100)]
Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers
```
# レイテンシーに基づくルーティング
アプリケーションが複数の でホストされている場合 AWS リージョン、レイテンシーが最も低い からのリクエストを処理することで AWS リージョン 、ユーザーのパフォーマンスを向上させることができます。
**注記**
ユーザーとリソース間のレイテンシーに関するデータは、ユーザーと AWS データセンター間のトラフィックに完全に基づいています。でリソースを使用していない場合 AWS リージョン、ユーザーとリソース間の実際のレイテンシーはレイテンシ AWS ーデータと大きく異なる場合があります。これは、リソースが AWS リージョンと同じ都市にある場合でも当てはまります。
レイテンシーベースルーティングを使用するには、複数の AWS リージョンのリソース用にレイテンシーレコードを作成します。ドメインまたはサブドメイン (example.com または acme.example.com) の DNS クエリを受信した Route 53 は、レイテンシーレコードが作成された AWS リージョン を判定し、ユーザーに対するレイテンシーが最も小さいリージョンを判定し、そのリージョンのレイテンシーレコードを選択します。Route 53 は、ウェブサーバーの IP アドレスなど、選択したレコードの値で応答します。
例えば、米国西部 (オレゴン) リージョンとアジアパシフィック (シンガポール) リージョンに Elastic Load Balancing ロードバランサーがあるとします。各ロードバランサーのレイテンシーレコードを作成します。ロンドンのユーザーがブラウザにあなたのドメイン名を入力した場合は次のようになります。
1. DNS がクエリを Route 53 ネームサーバーにルーティングします。
1. Route 53 は、ロンドンとシンガポールリージョン間のレイテンシーおよびロンドンとオレゴンリージョン間のレイテンシーに基づいて、そのリクエストのデータを参照します。
1. ロンドンとオレゴンリージョン間のレイテンシーのほうが低い場合、Route 53 はオレゴンのロードバランサーの IP アドレスをクエリに対して返します。ロンドンとシンガポールリージョン間のレイテンシーの方が低い場合、Route 53 はシンガポールのロードバランサーの IP アドレスをクエリに対して返します。
インターネット上のホスト間のレイテンシーは、ネットワーク接続やルーティングに変更があると、時間の経過と共に変化する場合があります。レイテンシーベースルーティングは一定期間中に実施されたレイテンシー測定の値に基づいており、これらの測定値はレイテンシーの変化を反映しています。この週にオレゴンリージョンにルーティングされたリクエストは、次の週にシンガポールリージョンにルーティングされる場合があります。
**注記**
ブラウザまたは他のビューアが EDNS0 の edns-client-subnet 拡張をサポートする DNS リゾルバーを使用している場合、DNS リゾルバーはユーザーの IP アドレスを切り捨てたアドレスを Route 53 に送信します。レイテンシーベースルーティングを設定した場合、Route 53 はトラフィックをリソースにルーティングする際にこの値を考慮します。詳細については、「[Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法](routing-policy-edns0.md)」を参照してください。
レイテンシールーティングポリシーは、プライベートホストゾーンのレコードに使用できます。
レイテンシールーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。
+ [レイテンシーレコードに固有の値](resource-record-sets-values-latency.md)
+ [レイテンシーエイリアスレコードに固有の値](resource-record-sets-values-latency-alias.md)
+ [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
# プライベートホストゾーンのレイテンシーに基づくルーティング
プライベートホストゾーンの場合、Route 53 は、同じ にある AWS リージョンエンドポイント、またはクエリの送信元の VPC AWS リージョン の に最も近いエンドポイントを使用して DNS クエリに応答します。
**注記**
アウトバウンドエンドポイントがインバウンドエンドポイントに転送されている場合、レコードはアウトバウンドエンドポイントではなく、インバウンドエンドポイントの位置に基づいて解決されます。
ヘルスチェックを含め、クエリのオリジンに対するレイテンシーが最も低いレコードが異常である場合、レイテンシーが次に低い正常なエンドポイントが返されます。
次の図の設定例では、us-east-1 AWS リージョンまたはそれに最も近い DNS クエリが 1.1.1.1 エンドポイントにルーティングされます。us-west-2 からの DNS クエリ、またはそれに最も近いクエリは、2.2.2.2 エンドポイントにルーティングされます。
![\[プライベートホストゾーンの 2 つのレイテンシーレコードを示すスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/latency-phz.png)
# IP ベースルーティング
Amazon Route 53 の IP ベースルーティングでは、ネットワーク、アプリケーション、およびクライアントについて把握することで DNS ルーティングを微調整し、エンドユーザーのための最適な DNS ルーティングを決定できます。IP ベースのルーティングでは、ユーザー IP からエンドポイントにマッピングする形で Route 53 にデータをアップロードするので、パフォーマンスの最適化やネットワークコスト削減のための、きめ細かな制御が可能になります。
位置情報およびレイテンシーベースのルーティングは、Route 53 により収集され最新の状態に維持されているデータに基づいています。このアプローチは大多数の顧客にとってうまく機能しますが、IP ベースのルーティングを使用することで、顧客ごとに特有な情報に基づいてルーティングを最適化できる追加機能が提供されます。例えば、グローバルな動画コンテンツプロバイダーが、特定のインターネットサービスプロバイダー (ISP) からエンドユーザーをルーティングする場合があります。
以下に、IP ベースルーティングでの一般的なユースケースを示します。
+ ネットワーク伝送コストやパフォーマンスを最適化するために、特定の ISP から特定のエンドポイントにエンドユーザーをルーティングしたい場合。
+ クライアントの物理的な場所に関する情報に基づいて、位置情報ルーティングなど、既存の Route 53 ルーティングタイプにオーバーライドを追加したい場合。
**IP 範囲の管理とリソースレコードセット (RRSet) への関連付け**
IPv4 では長さ 1 ～ 24 ビットの CIDR ブロックを使用できますが、IPv6 では 1 ～ 48 ビットの長さの CIDR ブロックを使用できます。ゼロビット CIDR ブロック (0.0.0.0/0 または ::/0) を定義するには、デフォルト (「\$1」) の場所を使用します。
CIDR コレクションで指定されたものよりも長い CIDR を持つ DNS クエリの場合、Route 53 はそれを短い CIDR と一致させます。例えば、CIDR コレクションの CIDR ブロックとして 2001:0DB8::/32 を指定し、クエリが 2001:0DB8:0000:1234::/48 から発信された場合、そのクエリは一致します。一方、CIDR コレクションで 2001:0DB8:0000:1234::/48 を指定し、クエリが 2001:0DB8::/32 から発信された場合、これは一致せず、Route 53 はデフォルト (「\$1」) ロケーションのレコードで応答します。
CIDR ブロック (または IP 範囲) のセットは、CIDR ロケーション内にグループ化することができ、このグループは以下のように、CIDR コレクションと呼ばれる再利用可能なエンティティにグループ化されます。
**CIDR ブロック**
CIDR 表記での IP 範囲。例:192.0.2.0/24 または 2001:DB8::/32。
**CIDR ロケーション**
CIDR ブロックの名前付きリスト。これは例えば、example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:DB8::/32 ]、のようになります。CIDR ロケーションリスト内のブロックは、隣接している必要や、同じ範囲である必要はありません。
IPv4 ブロックと IPv6 ブロックの両方を単一のロケーションに含めることが可能で、このロケーションはそれぞれ A レコードセットと AAAA レコードセットの両方に関連付けることができます。
慣例では、このロケーション名は土地の名前であることが多いですが、任意の文字列でも問題ありません (*Company-A* など)。
**CIDR コレクション**
名前付きロケーションのコレクション。これは例えば、mycollection = [example-isp-seattle, example-isp-tokyo] のようになります。
IP ベースのルーティングリソースレコードセットはコレクション内のロケーションを参照します。同じ名前とタイプのレコードセットでは、すべてのリソースレコードセットが同じコレクションを参照する必要があります。例えば、2 つのリージョンに Web サイトを作成し、これら 2 つの異なる CIDR ロケーションから、発信元 IP アドレスに基づいて特定の Web サイトに DNS クエリを送信する場合は、それらの両方のロケーションを同じ CIDR コレクションにリストする必要があります。
IP ベースルーティングポリシーは、プライベートホストゾーンのレコードに使用できません。
シンプルルーティングポリシーを使用してレコードを作成する際に指定する値については、以下のトピックを参照してください。
+ [IP ベースレコード特有の値](resource-record-sets-values-ipbased.md)
+ [IP ベースエイリアスレコードに特有の値](resource-record-sets-values-ipbased-alias.md)
+ [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
**Topics**
+ [Creating a CIDR collection with CIDR locations and blocks (CIDR ロケーションとブロックを使用した CIDR コレクションの作成)](resource-record-sets-creating-cidr-collection.md)
+ [CIDR ロケーションと CIDR ブロックの操作](resource-record-sets-working-with-cidr-locations.md)
+ [CIDR コレクションの削除](resource-record-sets-delete-cidr-collection.md)
+ [位置情報ルーティングの IP ベースのルーティングへの移動](resource-record-sets-move-geolocation-to-cidr.md)
# Creating a CIDR collection with CIDR locations and blocks (CIDR ロケーションとブロックを使用した CIDR コレクションの作成)
使用を開始するには、CIDR コレクションを作成し、そのコレクションに CIDR ブロックとロケーションを追加します。
**Route 53 コンソールを使用して CIDR コレクションを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、**[IP-based routing]** (IP ベースルーティング)、**[CIDR collections]** (CIDR コレクション) の順に選択します。
1. **[Create CIDR collection]** (CIDR コレクションを作成) を選択します。
1. **[Create CIDR collection]** (CIDR コレクションの作成) ペインで、**[Details]** (詳細) の下にコレクションの名前を入力します。
1. **[Create collection]** (コレクションを作成) を選択し、空のコレクションを作成します。
- または -
**[CIDR ロケーションの作成]** セクションの**[CIDR ロケーション]**ボックスに CIDR ロケーションの名前を入力します。ロケーション名には、識別できる任意の文字列を使用できます。例えば **company 1**、または **Seattle** などです。これらは、実際の地理的な名前でなくても問題ありません。
**重要**
CIDR ロケーション名の最大長は 16 文字です。
**[CIDR ブロック]** ボックスに CIDR ブロックを 1 行に 1 つずつ入力します。これらの指定には、IPv4 アドレス (/0 から /24 の範囲) または IPv6 アドレス (/0 から /48 の範囲) を使用します。
1. さらにロケーションと CIDR ブロックの入力を続ける場合は、CIDR ブロックを入力した後、**[Create CIDR collection]** (CIDR コレクションを作成) または **[Add another location]** (別のロケーションを追加) を選択します。コレクションごとに複数の CIDR ロケーションを入力できます。
1. CIDR ロケーションを入力し終えたら、**[Create CIDR collection]** (CIDR コレクションを作成) を選択します。
# CIDR ロケーションと CIDR ブロックの操作
**Route 53 コンソールから CIDR ロケーションを操作するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、**[IP-based routing]** (IP ベースルーティング)、**[CIDR collections]** (CIDR コレクション) の順に選択した後、**[CIDR collections]** (CIDR コレクション) セクションで **[Collection name]** (コレクション名) リストの [CIDR collections] (CIDR コレクション) へのリンクをクリックします。
**[CIDR locations]** (CIDR ロケーション) ページでは、CIDR ロケーションの作成や削除、ロケーションとそのブロックの編集を行うことができます。
+ **[Create CIDR location]** (CIDR ロケーションを作成) を選択し、ロケーションを作成します。
+ **[Create CIDR location]** (CIDR ロケーションの作成) ペインで、ロケーションとロケーションに関連付けられた CIDR ブロックの名前をそれぞれ入力し、**[Create]** (作成) を選択します。
+ CIDR ロケーションと内部のブロックを表示するには、ロケーションペインで、名前と CIDR ブロックを表示する対象のロケーションの横にあるラジオボタンをオンにします。
このペインにある **[編集]** をクリックすると、ロケーションと CIDR ブロックの名前を更新することもできます。編集が完了したら、**[Save]** (保存) を選択します。
+ CIDR ロケーションとその中のブロックを削除するには、削除する対象のロケーションの横でラジオボタンをオンにし、次に **[Delete]** (削除) を選択します。削除されたことを確認するには、テキスト入力フィールドにロケーション名を入力した上で、もう一度、**[Delete]** (削除) を選択します。
**重要**
削除された CIDR ロケーションは元に戻せません。削除ロケーションに DNS レコードを関連付けている場合、使用しているドメインに到達できなくなる可能性があります。
# CIDR コレクションの削除
**Route 53 コンソールを使用して、CIDR コレクション、そのロケーション、およびブロックを削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで、**[IP-based routing]** (IP ベースルーティング)、**[CIDR collections]** (CIDR コレクション) の順に選択します。
1. **[CIDR collections]** (CIDR コレクション) セクションで、削除するコレクションとリンクしている名前を選択します。
1. **[CIDR locations]** (CIDR ロケーション) ページで、1 つずつ各ロケーションを 選択した上で **[Delete]** (削除) を選択し、ダイアログボックスに対象の名前を入力した後、**[Delete]** (削除) を選択します。CIDR コレクションに関連付けられている個々のロケーションを削除した後、そのコレクションを削除できるようになります。
1. 各 CIDR ロケーションの削除が完了したら、**[CIDR locations]** (CIDR ロケーション) ページで、削除するコレクションの横にあるラジオボタンをオンにした上で、**[Delete]** (削除) を選択します。
# 位置情報ルーティングの IP ベースのルーティングへの移動
地理的な位置情報ルーティング、または地理的な近接ルーティングポリシーのいずれかを使用しており、物理的な場所やネットワークトポロジにとって最適ではないエンドポイントに、特定のクライアントが一貫してルーティングされている場合には、IP ベースルーティングを使用することで、これらのクライアントのパブリック IP 範囲をより適切にターゲットできます。
次の表に、既存の位置情報ルーティングでカリフォルニア IP 範囲を微調整する場合の、地理的な位置情報設定の例を示します。
| レコードセット名 | ルーティングポリシーと送信元 | アプリケーションエンドポイントの IP アドレス |
| --- | --- | --- |
| example.com | 位置情報ルーティング (米国) | `198.51.100.1` |
| example.com | 位置情報ルーティング (欧州) | `198.51.100.2` |
カリフォルニア州からの IP 範囲を上書きして新しいアプリケーションエンドポイントに移動させるには、初めに、新しいレコードセット名を使用して位置情報ルーティングを再作成します。
| レコードセット名 | ルーティングポリシーと送信元 | アプリケーションエンドポイントの IP アドレス |
| --- | --- | --- |
| geo.example.com | 位置情報ルーティング (米国) | `198.51.100.1` |
| geo.example.com | 位置情報ルーティング (欧州) | `198.51.100.2` |
次に、新たに再作成した位置情報ルーティングレコードセットを指す、IP ベースのルーティングレコードとデフォルトレコードを作成します。
| レコードセット名 | ルーティングポリシーと送信元 | アプリケーションエンドポイントの IP アドレス |
| --- | --- | --- |
| example.com | IP ベースルーティング (デフォルト) | デフォルトに設定する、アプリケーションエンドポイント (geo.example.com) へのエイリアスレコード。例えば、`198.51.100.1`。 |
| example.com | IP ベースルーティング (カリフォルニア IP 範囲) | `198.51.100.3` |
# 複数値回答ルーティング
複数値回答ルーティングにより、Amazon Route 53 が DNS クエリに対する応答として複数の値 (ウェブサーバーの IP アドレスなど) を返すように設定できます。ほとんどすべてのレコードに複数値を指定できますが、複数値回答ルーティングは各リソースが正常かどうかも確認するため、Route 53 は正常なリソースの値のみを返します。これはロードバランサーに置き換わるものではありませんが、正常であることが確認できる複数の IP アドレスを返す機能により、DNS を使用してアベイラビリティーとロードバランシングを向上させることができます。
トラフィックを複数のリソース (ウェブサーバーなど) にほぼランダムにルーティングするには、各リソースに対し複数値回答のレコードを 1 つ作成します。また、オプションで各レコードに Route 53 ヘルスチェックを関連付けます。Route 53 は最大 8 つの正常なレコードを持つ DNS クエリに応答し、DNS リゾルバーごとに異なる回答を返します。リゾルバーが応答をキャッシュした後にウェブサーバーが使用できなくなる場合、クライアントソフトウェアは応答内の別の IP アドレスを試ことができます。
次の点に注意してください。
+ ヘルスチェックを複数値回答のレコードと関連付けている場合、Route 53 はヘルスチェックの結果が正常である場合にのみ、対応する IP アドレスを DNS クエリに返します。
+ ヘルスチェックを複数値回答レコードと関連付けない場合、Route 53 は常にレコードを正常であると見なします。
+ 8 つ以下の正常なレコードがある場合、Route 53 はすべての DNS クエリに正常なすべてのレコードを返します。
+ すべてのレコードが異常である場合、Route 53 は DNS クエリに最大 8 つの異常なレコードを返します。
複数値回答ルーティングポリシーは、プライベートホストゾーンのレコードに使用できます。
複数値回答ルーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、[複数値回答レコードに固有の値](resource-record-sets-values-multivalue.md) および [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md) を参照してください。
# 加重ルーティング
加重ルーティングにより、単一のドメイン名 (example.com) またはサブドメイン名 (acme.example.com) に複数のリソースを関連付け、各リソースにルーティングされるトラフィックの数を選択できます。これは負荷分散や新しいバージョンのソフトウェアのテストなど、さまざまな目的に有用です。
加重ルーティングを設定するには、各リソース同じ名前とタイプでレコードを作成します。各リソースに送信するトラフィックの数に対応する相対的な重みを各レコードに割り当てます。グループ内のすべてのレコードの重みの合計に対する割合として、Amazon Route 53 はレコードに割り当てられた重みに基づいてリソースにトラフィックを送信します。
![\[特定のリソースにルーティングされるトラフィック量を表す式: 特定のレコードの重み/すべてのレコードの重みの合計\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/WRR_calculation.png)
例えば、トラフィックのごく一部を 1 つのリソースに送信し、残りを別のリソースに送信する場合、重みとして 1 つ 255 を指定します。重みが 1 のリソースは、トラフィックの 1/256 (1/(1\$1255)) を、他のリソースは 255/256 (255/(1\$1255)) を取得します。重みを変更するとバランスは徐々に変更できます。リソースへのトラフィックの送信を停止するには、レコードの重みを 0 に変更します。
加重ルーティングポリシーを使用してレコードを作成するときに指定する値の詳細については、以下のトピックを参照してください。
+ [加重レコードに固有の値](resource-record-sets-values-weighted.md)
+ [加重エイリアスレコードに固有の値](resource-record-sets-values-weighted-alias.md)
+ [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
加重ルーティングポリシーは、プライベートホストゾーンのレコードに使用できます。
## ヘルスチェックと加重ルーティング
加重レコードのグループ内のすべてのレコードにヘルスチェックを追加する一方で、一部のレコードにゼロ以外の重みを付け、他のレコードの重みをゼロにした場合、ヘルスチェックは、次の例外を除いて、すべてのレコードの重みがゼロ以外の場合と同様に動作します。
+ 最初に Route 53 は、ゼロ以外の加重レコード (存在する場合) のみを対象とします。
+ 重みが 0 より大きいレコードがいずれも異常であった場合、Route 53 は、重みがゼロである加重レコードを対象にします。
次の表は、重みが 0 のレコードにヘルスチェックが含まれる場合の動作の詳細を示しています。
| | レコード 1 | レコード 2 | レコード 3 |
| --- |--- |--- |--- |
| 重み | 1 | 1 | 0 |
| ヘルスチェックが含まれていますか? | はい | はい | はい |
| |
| --- |
| ヘルスチェックステータス | 異常 | 異常 | 正常 |
| DNSクエリに回答しましたか? | いいえ | なし | はい |
| |
| --- |
| ヘルスチェックステータス | 異常 | 異常 | 異常 |
| DNS query answered? | はい | あり | なし |
| |
| --- |
| ヘルスチェックステータス | 異常 | 正常 | 異常 |
| DNSクエリに回答しましたか? | いいえ | あり | なし |
| |
| --- |
| ヘルスチェックステータス | 正常 | 正常 | 異常 |
| DNSクエリに回答しましたか? | はい | あり | なし |
| |
| --- |
| ヘルスチェックステータス | 正常 | 正常 | 正常 |
| DNSクエリに回答しましたか? | はい | あり | なし |
次の表は、重みが 0 のレコードにヘルスチェックが含まれない場合の動作の詳細を示しています。
| | レコード 1 | レコード 2 | レコード 3 |
| --- |--- |--- |--- |
| 重み | 1 | 1 | 0 |
| ヘルスチェックが含まれていますか? | はい | あり | なし |
| |
| --- |
| ヘルスチェックステータス | 正常 | 正常 | N/A |
| DNS query answered? | Yes | はい | No |
| |
| --- |
| ヘルスチェックステータス | 異常 | 異常 | 該当なし |
| DNSクエリに回答しましたか? | いいえ | なし | はい |
| |
| --- |
| ヘルスチェックステータス | 異常 | 正常 | 該当なし |
| DNS query answered? | いいえ | あり | なし |
# Amazon Route 53 が EDNS0 を使用してユーザーの場所を推定する方法
位置情報、地理的近接性、IP ベース、およびレイテンシーに関するルーティングの精度を高めるために、Amazon Route 53 は EDNS0 の edns-client-subnet 拡張をサポートしています (EDNS0 では、DNS プロトコルにオプションの拡張がいくつか追加されています)。Route 53 では、DNS リゾルバーが edns-subnet をサポートしている場合のみ、edns-subnet を使用できます。
+ ブラウザまたは他のビューアが edns-client-subnet をサポートしない DNS リゾルバーを使用している場合、Route 53 は DNS リゾルバーのソース IP アドレスを使ってユーザーのおよその場所を特定し、位置情報クエリにリゾルバーの場所の DNS レコードを返します。
+ ブラウザまたは他のビューアが edns-client-subnet をサポートする DNS リゾルバーを使用している場合、DNS リゾルバーはユーザーの IP アドレスを切り捨てたアドレスを Route 53 に送信します。Route 53 は、DNS リゾルバーのソース IP アドレスではなく切り捨てられた IP アドレスに基づいてユーザーの場所を判断します。通常は、この方がユーザーの場所をより正確に推定できます。Route 53 は、ユーザーの場所の DNS レコードを位置情報クエリに返します。
+ EDNS0 は、プライベートホストゾーンには適用されません。プライベートホストゾーンの場合、Route 53 は、プライベートホストゾーン AWS リージョン がある の VPC リゾルバーからのデータを使用して、位置情報とレイテンシーのルーティングを決定します。
edns-client-subnet の詳細については、EDNS Client Subnet RFC の「[DNS リクエストのクライアントサブネット](https://www.rfc-editor.org/rfc/rfc7871)」を参照してください。
# エイリアスレコードと非エイリアスレコードの選択
Amazon Route 53 *エイリアスレコード* で、DNS 機能に Route 53 固有の拡張機能が追加されます。エイリアスレコードを使用すると、CloudFront ディストリビューションや Amazon S3 バケットなど、選択した AWS リソースにトラフィックをルーティングできます。また、エイリアスレコードにより、ホストゾーン内のあるレコードから別のレコードにトラフィックをルーティングできます。
CNAME レコードとは異なり、DNS 名前空間の最上位ノード (*Zone Apex* とも呼ばれる) にエイリアスレコードを作成できます。例えば、example.com という DNS 名を登録する場合、Zone Apex は example.com になります。example.com に対して CNAME レコードは作成できませんが、(www.example.com のレコードタイプが CNAME でない限り) www.example.com に対してトラフィックをルーティングするエイリアスレコードを作成できます。
Route 53 がエイリアスレコードに対する DNS クエリを受信すると、Route 53 はそのリソースに適用可能な値を返します。
+ **Amazon API Gateway リージョン固有のカスタム API またはエッジ最適化 API** – Route 53 はお客様の API の 1 つ以上の IP アドレスで応答します。
+ **Amazon VPC インターフェイスエンドポイント** – Route 53 はインターフェイスエンドポイントの 1 つ以上の IP アドレスで応答します。
+ **CloudFront ディストリビューション** – Route 53 は、お客様のコンテンツを提供できる CloudFront エッジサーバーの 1 つまたは複数の IP アドレスで応答します。
+ **App Runner サービス** – Route 53 は 1 つ以上の IP アドレスで応答します。
+ **Elastic Beanstalk 環境** – Route 53 はその環境の 1 つまたは複数の IP アドレスで応答します。
+ **Elastic Load Balancing ロードバランサー** – Route 53 は、ロードバランサーの 1 つまたは複数の IP アドレスで応答します。これには、Application Load Balancer、Classic Load Balancer、Network Load Balancer が含まれます。
+ ** AWS Global Accelerator アクセラレーター** – Route 53 はアクセラレーターの IP アドレスで応答します。
+ **OpenSearch Service** – Route 53 は OpenSearch Service カスタムドメインの 1 つ以上の IP アドレスで応答します。
+ **静的ウェブサイトとして設定されている Amazon S3 バケット** – Route 53 は Amazon S3 バケットの 1 つの IP アドレスで応答します。
+ **同じホストゾーン内の同じタイプの別の Route 53 レコード** – Route 53 は、エイリアスレコードで参照されたレコードに関するクエリを受け取ったのかのように応答します (「[エイリアスレコードと CNAME レコードの比較](#resource-record-sets-choosing-alias-non-alias-comparison)」を参照してください)。
+ **AWS AppSync ドメイン名** – Route 53 は、インターフェイスエンドポイントの 1 つ以上の IP アドレスで応答します。
詳細については、「[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)」を参照してください。
エイリアスレコードを使用して AWS リソースにトラフィックをルーティングすると、Route 53 はリソースの変更を自動的に認識します。例えば、エイリアスレコード example.com が lb1-1234.us-east-2.elb.amazonaws.com の Elastic Load Balancing ロードバランサーを指し示しているとします。ロードバランサーの IP アドレスが変更された場合、Route 53 が自動的に開始され、新しい IP アドレスを使用して DNS クエリに応答します。
エイリアスレコードが AWS リソースを指す場合、有効期限 (TTL) を設定することはできません。Route 53 はリソースのデフォルト TTL を使用します。エイリアスレコードが同じホストゾーン内の別のレコードをポイントする場合、Route 53 はエイリアスレコードがポイントするレコードの TTL を使用します。Elastic Load Balancing の現在の TTL 値の詳細については、[Elastic Load Balancing ユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing)の「リクエストルーティング」で「ttl」を検索してください。
Route 53 コンソールを使用したレコード作成の詳細については、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。エイリアスレコードに指定する値の詳細については、「[Amazon Route 53 レコードの作成時または編集時に指定する値](resource-record-sets-values.md)」の該当するトピックを参照してください。
+ [シンプルなエイリアスレコードに固有の値](resource-record-sets-values-alias.md)
+ [加重エイリアスレコードに固有の値](resource-record-sets-values-weighted-alias.md)
+ [レイテンシーエイリアスレコードに固有の値](resource-record-sets-values-latency-alias.md)
+ [フェイルオーバーエイリアスレコードに固有の値](resource-record-sets-values-failover-alias.md)
+ [位置情報エイリアスレコードに固有の値](resource-record-sets-values-geo-alias.md)
+ [地理的近接性エイリアスレコードに固有の値](resource-record-sets-values-geoprox-alias.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
## エイリアスレコードと CNAME レコードの比較
エイリアスレコードは CNAME レコードに似ていますが、次のようないくつかの大きな違いがあります。次のリストでは、エイリアスレコードと CNAME レコードを比較します。
**クエリのリダイレクト先とすることができるリソース**
**エイリアスレコード**
エイリアスレコードは、以下を含むがこれらに限定されない、選択した AWS リソースにのみクエリをリダイレクトできます。
+ Amazon S3 バケット
+ CloudFront ディストリビューション
+ 同じ Route 53 ホストゾーンの他のレコード
例えば、acme.example.com という名前の Amazon S3 バケットにクエリをリダイレクトする acme.example.com という名前のエイリアスレコードを作成できます。example.com ホストゾーン内の zenith.example.com という名前のレコードにクエリをリダイレクトする acme.example.com エイリアスレコードを作成することもできます。
**CNAME レコード**
CNAME レコードは、DNS クエリを任意の DNS レコードにリダイレクトできます。例えば、acme.example.com からzenith.example.com または acme.example.org にクエリをリダイレクトする CNAME レコードを作成できます。クエリのリダイレクト先ドメインの DNS サービスとして Route 53 を使用する必要はありません。
**ドメインと同じ名前のレコードの作成 (Zone Apex にあるレコード)**
**エイリアスレコード**
ほとんどの設定では、ホストゾーン (Zone Apex) と同じ名前のエイリアスレコードを作成できます。1 つの例外は、Zone Apex (example.com など) から CNAME のタイプを持つ同じホストゾーン (zenith.example.com など) のレコードにクエリをリダイレクトする場合です。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、Zone Apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
**CNAME レコード**
ホストゾーン (Zone Apex) と同じ名前の CNAME レコードを作成することはできません。これは、ドメイン名のホストゾーン (example.com) とサブドメインのホストゾーン (zenith.example.com) の両方に当てはまります。
**DNS クエリの料金設定**
**エイリアスレコード**
Route 53 では、 AWS リソースへのエイリアスクエリには課金されません。詳細については、「[Amazon Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。
**CNAME レコード**
Route 53 では、CNAME クエリに対して課金されます。
Route 53 ホストゾーン (同じホストゾーンまたは別のホストゾーン) の別のレコードの名前にリダイレクトする CNAME レコードを作成した場合、各 DNS クエリは 2 つのクエリとして課金されます。
+ Route 53 は、リダイレクト先のレコードの名前で最初の DNS クエリに応答します。
+ 次に、DNS リゾルバーは、最初のレスポンスでレコードの別のクエリを送信して、トラフィックを誘導する場所 (ウェブサーバーの IP アドレスなど) に関する情報を取得する必要があります。
CNAME レコードが別の DNS サービスでホストされているレコードの名前にリダイレクトされる場合、Route 53 では、 1 つのクエリに対して課金されます。別の DNS サービスでは、2 番目のクエリに対して課金される場合があります。
**DNS クエリで指定されたレコードタイプ**
**エイリアスレコード**
Route 53 は、エイリアスレコードの名前 (acme.example.com など) とエイリアスレコードのタイプ (A や AAAA など) が DNS クエリの名前およびタイプと一致した場合にだけ DNS クエリに応答します。
**CNAME レコード**
CNAME レコードは、A や AAAA など、DNS クエリで指定されたレコードタイプに関係なく、レコード名の DNS クエリをリダイレクトします。
**dig クエリまたは nslookup クエリでレコードがリストされる方法**
**エイリアスレコード**
dig クエリまたは nslookup クエリへのレスポンスでは、エイリアスレコードは、レコードを作成したときに指定したレコードタイプとして表示されます (A や AAAA など)。(エイリアスレコードに指定するレコードタイプは、トラフィックをルーティングするリソースによって異なります。例えば、S3 バケットにトラフィックをルーティングするには、タイプに A を指定します)。エイリアスプロパティは、Route 53 コンソールまたは AWS CLI `list-resource-record-sets` コマンドなどのプログラムによるリクエストへのレスポンスでのみ表示されます。
**CNAME レコード**
CNAME レコードは、dig または nslookup クエリへの応答で CNAME レコードとして表示されます。
# サポートされる DNS レコードタイプ
Amazon Route 53 は、このセクションに一覧表示されている DNS レコードタイプをサポートしています。それぞれのレコードタイプの説明には、API を使用して Route 53 にアクセスするときに `Value` 要素を書式化する例も含まれています。
**注記**
ドメイン名を含むレコードタイプの場合は、完全修飾ドメイン名 (例えば、*www.example.com*) を入力します。末尾のドットはオプションです。Route 53 では、ドメイン名が完全修飾ドメイン名であると見なされます。つまり、Route 53 では、(末尾にドットのない) *www.example.com* と (末尾にドットのある) *www.example.com.* が同一と見なされます。
Route 53 は、エイリアスレコードと呼ばれる DNS 機能の拡張を提供します。CNAME レコードと同様に、エイリアスレコードを使用すると、選択した AWS リソース (CloudFront ディストリビューションや Amazon S3 バケットなど) にトラフィックをルーティングできます。エイリアスレコードと CNAME レコードの比較など、詳細については、「[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)」を参照してください。
**Topics**
+ [A レコードタイプ](#AFormat)
+ [AAAA レコードタイプ](#AAAAFormat)
+ [CAA レコードタイプ](#CAAFormat)
+ [CNAME レコードタイプ](#CNAMEFormat)
+ [DS レコードタイプ](#DSFormat)
+ [HTTPS レコードタイプ](#HTTPSFormat)
+ [MX レコードタイプ](#MXFormat)
+ [NAPTR レコードタイプ](#NAPTRFormat)
+ [NS レコードタイプ](#NSFormat)
+ [PTR レコードタイプ](#PTRFormat)
+ [SOA レコードタイプ](#SOAFormat)
+ [SPF レコードタイプ](#SPFFormat)
+ [SRV レコードタイプ](#SRVFormat)
+ [SSHFP レコードタイプ](#SSHFPFormat)
+ [SVCB レコードタイプ](#SVCBFormat)
+ [TLSA レコードタイプ](#TLSAFormat)
+ [TXT レコードタイプ](#TXTFormat)
## A レコードタイプ
A レコードと、ドット形式 10 進表記の IPv4 アドレスを使用して、ウェブサーバーなどのリソースにトラフィックをルーティングします。
**Amazon Route 53 コンソールの例**
```
192.0.2.1
```
**Route 53 API の例**
```
192.0.2.1
```
## AAAA レコードタイプ
AAAA レコードと、コロン区切り 10 進表記の IPv6 アドレスを使用して、ウェブサーバーなどのリソースにトラフィックをルーティングします。
**Amazon Route 53 コンソールの例**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
**Route 53 API の例**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
## CAA レコードタイプ
CAA レコードでは、ドメインまたはサブドメインの証明書の発行を許可する認証機関 (CA) を指定します。CAA レコードを作成すると、間違った CA がドメインの証明書を発行することを防止できます。CAA レコードは、ドメインの所有者であることを検証する要件など、認証機関によって指定されたセキュリティ要件に代わるものではありません。
CAA レコードを使用して以下を指定できます｡
+ SSL/TLS 証明書を発行できる認証機関 (CA)
+ CA がドメインまたはサブドメインの証明書を発行するときに連絡する電子メールアドレスまたは URL
CAA レコードをホストゾーンに追加する際、スペースで区切られた 3 つの設定を指定します。
`flags tag "value"`
CAA レコードのフォーマットについて、以下の点に注意してください。
+ `tag` の値として使用できる文字は A〜Z、a〜z、0〜9 のみです。
+ `value` は常に引用符「""」で囲んでください。
+ 一部の CA には `value` の追加の値が許可されるか、要求されます。名前と値のペアとして追加の値を指定し、セミコロン (;) で区切ります。次に例を示します。
`0 issue "ca.example.net; account=123456"`
+ CA がサブドメイン (例えば、www.example.com) の証明書のリクエストを受け取り、サブドメインの CAA レコードが存在しない場合、CA は CAA レコードの親ドメイン (例えば、example.com) に対して DNS クエリを送信します。親ドメインのレコードが存在し、証明書リクエストが有効な場合、CA はサブドメインの証明書を発行します。
+ CAA レコードに指定する値を判断するには、CA に相談することをお勧めします。
+ 同じ名前の CAA レコードと CNAME レコードを作成することはできません。DNS では CNAME レコードと他のタイプのレコードの両方で同じ名前を使用できないためです。
**Topics**
+ [CA にドメインまたはサブドメインの証明書の発行を許可する](#CAAFormat-issue)
+ [CA にドメインまたはサブドメインのワイルドカード証明書の発行を許可する](#CAAFormat-issue-wild)
+ [CA にドメインまたはサブドメインの証明書を発行させない](#CAAFormat-prevent-issue)
+ [CA が無効な証明書リクエストを受信した場合に CA がお客様に通知するよう要求する](#CAAFormat-contact)
+ [CA でサポートされている別の設定を使用する](#CAAFormat-custom-setting)
+ [例](#CAAFormat-examples)
### CA にドメインまたはサブドメインの証明書の発行を許可する
CA にドメインまたはサブドメインの証明書の発行を許可するには、ドメインまたはサブドメインと同じ名前でレコードを作成し、次の設定を指定します。
+ **flags** – `0`
+ **tag** – `issue`
+ **value** – ドメインまたはサブドメインの証明書の発行を許可する CA のコード
例えば、ca.example.net が example.com に証明書を発行するよう許可するとします。以下の設定を使用して example.com の CAA レコードを作成します。
```
0 issue "ca.example.net"
```
AWS Certificate Manager に証明書の発行を許可する方法については、*AWS Certificate Manager ユーザーガイド* の [CAA レコードの設定](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html)を参照してください。
### CA にドメインまたはサブドメインのワイルドカード証明書の発行を許可する
CA にドメインまたはサブドメインのワイルドカード証明書の発行を許可するには、ドメインまたはサブドメインと同じ名前でレコードを作成し、次の設定を指定します。ワイルドカード証明書はドメインまたはサブドメイン、およびそのすべてのサブドメインに適用されます。
+ **flags** – `0`
+ **tag** – `issuewild`
+ **value** – ドメインまたはサブドメイン、およびそのサブドメインの証明書の発行を許可する CA のコード
例えば、ca.example.net が example.com にワイルドカード証明書を発行するよう許可する場合、その許可は example.com とそのすべてのサブドメインに適用されます。以下の設定を使用して example.com の CAA レコードを作成します。
```
0 issuewild "ca.example.net"
```
CA にドメインまたはサブドメインのワイルドカード証明書を発行するよう許可するには、ドメインまたはサブドメインと同じ名前でレコードを作成し、次の設定を指定します。ワイルドカード証明書はドメインまたはサブドメイン、およびそのすべてのサブドメインに適用されます。
### CA にドメインまたはサブドメインの証明書を発行させない
CA にドメインまたはサブドメインの証明書を発行させないためには、ドメインまたはサブドメインと同じ名前でレコードを作成し、次の設定を指定します。
+ **flags** – `0`
+ **tag** – `issue`
+ **value** – `";"`
例えば、CA が example.com に証明書を発行しないようにしたいとします。以下の設定を使用して example.com の CAA レコードを作成します。
`0 issue ";"`
CA に example.com またはそのサブドメインに証明書を発行させないためには、以下の設定で example.com の CAA レコードを作成します。
`0 issuewild ";"`
**注記**
example.com の CAA レコードを作成し、次の両方の値を指定すると、ca.example.net の値を使用している CA は example.com の証明書を発行できます。
```
0 issue ";"
0 issue "ca.example.net"
```
### CA が無効な証明書リクエストを受信した場合に CA がお客様に通知するよう要求する
無効な証明書リクエストを受信した CA がお客様に連絡するよう設定するには、以下の設定を指定します。
+ **flags** – `0`
+ **tag** – `iodef`
+ **value** – CA が無効な証明書のリクエストを受信した場合に、CA からの通知を希望する URL または E メールアドレス。該当する形式を使用します。
`"mailto:email-address"`
`"http://URL"`
`"https://URL"`
例えば、証明書に対する無効なリクエストを受信した CA が admin@example.com に E メールを送信するには、以下の設定を使用して CAA レコードを作成します。
```
0 iodef "mailto:admin@example.com"
```
### CA でサポートされている別の設定を使用する
CA が CAA レコード用に RFC で定義されていない機能をサポートしている場合、以下の設定を指定します。
+ **flags** – 128 (この値に設定すると、CA で指定された機能がサポートされていない場合に、CA による証明書の発行を防ぐことができます)
+ **tag** – CA に使用を許可するタグ
+ **value** – タグの値に対応する値
例えば、CA が無効な証明書リクエストを受け取った場合に、テキストメッセージを送信する機能を CA がサポートしているとします。(当社では、このオプションをサポートする CA は認識されていません。) レコードの設定は次のようになります。
```
128 exampletag "15555551212"
```
### 例
**Route 53 コンソールの例**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
**Route 53 API の例**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
## CNAME レコードタイプ
CNAME レコードは、acme.example.com などの現在のレコードの名前に対する DNS クエリを、別のドメイン (example.com、example.net など) またはサブドメイン (acme.example.com、zenith.example.org など) にマッピングします。
**重要**
DNS プロトコルでは、Zone Apex とも呼ばれる、DNS 名前空間の最上位ノードに対して CNAME レコードを作成することができません。例えば、example.com という DNS 名を登録する場合、Zone Apex は example.com になります。example.com に対して CNAME レコードを作成することはできませんが、www.example.com、newproduct.example.com などに対しては CNAME レコードを作成できます。
さらに、サブドメインに対して CNAME レコードを作成する場合、そのサブドメインの他のレコードを作成できません。例えば、www.example.com の CNAME を作成する場合、**Name** フィールドの値が www.example.com の他のレコードは作成できません。
Amazon Route 53 では、エイリアスレコードもサポートされています。これにより、CloudFront ディストリビューションや Amazon S3 バケットなどの選択された AWS リソースにクエリをルーティングできます。エイリアスはいろいろな意味で CNAME レコードタイプと似ていますが、エイリアスは Zone Apex に対して作成することができます。詳細については、「[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)」を参照してください。
**Route 53 コンソールの例**
```
hostname.example.com
```
**Route 53 API の例**
```
hostname.example.com
```
## DS レコードタイプ
Delegation Signer (DS) レコードは、委任されたサブドメインゾーンのゾーンキーを参照します。DNSSEC 署名を設定するときに、信頼のチェーンを確立するときに DS レコードを作成することがあります。Route 53 の DNSSEC の設定の詳細については、「[Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)」を参照してください。
最初の 3 つの値は、キータグ、アルゴリズム、ダイジェストタイプを表す 10 進値です。4 番目の値は、ゾーンキーのダイジェストです。DS レコードの形式については、「[RFC 4034](https://www.ietf.org/rfc/rfc4034.txt)」を参照してください。
**Route 53 コンソールの例**
```
123 4 5 1234567890abcdef1234567890absdef
```
**Route 53 API の例**
```
123 4 5 1234567890abcdef1234567890absdef
```
## HTTPS レコードタイプ
HTTPS リソースレコードは、拡張設定情報を提供するサービスバインディング (SVCB) DNS レコードの形式であり、クライアントは HTTP プロトコルを使用してサービスに簡単かつ安全に接続できます。設定情報は、複数の DNS クエリを必要とするのではなく、1 つの DNS クエリで接続を許可するパラメータで提供されます。
HTTPS リソースレコードの形式は次のとおりです。
`SvcPriority TargetName SvcParams(optional)`
以下のパラメータについては、[RFC 9460 セクション 9.1](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1) で説明されています。
**SvcPriority**
優先度を表す整数。優先度 0 はエイリアスモードを意味し、通常は Zone Apex でのエイリアスを目的としています。この値は Route 53 の整数 0～32767 で、そのうち 1～32767 はサービスモードレコードです。優先度を下げ、選好度を上げます。
**targetName**
エイリアスターゲット (エイリアスモードの場合) または代替エンドポイント (ServiceMode の場合) のドメイン名。
**SvcParams (オプション)**
空白で区切られたリスト。各パラメータは Key=Value ペアまたはスタンドアロンキーで構成されます。複数の値がある場合は、カンマ区切りのリストとして表示されます。定義された SvcParams を次に示します。
+ `1:alpn` – Application Layer Protocol Negotiation Protocol ID。デフォルトは HTTP/1.1、`h2` は HTTP/2 over TLS、`h3` は HTTP/3 (HTTP over QUIC protocol) です。
+ `2:no-default-alpn` – デフォルトはサポートされていないため、`alpn` パラメータを指定する必要があります。
+ `3:port` – 代替エンドポイント、またはサービスに到達できるポート。
+ `4:ipv4hint` – IPv4 アドレスのヒント。
+ `5:ech` – 暗号化されたクライアント Hello。
+ `6:ipv6hint` – IPv6 アドレスのヒント。
+ `7:dohpath` – DNS over HTTPS テンプレート
+ `8:ohttp` - サービスは、不明瞭な HTTP ターゲットを操作します。
**エイリアスモードの Amazon Route 53 コンソールの例**
```
0 example.com
```
**サービスモードの Amazon Route 53 コンソールの例**
```
16 example.com alpn="h2,h3" port=808
```
**エイリアスモードの Amazon Route 53 API の例**
```
0 example.com
```
**サービスモードの Amazon Route 53 API の例**
```
16 example.com alpn="h2,h3" port=808
```
詳細については、[「RFC 9460, Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)](https://datatracker.ietf.org/doc/html/rfc9460)」を参照してください。
**注記**
Route 53 は任意の unknown-key プレゼンテーション形式 `keyNNNNN` をサポートしていません
## MX レコードタイプ
MX レコードは、メールサーバーの名前を指定します。複数のメールサーバーがある場合は、優先順位を指定します。MX レコードの各値には、優先順位とドメイン名という 2 つの値が含まれます。
**優先度**
E メールサーバーの優先度を表す整数。サーバーを 1 つのみ指定する場合、優先順位は 0 ～ 65535 の任意の整数を指定できます。複数のサーバーを指定する場合、指定した優先度の値は、E メールをルーティングする順序の E メールサーバーを示します。優先順位の値が最も小さいサーバーが優先されます。例えば、E メールサーバーを 2 台所有しており、優先度に 10 および 20 と指定した場合は、利用できない場合を除き、E メールは常に優先度 10 でサーバーに送られます。10 および 10 を指定すると、メールは 2 つのサーバーにほぼ均等的にルーティングされます。
**ドメイン名**
E メールサーバーのドメイン名。A レコードまたは AAAA レコードの名前 (mail.example.com など) を指定します。[RFC 2181, Clarifications to the DNS Specification](https://tools.ietf.org/html/rfc2181) のセクション 10.3 では、ドメイン名の値に CNAME レコードの名前を指定することを禁止しています。(RFC における「エイリアス」は CNAME レコードを意味します。Route 53 のエイリアスレコードではありません)。
**Amazon Route 53 コンソールの例**
```
10 mail.example.com
```
**Route 53 API の例**
```
10 mail.example.com
```
## NAPTR レコードタイプ
名前付け権限ポインタ (NAPTR) は、動的委任発見システム (DDDS) アプリケーションで、1 つの値を別の値に変換または置き換えるために使用されるレコードのタイプです。例えば、1 つの一般的な用途は、電話番号を SIP URI に変換する場合です。
NAPTR レコードの `Value` 要素は、6 つのスペース区切りの値で構成されます。
**Order**
複数のレコードを指定した場合、DDDS アプリケーションがレコードを評価する順序。有効な値は 0 ～ 65535 です。
**Preference**
[**Order**] が同じ複数のレコードを指定した場合、それらのレコードが評価される順序の基本設定。例えば、[**Order**] が 1 のレコードが 2 つある場合、DDDS アプリケーションはまず [**Preference**] が小さいレコードを評価します。有効な値は 0 ～ 65535 です。
**Flags**
DDDS アプリケーションに固有の設定。[RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) で現在定義されている値は、大文字および小文字の **"A"**、**"P"**、**"S"**、**"U"** と空の文字列 **""** です。[**Flags**] は引用符で囲んでください。
**サービス**
DDDS アプリケーションに固有の設定。[**Service**] は引用符で囲んでください。
詳細については、該当する RFC を参照してください。
+ **URI DDDS アプリケーション** – [https://tools.ietf.org/html/rfc3404\$1section-4.4](https://tools.ietf.org/html/rfc3404#section-4.4)
+ **S-NAPTR DDDS アプリケーション** – [https://tools.ietf.org/html/rfc3958\$1section-6.5](https://tools.ietf.org/html/rfc3958#section-6.5)
+ **U-NAPTR DDDS アプリケーション** – [https://tools.ietf.org/html/rfc4848\$1section-4.5](https://tools.ietf.org/html/rfc4848#section-4.5)
**Regexp**
DDDS アプリケーションが入力値を出力値に変換するために使用する正規表現。例えば、IP 電話システムが正規表現を使用して、ユーザーが入力した電話番号を SIP URI に変換することができます。[**Regexp**] は引用符で囲んでください。[**Regexp**] の値と [**Replacement**] のいずれかを指定します。両方は指定しないでください。
正規表現には、次のいずれかの出力可能な ASCII 文字を含めることができます。
+ a～z
+ 0-9
+ - (ハイフン)
+ (スペース)
+ \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 .
+ " (引用符)。文字列にリテラル引用符を含めるには、文字列の前に \$1 文字を置きます (\$1")。
+ \$1 (バックスラッシュ)。文字列にバックスラッシュを含めるには、文字列の前に \$1 を置きます (\$1\$1)。
他のすべての値 (国際化ドメインなど) を 8 進数形式で指定します。
[**Regexp**] の構文については、「[RFC 3402, section 3.2, Substitution Expression Syntax](https://tools.ietf.org/html/rfc3402#section-3.2)」を参照してください。
**置換**
DDDS アプリケーションが DNS クエリを送信する次のドメイン名の完全修飾ドメイン名 (FQDN)。DDDS アプリケーションは、入力値を [**Replacement**] に指定した値 (ある場合) に置き換えます。[**Regexp**] の値と [**Replacement**] のいずれかを指定します。両方は指定しないでください。**[Regexp]** の値を指定する場合は、**[代替]** にドット (**.**) を指定します。
ドメイン名には、a ～ z、0 ～ 9、- (ハイフン) を含めることができます。
DDDS アプリケーションと NAPTR レコードについては、次の RFC を参照してください。
+ [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt)
+ [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt)
+ [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt)
+ [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt)
**Amazon Route 53 コンソールの例**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
**Route 53 API の例**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
## NS レコードタイプ
NS レコードはホストゾーンのネームサーバーを識別します。次の点に注意してください。
+ NS レコードの最も一般的な使用方法は、インターネットトラフィックがドメインにルーティングされる方法を制御することです。ホストゾーンのレコードを使用してドメインのトラフィックをルーティングするには、デフォルトの NS レコードの 4 つのネームサーバーを使用するようにドメイン登録設定を更新します (これは、ホストゾーンと同じ名前を持つ NS レコードです)。
+ サブドメイン (acme.example.com) 用に別のホストゾーンを作成し、そのホストゾーンを使用して、サブドメインとそのサブドメイン (subdomain.acme.example.com) のインターネットトラフィックをルーティングできます。この設定は、ホストゾーンでルートドメイン (example.com) 用の別の NS レコードを作成することにより指定します (「ホストゾーンへのサブドメインの責任の委任」と呼ばれます)。詳細については、「[サブドメインのトラフィックのルーティング](dns-routing-traffic-for-subdomains.md)」を参照してください。
+ また、NS レコードを使用して、ホワイトラベルネームサーバーを設定することもできます。詳細については、「[ホワイトラベルネームサーバーの設定](white-label-name-servers.md)」を参照してください。
+ NS レコードのもう 1 つの用途は、サブドメインの権限をオンプレミスリゾルバーに委任する委任ルールを作成するときのプライベートホストゾーン用です。委任ルールを作成する前に、この NS レコードを作成する必要があります。詳細については、「[Resolver エンドポイントが VPCs からネットワークに DNS クエリを転送する方法](resolver-overview-forward-vpc-to-network.md)」を参照してください。
NS レコードの詳細については、「[Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード](SOA-NSrecords.md)」を参照してください。
**Amazon Route 53 コンソールの例**
```
ns-1.example.com
```
**Route 53 API の例**
```
ns-1.example.com
```
## PTR レコードタイプ
PTR レコードは、IP アドレスを対応するドメイン名にマッピングします。
**Amazon Route 53 コンソールの例**
```
hostname.example.com
```
**Route 53 API の例**
```
hostname.example.com
```
## SOA レコードタイプ
Start of Authority (SOA) のレコードは、ドメインおよび対応する Amazon Route 53 のホストゾーンに関する情報を提供します。SOA レコードのフィールドについては、「[Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード](SOA-NSrecords.md)」を参照してください。
**Route 53 コンソールの例**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
**Route 53 API の例**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
## SPF レコードタイプ
以前は、メールの送信者の身元を確認するために SPF レコードが使用されていました。しかし、レコードタイプが SPF のレコードを作成することはもうお勧めできません。RFC 7208「*Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1*」が更新され、「...[RFC4408] で定義されたその存在と仕組みが相互運用性の問題を起こしています。したがって、その使用は SPF バージョン 1 ではもはや適切ではない。実装では使用してはならない」とされています。RFC 7208 のセクション 14.1「[The SPF DNS Record Type](http://tools.ietf.org/html/rfc7208#section-14.1)」を参照してください。
SPF レコードの代わりに、該当する値を含む TXT レコードを作成することをお勧めします。有効な値については、Wikipedia の記事「[センダーポリシーフレームワーク](https://en.wikipedia.org/wiki/Sender_Policy_Framework)」を参照してください。
**Amazon Route 53 コンソールの例**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Route 53 API の例**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
## SRV レコードタイプ
SRV レコードの `Value` 要素は 4 つのスペース区切りの値で構成されます。最初の 3 つの値は、優先順位、重み、およびポートをそれぞれ表す 10 進値です。4 番目の値は、ドメイン名です。SRV レコードは、メールや通信用のサービスなどのサービスにアクセスするために使用されます。SRV レコードの形式については、接続先のサービスのマニュアルを参照してください。
**Amazon Route 53 コンソールの例**
```
10 5 80 hostname.example.com
```
**Route 53 API の例**
```
10 5 80 hostname.example.com
```
## SSHFP レコードタイプ
Secure Shell フィンガープリントレコード (SSHFP) は、ドメイン名に関連付けられた SSH キーを識別します。SSHFP レコードは、信頼チェーンを確立するために DNSSEC で保護する必要があります。DNSSEC の詳細については、「[Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)」を参照してください。
SSHFP リソースレコードの形式は次のとおりです。
`[Key Algorithm] [Hash Type] Fingerprint`
以下のパラメータは [RFC 4255](https://datatracker.ietf.org/doc/html/rfc4255) で定義されています。
**キーアルゴリズム**
アルゴリズムタイプ:
+ `0` – 予約済みで、使用されていません。
+ `1: RSA` – Rivest–Shamir–Adleman アルゴリズムは、最初のパブリックキー暗号システムの 1 つであり、安全なデータ転送に引き続き使用されています。
+ `2: DSA` – デジタル署名アルゴリズムは、デジタル署名の連邦情報処理標準です。DSA は、モジュール式指数と離散対数の数学モデルに基づいています。
+ `3: ECDSA` – 楕円曲線デジタル署名アルゴリズムは、楕円曲線暗号を使用する DSA のバリアントです。
+ `4: Ed25519` – Ed25519 アルゴリズムは、SHA-512 (SHA-2) と Curve25519 を使用する EdDSA 署名スキームです。
+ `6: Ed448` – Ed448 は、SHAKE256 と Curve448 を使用する EdDSA 署名スキームです。
**ハッシュタイプ**
パブリックキーハッシュの作成に使用されるアルゴリズム:
+ `0` – 予約済みで、使用されていません。
+ `1: SHA-1`
+ `2: SHA-256`
**Fingerprint**
ハッシュの 16 進数表現。
**Amazon Route 53 コンソールの例**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
**Route 53 API の例**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
詳細については、[「RFC 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints」](https://datatracker.ietf.org/doc/html/rfc4255)を参照してください。
## SVCB レコードタイプ
SVCB レコードを使用して、サービスエンドポイントにアクセスするための設定情報を配信します。SVCB は汎用 DNS レコードであり、さまざまなアプリケーションプロトコルのパラメータをネゴシエートするために使用できます。
SVCB リソースレコードの形式は次のとおりです。
`SvcPriority TargetName SvcParams(optional)`
以下のパラメータについては、[RFC 9460 セクション 2.3](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3) で説明されています。
**SvcPriority**
優先度を表す整数。優先度 0 はエイリアスモードを意味し、通常は Zone Apex でのエイリアスを目的としています。優先度を下げ、選好度を上げます。
**targetName**
エイリアスターゲット (エイリアスモードの場合) または代替エンドポイント (ServiceMode の場合) のドメイン名。
**SvcParams (オプション)**
空白で区切られたリスト。各パラメータは Key=Value ペアまたはスタンドアロンキーで構成されます。複数の値がある場合は、カンマ区切りのリストとして表示されます。この値は Route 53 の整数 0～32767 で、そのうち 1～32767 はサービスモードレコードです。定義された SvcParams を次に示します。
+ `1:alpn` – Application Layer Protocol Negotiation Protocol ID。デフォルトは HTTP/1.1、`h2` は HTTP/2 over TLS、`h3` は HTTP/3 (HTTP over QUIC protocol) です。
+ `2:no-default-alpn` – デフォルトはサポートされていないため、`alpn` パラメータを指定する必要があります。
+ `3:port` – サービスに到達できる代替エンドポイントのポート。
+ `4:ipv4hint` – IPv4 アドレスのヒント。
+ `5:ech` – 暗号化されたクライアント Hello。
+ `6:ipv6hint` – IPv6 アドレスのヒント。
+ `7:dohpath` – DNS over HTTPS テンプレート
+ `8:ohttp` - サービスは、不明瞭な HTTP ターゲットを操作します。
**エイリアスモードの Amazon Route 53 コンソールの例**
```
0 example.com
```
**サービスモードの Amazon Route 53 コンソールの例**
```
16 example.com alpn="h2,h3" port=808
```
**エイリアスモードの Amazon Route 53 API の例**
```
0 example.com
```
**サービスモードの Amazon Route 53 API の例**
```
16 example.com alpn="h2,h3" port=808
```
詳細については、[「RFC 9460, Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)](https://datatracker.ietf.org/doc/html/rfc9460)」を参照してください。
**注記**
Route 53 は任意の unknown-key プレゼンテーション形式 `keyNNNNN` をサポートしていません
## TLSA レコードタイプ
TLSA レコードを使用して、名前付きエンティティの DNS ベースの認証 (DANE) を使用します。TLSA レコードは証明書/パブリックキーを Transport Layer Security (TLS) エンドポイントに関連付け、クライアントは DNSSEC で署名された TLSA レコードを使用して証明書/パブリックキーを検証できます。
TLSA レコードは、ドメインで DNSSEC が有効になっている場合にのみ信頼できます。DNSSEC の詳細については、「[Amazon Route 53 での DNSSEC 署名の設定](dns-configuring-dnssec.md)」を参照してください。
TLSA リソースレコードの形式は次のとおりです。
`[Certificate usage] Selector [Matching type] [Certificate association data]`
以下のパラメータは、[RFC 6698 のセクション 3](https://datatracker.ietf.org/doc/html/rfc6698#section-3) で指定されています。
**証明書の使用**
TLS ハンドシェイクで提示された証明書と一致させるために使用される、提供された関連付けを指定します。
+ 0: CA 制約 – 証明書またはパブリックキーは、TLS のサーバーによって提供されるエンドエンティティ証明書のパブリックキーインフラストラクチャ (PKIX) 証明書パスのいずれかにある必要があります。この制約により、指定されたサービスの証明書を発行するために使用できる CA が制限されます。
+ 1: サービス証明書の制約 – TLS でサーバーから提供されたエンドエンティティ証明書と一致する必要があるエンドエンティティ証明書 (またはパブリックキー) を指定します。この証明書は、ホスト上の指定されたサービスで使用できるエンドエンティティ証明書を制限します。
+ 2: 信頼アンカーアサーション – TLS でサーバーから提供されたエンドエンティティ証明書を検証するときに「トラストアンカー」として使用する必要がある証明書 (またはパブリックキー) を指定します。ドメイン管理者がトラストアンカーを指定できるようにします。
+ 3: ドメイン発行の証明書 – TLS でサーバーから提供されたエンドエンティティ証明書と一致する必要がある証明書 (またはパブリックキー) を指定します。この証明書により、ドメイン管理者は、サードパーティー CA を関与させることなくドメインの証明書を発行できます。この証明書は PKIX 検証に合格する必要はありません。
**Selector**
ハンドシェイクでサーバーによって提示された証明書のどの部分が関連付け値と照合されるかを指定します。
+ 0: 証明書全体が一致する必要があります。
+ 1: サブジェクトパブリックキー、または DER エンコードされたバイナリ構造が一致している必要があります。
**マッチングタイプ**
証明書一致の表示 (セレクタフィールドによって決定) を指定します。
+ 0: コンテンツの完全一致。
+ 1: SHA-256 ハッシュ。
+ 2: SHA-512 ハッシュ。
**証明書の関連付けデータ**
他のフィールドの設定に基づいて照合されるデータ。
**Amazon Route 53 コンソールの例**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
**Route 53 API の例**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
詳細については、[「RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA](https://datatracker.ietf.org/doc/html/rfc6698)」を参照してください。
## TXT レコードタイプ
TXT レコードには、二重引用符 (`"`) で囲まれた 1 つ以上の文字列が含まれます。シンプル[ルーティングポリシー](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)を使用する際には、同じ TXT レコードにあるドメインのすべての値 (example.com) またはサブドメイン (www.example.com) を含めます。
**Topics**
+ [TXT レコード値の入力](#TXTformat-limits)
+ [TXT レコード値の特殊文字](#TXTformat-special-characters)
+ [TXT レコード値の大文字と小文字](#TXTformat-case)
+ [例](#TXTformat-examples)
### TXT レコード値の入力
1 つの文字列には、最大 255 文字を含めることができます。これには以下のものが含まれます。
+ a～z
+ A～Z
+ 0-9
+ スペース
+ - (ハイフン)
+ \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 .
255 文字を超える値を入力する必要がある場合、値を 255 文字以下の文字列に分割し、各文字列を二重引用符 (`"`) で囲みます。コンソールで、同じ行にすべての文字列を一覧表示します。
```
"String 1" "String 2" "String 3"
```
API の場合、すべての文字列を同じ `Value` 要素に含めます。
```
"String 1" "String 2" "String 3"
```
TXT レコード内の値の最大長は 4,000 文字です。
複数の TXT 値を入力するには、値を 1 行に 1 つ入力します。
### TXT レコード値の特殊文字
TXT レコードが以下の文字を含む場合は、エスケープコードを使って、`\`*3 桁の 8 進コード*という形式で文字を指定する必要があります。
+ 8 進数で文字 000～040 (10 進数で 0～32、16 進数で 0x20～0x00)
+ 8 進数で文字 177～377 (10 進数で 127～255、16 進数で 0xFF～0x7F)
例えば、TXT レコードの値が `"exämple.com"` の場合、`"ex\344mple.com"` と指定します。
ASCII 文字および 8 進コードの間のマッピングについては、インターネットで「ASCII 8 進コード」を検索してください。[ASCII Code - The extended ASCII table](https://www.ascii-code.com/) に役立つ情報があります。
文字列に引用符 (`"`) を含めるには、引用符の前にバックスラッシュ (`\`) を配置します (`\"`)。
### TXT レコード値の大文字と小文字
ケースが保持され、`"Ab"` と `"aB"` は異なる値となります。
### 例
**Amazon Route 53 コンソールの例**
個別の行にそれぞれの値を入力します。
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Route 53 API の例**
個別の `Value` 要素にそれぞれの値を入力します。
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
# Amazon Route 53 コンソールを使用したレコードの作成
以下の手順では、Amazon Route 53 コンソールを使用してレコードを作成する方法について説明します。Route 53 API を使用してレコードを作成する方法については、「*Amazon Route 53 API リファレンス*」の「[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)」を参照してください。
**注記**
複雑なルーティング設定のレコードを作成するには、Traffic Flow ビジュアルエディターを使用して、設定をトラフィックポリシーとして保存することができます。その後、トラフィックポリシーを、同じホストゾーンまたは複数のホストゾーンで 1 つ以上のドメイン名 (example.com など) またはサブドメイン名 (www.example.com など) に関連付けることができます。さらに、新しい設定が期待どおりに機能していない場合は、更新を元に戻すことができます。詳細については、「[DNS トラフィックのルーティングにトラフィックフローを使用する](traffic-flow.md)」を参照してください
**Route 53 コンソールを使用してレコードを作成するには**
1. エイリアスレコードを作成しない場合は、ステップ 2 に進みます。
また、Elastic Load Balancing ロードバランサーまたは別の Route 53 レコード以外の AWS リソースに DNS トラフィックをルーティングするエイリアスレコードを作成する場合は、ステップ 2 に進みます。
Elastic Load Balancing ロードバランサーにトラフィックをルーティングするエイリアスレコードを作成する場合、および、複数の異なるアカウントを使用してホストゾーンとロードバランサーを作成した場合は、手順「[Elastic Load Balancing ロードバランサーの DNS 名を取得する](#resource-record-sets-elb-dns-name-procedure)」を実行してロードバランサーの DNS 名を取得します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. ドメインにすでにホストゾーンがある場合は、ステップ 5 に進みます。それ以外の場合は、該当する手順を実行してホストゾーンを作成します。
+ インターネットトラフィックを Amazon S3 バケットや Amazon EC2 インスタンスなどのリソースにルーティングするには、「[パブリックホストゾーンの作成](CreatingHostedZone.md)」を参照してください。
+ VPC でトラフィックをルーティングするには、「[プライベートホストゾーンの作成](hosted-zone-private-creating.md)」を参照してください。
1. [**ホストゾーン**] ページで、レコードを作成するホストゾーンの名前を選択します。
1. [**Create record (レコードを作成)**] を選択します。
1. 適切なルーティングポリシーと値を選択し、定義します。詳細については、作成するレコードの種類に関するトピックを参照してください。
+ [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
+ [シンプルなレコードに固有の値](resource-record-sets-values-basic.md)
+ [シンプルなエイリアスレコードに固有の値](resource-record-sets-values-alias.md)
+ [フェイルオーバーレコードに固有の値](resource-record-sets-values-failover.md)
+ [フェイルオーバーエイリアスレコードに固有の値](resource-record-sets-values-failover-alias.md)
+ [位置情報レコードに固有の値](resource-record-sets-values-geo.md)
+ [位置情報エイリアスレコードに固有の値](resource-record-sets-values-geo-alias.md)
+ [地理的近接性レコードに固有の値](resource-record-sets-values-geoprox.md)
+ [地理的近接性エイリアスレコードに固有の値](resource-record-sets-values-geoprox-alias.md)
+ [レイテンシーレコードに固有の値](resource-record-sets-values-latency.md)
+ [レイテンシーエイリアスレコードに固有の値](resource-record-sets-values-latency-alias.md)
+ [IP ベースレコード特有の値](resource-record-sets-values-ipbased.md)
+ [IP ベースエイリアスレコードに特有の値](resource-record-sets-values-ipbased-alias.md)
+ [複数値回答レコードに固有の値](resource-record-sets-values-multivalue.md)
+ [加重レコードに固有の値](resource-record-sets-values-weighted.md)
+ [加重エイリアスレコードに固有の値](resource-record-sets-values-weighted-alias.md)
1. **[レコードを作成]** を選択します。
**注記**
新しいレコードが Route 53 DNS サーバーに伝達されるまでにしばらく時間がかかります。現在、変更が反映されたことを確認するには、[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API アクションを使用する方法しかありません。通常、変更は 60 秒以内にすべての Route 53 ネームサーバーに伝播します。
1. レコードを複数作成する場合は、ステップ 7～8 を繰り返します。
**Elastic Load Balancing ロードバランサーの DNS 名を取得する**
1. エイリアスレコードを作成する Classic、Application、または Network Load Balancer の作成に使用した AWS アカウント AWS マネジメントコンソール を使用して にサインインします。
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**Load Balancers**] を選択します。
1. ロードバランサーのリストで、エイリアスレコードを作成するロードバランサーを選択します。
1. [**Description**] タブで、[**DNS name**] の値を取得します。
1. 他の Elastic Load Balancing ロードバランサーに対してもエイリアスレコードを作成する場合は、ステップ 4 と 5 を繰り返します。
1. からサインアウトします AWS マネジメントコンソール。
1. Route 53 ホストゾーンの作成に使用した AWS アカウントを使用して、 に AWS マネジメントコンソール 再度サインインします。
1. 手順「[Amazon Route 53 コンソールを使用したレコードの作成](#resource-record-sets-creating)」のステップ 3 に戻ります。
# リソースレコードセットのアクセス許可
リソースレコードセットのアクセス許可では、Identity and Access Management (IAM) ポリシー条件を使用して、Route 53 コンソールでのアクションや、[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) API の使用についてのきめ細かいアクセス許可を設定できます。
リソースレコードセットは、複数のリソースレコードとして定義されます。これらの名前とタイプは同じです (クラスも同じですが、ほとんどの場合、クラスは常に IN またはインターネットです) が、含まれているデータは異なります。例えば、位置情報ルーティングを選択した場合、同じドメインの異なるエンドポイントを指す複数の A レコードまたは AAAA レコードを設定できます。これらの A レコードまたは AAAA レコードはすべて組み合わされて 1 つのリソースレコードセットを形成します。DNS 用語の詳細については、「[RFC 7719](https://datatracker.ietf.org/doc/html/rfc7719)」を参照してください。
IAM ポリシー条件 、`route53:ChangeResourceRecordSetsNormalizedRecordNames`、`route53:ChangeResourceRecordSetsRecordTypes`および を使用すると`route53:ChangeResourceRecordSetsActions`、他の AWS アカウントの AWS 他のユーザーにきめ細かな管理権限を付与できます。これにより、あるユーザーに、次のアクセス許可を付与できます。
+ 単一リソースレコードセット。
+ 特定の DNS レコードタイプのすべてのリソースレコードセット。
+ 名前に特定の文字列が含まれるリソースレコードセット。
+ [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) API、または Route 53 コンソール使用時の `CREATE | UPSERT | DELETE ` アクションのいずれか、またはすべての実行。
Route 53 のポリシー条件のいずれかを組み合わせたアクセス許可を作成することもできます。例えば、あるユーザーに marketing-example.com の A レコードデータを変更するアクセス許可を付与するが、そのユーザーにはレコードの削除を許可しないことができます。
リソースレコードセットのアクセス許可の詳細と使用方法の例については、「[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions-route53.md)」を参照してください。
AWS ユーザーを認証する方法については、[アイデンティティを使用した認証](security-iam.md#security_iam_authentication)「」を参照してください。Route 53 リソースへのアクセスを制御する方法については、「」を参照してください[アクセスコントロール](security-iam.md#access-control)。
# Amazon Route 53 レコードの作成時または編集時に指定する値
Amazon Route 53 コンソールを使用してレコードを作成する場合、指定する値は、使用するルーティングポリシーと、トラフィックを AWS リソースにルーティングするエイリアスレコードを作成するかどうかによって異なります。
ターゲット AWS リソースを指定する特定のリソース (Elastic Load Balancing、CloudFront ディストリビューション、Amazon S3 バケットなど) にトラフィックをルーティングするエイリアスレコード。オプションで、ヘルスチェックを関連付けたり、ターゲットヘルス評価を設定したりすることもできます。以下のトピックは、各ルーティングポリシーとレコードタイプに必要な値に関する詳細情報を提供しており、Route 53 レコードを効果的に設定するのに役立ちます。
**Topics**
+ [すべてのルーティングポリシーに共通する値](resource-record-sets-values-shared.md)
+ [すべてのルーティングポリシーのエイリアスレコードに共通する値](resource-record-sets-values-alias-common.md)
+ [シンプルなレコードに固有の値](resource-record-sets-values-basic.md)
+ [シンプルなエイリアスレコードに固有の値](resource-record-sets-values-alias.md)
+ [フェイルオーバーレコードに固有の値](resource-record-sets-values-failover.md)
+ [フェイルオーバーエイリアスレコードに固有の値](resource-record-sets-values-failover-alias.md)
+ [位置情報レコードに固有の値](resource-record-sets-values-geo.md)
+ [位置情報エイリアスレコードに固有の値](resource-record-sets-values-geo-alias.md)
+ [地理的近接性レコードに固有の値](resource-record-sets-values-geoprox.md)
+ [地理的近接性エイリアスレコードに固有の値](resource-record-sets-values-geoprox-alias.md)
+ [レイテンシーレコードに固有の値](resource-record-sets-values-latency.md)
+ [レイテンシーエイリアスレコードに固有の値](resource-record-sets-values-latency-alias.md)
+ [IP ベースレコード特有の値](resource-record-sets-values-ipbased.md)
+ [IP ベースエイリアスレコードに特有の値](resource-record-sets-values-ipbased-alias.md)
+ [複数値回答レコードに固有の値](resource-record-sets-values-multivalue.md)
+ [加重レコードに固有の値](resource-record-sets-values-weighted.md)
+ [加重エイリアスレコードに固有の値](resource-record-sets-values-weighted-alias.md)
# すべてのルーティングポリシーに共通する値
これらは、Amazon Route 53 レコードを作成または編集するときに指定できる共通の値です。これらの値は、すべてのルーティングポリシーによって使用されます。
**Topics**
+ [レコード名](#rrsets-values-common-name)
+ [値/トラフィックのルーティング先](#rrsets-values-common-value)
+ [TTL (秒)](#rrsets-values-common-ttl)
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**名前**] フィールドに値 (@ 記号など) を入力しないでください。
**CNAME レコード**
[**レコードタイプ**] の値が [**CNAME**] のレコードを作成する場合、レコードの名前をホストゾーンの名前と同じにすることはできません。
**特殊文字**
a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。
**ワイルドカード文字**
名前にはアスタリスク (\$1) を使用できます。DNSは、名前の中の位置に応じて、「\$1」をワイルドカードまたはアスタリスク (ASCII 42) として処理します。詳細については、「[ホストゾーンおよびレコード名のアスタリスク (\$1) を使用する](DomainNameFormat.md#domain-name-format-asterisk)」を参照してください。
型が **NS** であるリソースレコードセットに対して \$1 ワイルドカードを使用することはできません。
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。[**CNAME**] を除くすべてのタイプは、複数の値を入力できます。各値は個別の行に入力します。
**A — IPv4 アドレス**
IPv4 形式の IP アドレス。例えば、**192.0.2.235**。
**AAAA — IPv6 アドレス**
IPv6 の形式の IP アドレス。例えば、**2001:0db8:85a3:0:0:8a2e:0370:7334**。
**CAA — 認証局の承認**
**[Record name]** (レコード名) で指定されたドメインまたはサブドメインの証明書またはワイルドカード証明書を発行可能な認証機関を制御する、スペースで区切られた 3 つの値です。CAA レコードを使用して以下を指定できます｡
+ SSL/TLS 証明書を発行できる認証機関 (CA)
+ CA がドメインまたはサブドメインの証明書を発行するときに連絡する電子メールアドレスまたは URL
**CNAME — 正規名**
Route 53 で、このレコードに対する DNS クエリに応答して返される完全修飾ドメイン名 (例えば、*www.example.com*)。末尾のドットはオプションです。Route 53 では、ドメイン名が完全修飾ドメイン名であると見なされます。つまり、Route 53 では、(末尾にドットのない) *www.example.com* と (末尾にドットのある) *www.example.com.* が同一と見なされます。
**MX — メール交換**
優先順位とメールサーバーを指定するドメイン名。例えば、**10 mailserver.example.com**。末尾のドットはオプションです。
**NAPTR — 名前付け権限ポインタ**
動的委任発見システム (DDDS) アプリケーションで、1 つの値を別の値に変換または置き換えるために使用される、スペースで区切られた 6 つの設定。詳細については、「[NAPTR レコードタイプ](ResourceRecordTypes.md#NAPTRFormat)」を参照してください。
**PTR — ポインタ**
Route 53 が返すように設定するドメイン名。
**NS – ネームサーバー**
ネームサーバーのドメイン名。例えば、**ns1.example.com**。
単純なルーティングポリシーのみで NS レコードを指定できます。
**SPF — センダーポリシーフレームワーク**
引用符で囲まれた SPF のレコード。例えば、**"v=spf1 ip4:192.168.0.1/16-all"**。SPF レコードは推奨されていません。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
**SRV — サービスロケーター**
SRV レコード。SRV レコードは、メールや通信用のサービスなどのサービスにアクセスするために使用されます。SRV レコードの形式については、接続先のサービスのマニュアルを参照してください。末尾のドットはオプションとして扱われます。
SRV レコードの形式は次のとおりです。
**[優先順位] [重み] [ポート] [サーバーのホスト名]**
次に例を示します。
**1 10 5269 xmpp-server.example.com。**
**TXT — テキスト**
テキストレコード。テキストは引用符で囲みます。例えば、**"Sample text entry"**。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これにより、レイテンシーが短縮され、Route 53 サービスの請求額が削減されます。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
このレコードをヘルスチェックに関連付ける場合は、クライアントがヘルスステータスの変化に迅速に応答するように、TTL を 60 秒以下に指定することをお勧めします。
# すべてのルーティングポリシーのエイリアスレコードに共通する値
これらは、Amazon Route 53 レコードを作成または編集するときに指定できる一般的なエイリアス値です。これらの値は、すべてのルーティングポリシーによって使用されます。
**Topics**
+ [レコード名](#rrsets-values-common-alias-name)
+ [への値/ルートトラフィック](#rrsets-values-alias-common-target)
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**名前**] フィールドに値 (@ 記号など) を入力しないでください。
**CNAME レコード**
**[Type]** (タイプ) の値が **[CNAME]** のレコードを作成する場合、レコードの名前をホストゾーンの名前と同じ名前にすることはできません。
**CloudFront ディストリビューションと Amazon S3 バケットへのエイリアス**
指定する値は、トラフィックをルーティングする AWS リソースによって異なります。
+ **CloudFront ディストリビューション** – ディストリビューションには、レコードの名前と一致する代替ドメイン名が含まれる必要があります。例えば、レコード名が **acme.example.com** の場合、CloudFront ディストリビューションには代替ドメイン名の 1 つとして **acme.example.com** が含まれる必要があります。詳細については、*Amazon CloudFront デベロッパーガイド*の「[代替ドメイン名 (CNAME) を使用する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)」を参照してください。
+ **Amazon S3 バケット** – レコード名は、Amazon S3 バケット名と一致する必要があります。例えば、 バケット名が [**acme.example.com**] である場合、このレコード名も [**acme.example.com**] である必要があります。
また、ウェブサイトホスティング用にバケットを設定する必要があります。詳細については、*Amazon Simple Storage Service ユーザーガイド*の[ウェブサイトホスティング用にバケットを設定する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html)を参照してください。
**特殊文字**
a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。
**ワイルドカード文字**
名前にはアスタリスク (\$1) を使用できます。DNSは、名前の中の位置に応じて、「\$1」をワイルドカードまたはアスタリスク (ASCII 42) として処理します。詳細については、「[ホストゾーンおよびレコード名のアスタリスク (\$1) を使用する](DomainNameFormat.md#domain-name-format-asterisk)」を参照してください。
## への値/ルートトラフィック
リストから選択する値、または フィールドに入力する値は、トラフィックをルーティングする AWS リソースによって異なります。
特定の AWS リソースにトラフィックをルーティングするように Route 53 を設定する方法の詳細については、「」を参照してください[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)。
**重要**
同じ AWS アカウントを使用して、トラフィックをルーティングするホストゾーンとリソースを作成し、リソースが**エンドポイント**リストに表示されない場合は、以下を確認してください。
[**レコードタイプ**] でサポートされている値を選択したことを確認します。サポートされている値は、トラフィックのルーティング先のリソースに固有です。例えば、S3 バケットにトラフィックをルーティングするには、[**レコードタイプ**] として [**A — IPv4 アドレス**] を選択する必要があります。
アカウントに、該当するリソースを一覧表示するために必要な IAM アクセス許可があることを確認します。例えば、CloudFront ディストリビューションを [**エンドポイント**] リストに表示するためには、アカウントが次のアクションを実行するアクセス許可を持っている必要があります: `cloudfront:ListDistributions`。
IAM ポリシーの例については、「[Amazon Route 53 コンソールを使用するために必要なアクセス許可](access-control-managing-permissions.md#console-required-permissions)」を参照してください。
異なる AWS アカウントを使用してホストゾーンとリソースを作成した場合、**エンドポイント**リストにはリソースは表示されません。[**エンドポイント**] に入力する値を決定するには、リソースタイプに関する次のドキュメントを参照してください。
**API Gateway のカスタムリージョン API とエッジ最適化 API**
API Gateway のカスタムリージョン API とエッジ最適化 API で、次のいずれかを行います。
+ **同じアカウントを使用して、Route 53 ホストゾーンと API を作成した場合** – [**エンドポイント**] を選択し、リストから API を選択します。API が多数ある場合は、API エンドポイントの最初の数文字を入力してリストをフィルタリングすることができます。
**注記**
このレコードの名前は、API のカスタムドメイン名 (例: **api.example.com**) と一致している必要があります。
+ **別のアカウントを使用して、Route 53 ホストゾーンと API を作成した場合** – API の API エンドポイント (例: **api.example.com**) を入力します。
1 つの AWS アカウントを使用して現在のホストゾーンを作成し、別のアカウントを使用して API を作成した場合、API は API **Gateway APIs** **のエンドポイント**リストに表示されません。
1 つのアカウントを使用して現在のホストゾーンを作成し、すべての API を作成するのに 1 つ以上の別のアカウントを使用した場合、[**エンドポイント**] リストの [**API Gateway API**] に「**No targets available**」と表示されます。詳細については、「[ドメイン名を使用してトラフィックを Amazon API Gateway の API にルーティングする](routing-to-api-gateway.md)」を参照してください。
**CloudFront ディストリビューション**
CloudFront ディストリビューションの場合は、次のいずれかの操作を実行します。
+ **Route 53 ホストゾーンと CloudFront ディストリビューションを作成する際に同じアカウントを使用している場合** – [**エンドポイント**] を選択し、リストからディストリビューションを選択します。ディストリビューションが多数ある場合は、ディストリビューションのドメイン名の最初の数文字を入力することでリストをフィルタ処理できます。
ディストリビューションがリストに表示されていない場合は、次の点を確認してください。
+ このレコードの名前は、ディストリビューションの代替ドメイン名に一致する必要があります。
+ ディストリビューションに代替ドメイン名を追加した直後であれば、変更がすべての CloudFront エッジロケーションに伝達されるまでに 15 分程度かかる場合があります。変更が伝達されるまで、Route 53 は新しい代替ドメイン名を認識できません。
+ **Route 53 ホストゾーンとディストリビューションを作成する際に異なるアカウントを使用している場合** – ディストリビューションの CloudFront ドメイン名を入力します (例えば、**d111111abcdef8.cloudfront.net**)。
1 つの AWS アカウントを使用して現在のホストゾーンを作成し、別のアカウントを使用してディストリビューションを作成した場合、ディストリビューションは**エンドポイント**リストに表示されません。
1 つのアカウントを使用して現在のホストゾーンを作成し、1 つ以上の別のアカウントを使用してすべてのディストリビューションを作成した場合 、[**エンドポイント**] リストの [**CloudFront ディストリビューション**] に「**No targets available**」と表示されます。
すべてのエッジロケーションに伝達されていない CloudFront ディストリビューションにクエリをルーティングしないでください。その場合、ユーザーは該当するコンテンツにアクセスできません。
CloudFront ディストリビューションには、レコードの名前と一致する代替ドメイン名が含まれる必要があります。例えば、レコード名が **acme.example.com** の場合、CloudFront ディストリビューションには代替ドメイン名の 1 つとして **acme.example.com** が含まれる必要があります。詳細については、*Amazon CloudFront デベロッパーガイド*の「[代替ドメイン名 (CNAME) を使用する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)」を参照してください。
ディストリビューションに対して IPv6 が有効になっている場合は、2 つのレコードを作成します。1 つは [**レコードタイプ**] として [**A — IPv4 アドレス**]の値を持つもの、もう 1 つは [**AAAA IPv6 — アドレス**] の値を持つものとします。詳細については、「[ドメイン名を使用したトラフィックの Amazon CloudFront ディストリビューションへのルーティング](routing-to-cloudfront-distribution.md)」を参照してください。
**App Runner サービス**
App Runner サービスで、次のいずれかの操作を行います。
+ **同じアカウントを使用して Route 53 ホストゾーンと App Runner サービスを作成した場合は**、 を選択し AWS リージョン、リストからトラフィックをルーティングする環境のドメイン名を選択します。
+ **異なるアカウントを使用して Route 53 ホストゾーンと App Runner を作成した場合** – カスタムドメイン名を入力します。詳細については、「[Managing custom domain names for App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html)」(App Runner サービスでのカスタムドメイン名の管理) を参照してください。
1 つの AWS アカウントを使用して現在のホストゾーンを作成し、別のアカウントを使用して App Runner を作成した場合、App Runner は**エンドポイント**リストに表示されません。
詳細については、「[Amazon Route 53 での App Runner サービスに対するトラフィックのルーティングの設定](routing-to-app-runner.md#routing-to-app-runner-configuring)」を参照してください。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
Elastic Beanstalk 環境のドメイン名に環境をデプロイしたリージョンが含まれている場合、トラフィックを環境にルーティングするエイリアスレコードを作成できます。たとえば、ドメイン名 `my-environment.us-west-2.elasticbeanstalk.com` はローカル化されたドメイン名です｡
2016 年の初めよりも前に作成された環境の場合、ドメイン名にはリージョンは含まれていません。これらの環境にトラフィックをルーティングするには、エイリアスレコードの代わりに CNAME レコードを作成する必要があります。ルートドメイン名に対して CNAME レコードを作成することはできないことに注意してください｡ 例えば、ドメイン名が example.com の場合、acme.example.com のトラフィックを Elastic Beanstalk 環境にルーティングするレコードは作成できますが、example.com のトラフィックを Elastic Beanstalk 環境にルーティングするレコードは作成できません。
ローカル化されたサブドメインがある Elastic Beanstalk 環境の場合は、次のいずれかを実行します。
+ **Route 53 ホストゾーンと Elastic Beanstalk 環境を作成する際に同じアカウントを使用している場合** – [**エンドポイント**] を選択し、リストから環境を選択します。環境が多数ある場合は、環境の CNAME 属性の最初の数文字を入力することでリストをフィルタ処理できます。
+ **別のアカウントを使用して、Route 53 ホストゾーンと Elastic Beanstalk 環境を作成した場合**— Elastic Beanstalk 環境の CNAME 属性を入力します。
詳細については、「[AWS Elastic Beanstalk 環境へのトラフィックのルーティング](routing-to-beanstalk-environment.md)」を参照してください。
**ELB ロードバランサー**
ELB ロードバランサーの場合は、次のいずれかの操作を実行します。
+ **Route 53 ホストゾーンとロードバランサーを作成する際に同じアカウントを使用している場合** – [**エンドポイント**] を選択し、リストからロードバランサーを選択します。ロードバランサーが多数ある場合は、DNS 名の最初の数文字を入力することでリストをフィルタ処理できます。
+ **Route 53 ホストゾーンとロードバランサーを作成する際に異なるアカウントを使用している場合** – 「[Elastic Load Balancing ロードバランサーの DNS 名を取得する](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure)」の手順で取得した値を入力します。
1 つの AWS アカウントを使用して現在のホストゾーンを作成し、別のアカウントを使用してロードバランサーを作成した場合、ロードバランサーは**エンドポイント**リストに表示されません。
1 つのアカウントを使用して現在のホストゾーンを作成し、すべてのロードバランサーを作成するのに 1 つ以上の別のアカウントを使用した場合、[**エンドポイント**] リストの [**Elastic Load Balancers**] に「**No targets available**」と表示されます。
コンソールは、別のアカウントのアプリケーションと Classic Load Balancer に **dualstack.** を付加します。ウェブブラウザなどのクライアントが、ドメイン名 (example.com) またはサブドメイン名 (www.example.com) の IP アドレスをリクエストする場合、クライアントは IPv4 アドレス (A レコード)、IPv6 アドレス (AAAA レコード)、または IPv4 アドレスと IPv6 アドレスの両方を (別のリクエストで) リクエストできます。[**dualstack.**] の指定により、Route 53 は、クライアントがリクエストした IP アドレス形式に基づいて、ロードバランサーに対する適切な IP アドレスで応答することができます。
詳細については、「[ELB ロードバランサーへのトラフィックのルーティング](routing-to-elb-load-balancer.md)」を参照してください。
**AWS Global Accelerator アクセラレーター**
AWS Global Accelerator アクセラレーターの場合は、アクセラレーターの DNS 名を入力します。現在のアカウントまたは別の AWS アカウントを使用して作成したアクセラレーターの DNS 名を入力できます AWS 。
**Amazon S3 バケット**
ウェブサイトエンドポイントとして設定された Amazon S3 バケットの場合、次のいずれかを実行します。
+ **Route 53 ホストゾーンと Amazon S3 バケットを作成する際に同じアカウントを使用している場合** – [**エンドポイント**] を選択し、リストからバケットを選択します。バケットが多数ある場合は、DNS 名の最初の数文字を入力することでリストをフィルタ処理できます。
[**エンドポイント**] の値は、バケットの Amazon S3 ウェブサイトエンドポイントに変わります。
+ **別のアカウントを使用して、Route 53 ホストゾーンと Amazon S3 bucket を作成した場合** – S3 バケットを作成したリージョンの名前を入力します。*Amazon Web Services 全般のリファレンス* の「[Amazon S3 ウェブサイトのエンドポイント](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints)」にアクセスし、表にある**ウェブサイトのエンドポイント**列の値を使用します。
現在の AWS アカウント以外のアカウントを使用して Amazon S3 バケットを作成した場合、そのバケットは**エンドポイント**リストに表示されません。
ウェブサイトホスティング用にバケットを設定する必要があります。詳細については、*Amazon Simple Storage Service ユーザーガイド*の[ウェブサイトホスティング用にバケットを設定する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html)を参照してください。
レコード名は、Amazon S3 バケット名と一致する必要があります。例えば、Amazon S3 バケット名が [**acme.example.com**] である場合、このレコード名も [**acme.example.com**] である必要があります。
加重エイリアス、レイテンシーエイリアス、フェイルオーバーエイリアス、または位置情報エイリアスのレコードのグループの中には、Amazon S3 バケットにクエリをルーティングするレコードを 1 つだけ作成できます。これは、レコード名はバケット名と一致する必要があり、バケット名はグローバルに一意である必要があるためです。
**Amazon OpenSearch Service**
OpenSearch Service で、次のいずれかの操作を行います。
+ **OpenSearch Service カスタムドメイン**: レコードの名前はカスタムドメインの名前と一致する必要があります。例えば、カスタムドメイン名が [test.example.com] である場合、このレコード名も [test.example.com] である必要があります。
+ **同じアカウントを使用して Route 53 ホストゾーンと OpenSearch Service ドメインを作成した場合は**、 を選択し AWS リージョン、ドメイン名を選択します。
+ **異なるアカウントを使用して Route 53 ホストゾーンと OpenSearch Service を作成した場合** – カスタムドメイン名を入力します。詳細については、「[カスタムエンドポイントを作成する](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html)」を参照してください。
1 つの AWS アカウントを使用して現在のホストゾーンを作成し、別のアカウントを使用して OpenSearch Service ドメインを作成した場合、そのドメインは**エンドポイント**リストに表示されません。
1 つのアカウントを使用して現在のホストゾーンを作成し、すべての OpenSearch Service ドメインを作成するのに 1 つ以上の別のアカウントを使用した場合、[**エンドポイント**] リストの **[OpenSearch Service]** に「**No targets available**」と表示されます。
詳細については、「[Amazon Route 53 を Amazon OpenSearch Service ドメインエンドポイントにルーティングする Amazon Route 53 の設定](routing-to-open-search-service.md#routing-to-open-search-service-configuring)」を参照してください。
**Amazon VPC インターフェイスのエンドポイント**
Amazon VPC インターフェイスエンドポイントで、以下のいずれかを行います。
+ **Route 53 ホストゾーンとインターフェイスエンドポイントを作成する際に同じアカウントを使用している場合** – [**エンドポイント**] を選択し、リストからインターフェイスエンドポイントを選択します。インターフェイスエンドポイントが多数ある場合は、DNS ホスト名の最初の数文字を入力することでリストをフィルタリングすることができます。
+ **別のアカウントを使用して Route 53 ホストゾーンとインターフェイスエンドポイントを作成した場合** – インターフェイスエンドポイントの DNS ホスト名 (例: **vpce-123456789abcdef01-example-us-east-1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com**) を入力します。
1 つの AWS アカウントを使用して現在のホストゾーンを作成し、別のアカウントを使用してインターフェイスエンドポイントを作成した場合、インターフェイスエンドポイントは **VPC エンドポイント**の**エンドポイント**リストに表示されません。
1 つのアカウントを使用して現在のホストゾーンを作成し、すべてのインターフェイスエンドポイントを作成するのに 1 つ以上の別のアカウントを使用した場合、[**エンドポイント**] リストの [**VPC エンドポイント**] に「**No targets available**」と表示されます。
詳細については、「[ドメイン名を使用してトラフィックを Amazon Virtual Private Cloud インターフェイスエンドポイントにルーティングする](routing-to-vpc-interface-endpoint.md)」を参照してください。
**このホストゾーン内のレコード**
このホストゾーン内のレコードの場合は、[**エンドポイント**] を選択し、該当するレコードを選択します。レコードが多数ある場合は、名前の最初の数文字を入力することでリストをフィルタ処理できます。
ホストゾーンにデフォルトの NS および SOA レコードのみが含まれる場合、[**エンドポイント**] リストには「**No targets available**」と表示されます。
ホストゾーン ([*zone apex*] といいます) と同じ名前のエイリアスレコードを作成する場合、[**レコードタイプ**] の値が [**CNAME**] のレコードは選択できません。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、Zone Apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
# シンプルなレコードに固有の値
シンプルなレコードを作成するときは、以下の値を指定します。
**Topics**
+ [ルーティングポリシー](#rrsets-values-basic-routing-policy)
+ [レコード名](#rrsets-values-basic-name)
+ [値/トラフィックのルーティング先](#rrsets-values-basic-value)
+ [レコードタイプ](#rrsets-values-basic-type)
+ [TTL (秒)](#rrsets-values-basic-ttl)
## ルーティングポリシー
**[Simple routing]** (シンプルルーティング) を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**名前**] フィールドに値 (@ 記号など) を入力しないでください。
レコード名の詳細については、[レコード名](resource-record-sets-values-shared.md#rrsets-values-common-name) を参照してください。
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。[**CNAME**] を除くすべてのタイプは、複数の値を入力できます。各値は個別の行に入力します。
次の値にトラフィックをルーティングするか、次の値を指定できます。
+ **A — IPv4 アドレス**
+ **AAAA — IPv6 アドレス**
+ **CAA —認証局の承認**
+ **CNAME — 正規名**
+ **MX — メール交換**
+ **NAPTR — 名前付け権限ポインタ**
+ **NS – ネームサーバー**
ネームサーバーのドメイン名。例えば、**ns1.example.com**。
**注記**
単純なルーティングポリシーのみで NS レコードを指定できます。
+ **PTR — ポインタ**
+ **SPF — センダーポリシーフレームワーク**
+ **SRV — サービスロケーター**
+ **TXT — テキスト**
上記の値の詳細については、「[common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value)」(値/トラフィックのルーティング先) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
Route 53 が DNS クエリに応答する方法に基づいて、**レコードタイプ**の値を選択します。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これにより、レイテンシーが短縮され、Route 53 サービスの請求額が削減されます。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
# シンプルなエイリアスレコードに固有の値
エイリアスレコードを作成するときは、以下の値を指定します。詳細については、「[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)」を参照してください。
**注記**
で Route 53 を使用している場合 AWS GovCloud (US) Region、この機能にはいくつかの制限があります。詳細については、*AWS GovCloud (US) ユーザーガイド*の [Amazon Route 53 のページ](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html)を参照してください。
**Topics**
+ [ルーティングポリシー](#rrsets-values-alias-routing-policy)
+ [レコード名](#rrsets-values-alias-name)
+ [への値/ルートトラフィック](#rrsets-values-alias-alias-target)
+ [レコードタイプ](#rrsets-values-alias-type)
+ [ターゲットの正常性の評価](#rrsets-values-alias-evaluate-target-health)
## ルーティングポリシー
**[Simple routing]** (シンプルルーティング) を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**名前**] フィールドに値 (@ 記号など) を入力しないでください。
レコード名の詳細については、[レコード名](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) を参照してください。
## への値/ルートトラフィック
リストから選択する値、または フィールドに入力する値は、トラフィックをルーティングする AWS リソースによって異なります。
ターゲットにできる AWS リソースの詳細については、[値/ルートトラフィックのエイリアスレコードの一般的な値](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target)を参照してください。
特定の AWS リソースにトラフィックをルーティングするように Route 53 を設定する方法の詳細については、「」を参照してください[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
トラフィックをルーティングする AWS リソースに基づいて、該当する値を選択します。
**API Gateway のカスタムリージョン API またはエッジ最適化 API**
[**A — IPv4 アドレス**] を選択します。
**Amazon VPC インターフェイスのエンドポイント**
[**A — IPv4 アドレス**] を選択します。
**CloudFront 配信**
[**A — IPv4 アドレス**] を選択します。
ディストリビューションに対して IPv6 が有効になっている場合は、2 つのレコードを作成します。1 つは [**タイプ**] として [**A — IPv4 アドレス**] の値を持つもの、もう 1つは [**AAAA — IPv6 アドレス**] の値を持つものとします。
**App Runner サービス**
[**A — IPv4 アドレス**] を選択します。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**A — IPv4 アドレス**] を選択します。
**ELB ロードバランサー**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**Amazon S3 バケット**
[**A — IPv4 アドレス**] を選択します。
**OpenSearch Service**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**このホストゾーン内の別のレコード**
エイリアスを作成するレコードのタイプを選択します。[**NS**] および [**SOA**] 以外のすべてのタイプがサポートされます。
ホストゾーン (*Zone Apex* といいます) と同じ名前のエイリアスレコードを作成する場合、[**タイプ**] の値が [**CNAME**] のレコードにトラフィックをルーティングすることはできません。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、zone apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
## ターゲットの正常性の評価
**[Routing policy]** (ルーティングポリシー) の値が **[Simple]** (シンプル) の場合、**[No]** (いいえ) またはデフォルトの **[Yes]** (はい) を選択できます。**[Evaluate target health]** (ターゲットヘルスを評価) は、**[Simple]** (シンプル) ルーティングに一切影響を及ぼさないためです。指定の名前とタイプのレコードが 1 つのみの場合、Route 53 は、ソースが正常かどうかに関係なく、そのレコードの値を使用して DNS クエリに応答します。
他のルーティングポリシーの場合、**ターゲットヘルスの評価**は、エイリアスレコードが参照するリソースのヘルスを Route 53 がチェックするかどうかを決定します。
+ **ターゲットヘルスの評価が運用上の利点を提供するサービス**: ロードバランサー (ELB) とロードバランサーを使用する AWS Elastic Beanstalk 環境の場合、**ターゲットヘルスの評価**を**「はい」**に設定すると、Route 53 は異常なリソースからトラフィックをルーティングできます。
+ **高可用性サービス**: Amazon S3 バケット、VPC インターフェイスエンドポイント、Amazon API Gateway、Amazon OpenSearch Service AWS Global Accelerator、Amazon VPC Lattice などのサービスの場合、ターゲット**ヘルスの評価**は高可用性のために設計されているため、運用上の利点はありません。これらのサービスのフェイルオーバーシナリオでは、代わりに [Route 53 ヘルスチェック](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html)を使用します。
さまざまな AWS のサービスで**ターゲットヘルスを評価する**方法の詳細については、 API リファレンスの[EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth) ドキュメント」を参照してください。
# フェイルオーバーレコードに固有の値
フェイルオーバーレコードを作成するときは、以下の値を指定します。
**注記**
プライベートホストゾーンでのフェイルオーバーレコードの作成については、「[プライベートホストゾーンのフェイルオーバーの設定](dns-failover-private-hosted-zones.md)」を参照してください。
**Topics**
+ [ルーティングポリシー](#rrsets-values-failover-routing-policy)
+ [レコード名](#rrsets-values-failover-name)
+ [レコードタイプ](#rrsets-values-failover-type)
+ [TTL (秒)](#rrsets-values-failover-ttl)
+ [値/トラフィックのルーティング先](#rrsets-values-failover-value)
+ [フェイルオーバーレコードタイプ](#rrsets-values-failover-record-type)
+ [ヘルスチェック](#rrsets-values-failover-associate-with-health-check)
+ [記録 ID](#rrsets-values-failover-set-id)
## ルーティングポリシー
[**フェイルオーバー**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
フェイルオーバーレコードのグループで、両方のレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-shared.md#rrsets-values-common-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
プライマリフェイルオーバーレコードとセカンダリフェイルオーバーレコードの両方に同じ値を選択してください。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これにより、レイテンシーが短縮され、Route 53 サービスの請求額が削減されます。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
このレコードをヘルスチェックに関連付ける場合、ヘルスステータスの変化にクライアントがすばやく対応できるよう、60 秒以下の TTL を指定することをお勧めします。
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。[**CNAME**] を除くすべてのタイプは、複数の値を入力できます。各値は個別の行に入力します。
次の値にトラフィックをルーティングするか、次の値を指定できます。
+ **A — IPv4 アドレス**
+ **AAAA — IPv6 アドレス**
+ **CAA —認証局の承認**
+ **CNAME — 正規名**
+ **MX — メール交換**
+ **NAPTR — 名前付け権限ポインタ**
+ **PTR — ポインタ**
+ **SPF — センダーポリシーフレームワーク**
+ **SRV — サービスロケーター**
+ **TXT — テキスト**
上記の値の詳細については、「[common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value)」(値/トラフィックのルーティング先) を参照してください。
## フェイルオーバーレコードタイプ
このレコードに該当する値を選択します。フェイルオーバーが正常に動作するためには、プライマリフェイルオーバーレコードを 1 つとセカンダリフェイルオーバーレコードを 1 つ作成する必要があります。
[**レコード名**] および [**レコードタイプ**] の値がフェイルオーバーレコードと同じである非フェイルオーバーレコードを作成することはできません。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にあるエイリアスレコードまたはレコードの **[Evaluate target health]** (ターゲットのヘルスを評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
## 記録 ID
プライマリレコードとセカンダリレコードを一意に識別する値を入力します。
# フェイルオーバーエイリアスレコードに固有の値
フェイルオーバーエイリアスレコードを作成するときは、以下の値を指定します。
詳細については、以下のトピックを参照してください。
+ プライベートホストゾーンでのフェイルオーバーレコードの作成については、「[プライベートホストゾーンのフェイルオーバーの設定](dns-failover-private-hosted-zones.md)」を参照してください。
+ エイリアスレコードの詳細については、「[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)」を参照してください。
**Topics**
+ [ルーティングポリシー](#rrsets-values-failover-alias-routing-policy)
+ [レコード名](#rrsets-values-failover-alias-name)
+ [レコードタイプ](#rrsets-values-failover-alias-type)
+ [値/トラフィックのルーティング先](#rrsets-values-failover-alias-alias-target)
+ [フェイルオーバーレコードタイプ](#rrsets-values-failover-alias-failover-record-type)
+ [ヘルスチェック](#rrsets-values-failover-alias-associate-with-health-check)
+ [ターゲットの正常性の評価](#rrsets-values-failover-alias-evaluate-target-health)
+ [記録 ID](#rrsets-values-failover-alias-set-id)
## ルーティングポリシー
[**フェイルオーバー**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
フェイルオーバーレコードのグループで、両方のレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
トラフィックをルーティングする AWS リソースに基づいて、該当する値を選択します。プライマリフェイルオーバーレコードとセカンダリフェイルオーバーレコードの両方に同じ値を選択してください。
**API Gateway のカスタムリージョン API またはエッジ最適化 API**
[**A — IPv4 アドレス**] を選択します。
**Amazon VPC インターフェイスのエンドポイント**
[**A — IPv4 アドレス**] を選択します。
**CloudFront 配信**
[**A — IPv4 アドレス**] を選択します。
ディストリビューションに対して IPv6 が有効になっている場合は、2 つのレコードを作成します。1 つは [**タイプ**] として [**A — IPv4 アドレス**] の値を持つもの、もう 1つは [**AAAA — IPv6 アドレス**] の値を持つものとします。
**App Runner サービス**
[**A — IPv4 アドレス**] を選択します。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**A — IPv4 アドレス**] を選択します。
**ELB ロードバランサー**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**Amazon S3 バケット**
[**A — IPv4 アドレス**] を選択します。
**OpenSearch Service**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**このホストゾーン内の別のレコード**
エイリアスを作成するレコードのタイプを選択します。[**NS**] および [**SOA**] 以外のすべてのタイプがサポートされます。
ホストゾーン (*Zone Apex* といいます) と同じ名前のエイリアスレコードを作成する場合、[**タイプ**] の値が [**CNAME**] のレコードにトラフィックをルーティングすることはできません。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、Zone Apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
## 値/トラフィックのルーティング先
リストから選択する値、または フィールドに入力する値は、トラフィックをルーティングする AWS リソースによって異なります。
ターゲットにできる AWS リソースの詳細については、[値/ルートトラフィックのエイリアスレコードの一般的な値](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target)を参照してください。
特定の AWS リソースにトラフィックをルーティングするように Route 53 を設定する方法の詳細については、「」を参照してください[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)。
**注記**
プライマリフェイルオーバーレコードとセカンダリフェイルオーバーレコードを作成する場合、オプションで、 [**名前**] および [**レコードタイプ**] が同じ値のフェイルオーバーレコードを 1 つとフェイルオーバー*エイリアス*レコードを 1 つ作成できます。フェイルオーバーレコードとフェイルオーバーエイリアスレコードを混在させる場合、いずれかをプライマリレコードにすることができます。
## フェイルオーバーレコードタイプ
このレコードに該当する値を選択します。フェイルオーバーが正常に動作するためには、プライマリフェイルオーバーレコードを 1 つとセカンダリフェイルオーバーレコードを 1 つ作成する必要があります。
[**レコード名**] および [**レコードタイプ**] の値がフェイルオーバーレコードと同じである非フェイルオーバーレコードを作成することはできません。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にあるエイリアスレコードまたはレコードの **[Evaluate target health]** (ターゲットのヘルスを評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
## ターゲットの正常性の評価
Route 53 で、このレコードを使用して [**エンドポイント**] で指定されたリソースの正常性を確認することによって DNS クエリに応答するかどうかを判定する場合は、[**Yes**] を選択します。
次の点に注意してください。
**API Gateway のカスタムリージョン API とエッジ最適化 API**
エンドポイントが API Gateway カスタムリージョン API またはエッジ最適化 API である場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**CloudFront ディストリビューション**
エンドポイントが CloudFront ディストリビューションの場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定することはできません。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**エンドポイント**] で Elastic Beanstalk 環境を指定し、その環境に ELB ロードバランサーが含まれている場合、Elastic Load Balancing はクエリをロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみルーティングします。(複数の Amazon EC2 インスタンスが含まれている場合、環境には自動的に ELB ロードバランサーが含まれます。) [**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な Amazon EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他に利用可能なリソースがあれば、そこにクエリをルーティングします。
環境に 1 つの Amazon EC2 インスタンスが含まれている場合、特別な要件はありません。
**ELB ロードバランサー**
ヘルスチェックの動作はロードバランサーのタイプによって異なります。
+ [**Classic Load Balancers**] – [**エンドポイント**] で ELB Classic Load Balancer を指定した場合、Elastic Load Balancing は、ロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみクエリをルーティングします。[**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他のリソースにクエリをルーティングします。
+ **アプリケーションと Network Load Balancer** – ELB アプリケーションまたは Network Load Balancer を指定し、[**Evaluate Target health (ターゲットの正常性の評価)**] を **Yes** に設定すると、Route 53 は､ロードバランサーに関連付けられているターゲットグループの正常性に基づいて､クエリをロードバランサーにルーティングします。
+ アプリケーションまたは Network Load Balancer が正常とみなされるには、ターゲットを含むターゲットグループに、正常なターゲットが 1 つ以上含まれている必要があります。ターゲットグループに異常なターゲットのみが含まれている場合、ロードバランサーは異常であるとみなされ、Route 53 はクエリを他のリソースにルーティングします。
+ 登録されたターゲットを持たないターゲットグループは異常であるとみなされます｡
ロードバランサーを作成するときは、Elastic Load Balancing のヘルスチェックの設定を行います。これは Route 53 のヘルスチェックではありませんが、同様の機能を実行します。ELB ロードバランサーに登録する EC2 インスタンスに対しては Route 53 のヘルスチェックを作成しないでください。
**S3 バケット**
エンドポイントが S3 バケットである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**Amazon VPC インターフェイスのエンドポイント**
エンドポイントが Amazon VPC インターフェイスエンドポイントである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**同じホストゾーンの他のレコード**
Endpoint で指定した AWS リソース****がレコードまたはレコードのグループ (加重レコードのグループなど) で、別のエイリアスレコードではない場合は、ヘルスチェックをエンドポイント内のすべてのレコードに関連付けることをお勧めします。詳細については、「[ヘルスチェックを省略するとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting)」を参照してください。
## 記録 ID
プライマリレコードとセカンダリレコードを一意に識別する値を入力します。
# 位置情報レコードに固有の値
位置情報レコードを作成するときは、以下の値を指定します。
**Topics**
+ [ルーティングポリシー](#rrsets-values-geo-routing-policy)
+ [レコード名](#rrsets-values-geo-name)
+ [レコードタイプ](#rrsets-values-geo-type)
+ [TTL (秒)](#rrsets-values-geo-ttl)
+ [値/トラフィックのルーティング先](#rrsets-values-geo-value)
+ [ロケーション](#rrsets-values-geo-location)
+ [米国の州](#rrsets-values-geo-sublocation)
+ [ヘルスチェック](#rrsets-values-geo-associate-with-health-check)
+ [記録 ID](#rrsets-values-geo-set-id)
## ルーティングポリシー
[**位置情報**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**名前**] フィールドに値 (@ 記号など) を入力しないでください。
位置情報レコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-shared.md#rrsets-values-common-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください
位置情報レコードのグループ内のすべてのレコードに同じ値を選択します。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これにより、レイテンシーが短縮され、Route 53 サービスの請求額が削減されます。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
このレコードをヘルスチェックに関連付ける場合、ヘルスステータスの変化にクライアントがすばやく対応できるよう、60 秒以下の TTL を指定することをお勧めします。
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。[**CNAME**] を除くすべてのタイプは、複数の値を入力できます。各値は個別の行に入力します。
次の値にトラフィックをルーティングするか、次の値を指定できます。
+ **A — IPv4 アドレス**
+ **AAAA — IPv6 アドレス**
+ **CAA —認証局の承認**
+ **CNAME — 正規名**
+ **MX — メール交換**
+ **NAPTR — 名前付け権限ポインタ**
+ **PTR — ポインタ**
+ **SPF — センダーポリシーフレームワーク**
+ **SRV — サービスロケーター**
+ **TXT — テキスト**
上記の値の詳細については、「[common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value)」(値/トラフィックのルーティング先) を参照してください。
## ロケーション
クエリの発信元の場所に基づいて DNS クエリに応答するように Route 53 を設定する場合は、Route 53 がこのレコードの設定を使用して応答する対象の大陸または国を選択します。Route 53 が米国の各州について DNS クエリに応答する場合は、[**ロケーション**] リストから [**米国**] を選択し、[**サブロケーション**] グループから州を選択します。
プライベートホストゾーンの場合は、リソース AWS リージョン がある に最も近い大陸、国、またはサブディビジョンを選択します。例えば、リソースが us-east-1 にある場合であれば、北米、米国、またはバージニアを指定します。
**重要**
[**ロケーション**] に関する [**デフォルト**] の値を持つ位置情報レコードを 1 つ作成することをお勧めします。これにより、レコードを作成していない地理的場所および Route 53 が位置を識別できない IP アドレスをカバーできます。
[**レコード名**] および [**レコードタイプ**] の値が位置情報コードと同じである非位置情報レコードを作成することはできません。
詳細については、「[位置情報ルーティング](routing-policy-geo.md)」を参照してください
Amazon Route 53 が各大陸に関連付ける国を次に示します。国コードは、ISO 3166 のものです。詳細については、Wikipedia の記事、「[ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)」を参照してください。
**アフリカ (AF)**
AO、BF、BI、BJ、BW、CD、CF、CG、CI、CM、CV、DJ、DZ、EG、ER、ET、GA、GH、GM、GN、GQ、GW、KE、KM、LR、LS、LY、MA、MG、ML、MR、MU、MW、MZ、NA、NE、NG、RE、RW、SC、SD、SH、SL、SN、SO、SS、ST、SZ、TD、TG、TN、TZ、UG、YT、ZA、ZM、ZW
**南極 (AN)**
AQ、GS、TF
**アジア (AS)**
AE、AF、AM、AZ、BD、BH、BN、BT、CC、CN、GE、HK、ID、IL、IN、IO、IQ、IR、JO、JP、KG、KH、KP、KR、KW、KZ、LA、LB、LK、MM、MN、MO、MV、MY、NP、OM、PH、PK、PS、QA、SA、SG、SY、TH、TJ、TM、TW、UZ、VN、YE
**欧州 (EU)**
AD、AL、AT、AX、BA、BE、BG、BY、CH、CY、CZ、DE、DK、EE、ES、FI、FO、FR、GB、GG、GI、GR、HR、HU、IE、IM、IS、IT、JE、LI、LT、LU、LV、MC、MD、ME、MK、MT、NL、NO、PL、PT、RO、RS、RU、SE、SI、SJ、SK、SM、TR、UA、VA、XK
一部のプロバイダーは、TR がアジアにあると見なしており、IP アドレスにはそれが反映されます。
**北米 (NA)**
AG、AI、AW、BB、BL、BM、BQ、BS、BZ、CA、CR、CU、CW、DM、DO、GD、GL、GP、GT、HN、HT、JM、KN、KY、LC、MF、MQ、MS、MX、NI、PA、PM、PR、SV、SX、TC、TT、US、VC、VG、VI
**オセアニア (OC)**
AS、AU、CK、FJ、FM、GU、KI、MH、MP、NC、NF、NR、NU、NZ、PF、PG、PN、PW、SB、TK、TL、TO、TV、UM、VU、WF、WS
**南米 (SA)**
AR、BO、BR、CL、CO、EC、FK、GF、GY、PE、PY、SR、UY、VE
**注記**
Route 53 では、以下の国の位置情報レコードの作成をサポートしていません。ブーベ島 (BV)、クリスマス島 (CX)、西サハラ (EH)、ハード島とマクドナルド諸島 (HM)。これらの国の IP アドレスに関するデータは利用できません。
## 米国の州
クエリの発信元である米国の州に基づいて DNS クエリに応答するように Route 53 を設定する場合は、[**米国の州**] リストから州を選択します。米国の海外領土 (プエルトリコなど) は [**Location (ロケーション)**] リストに国として表示されます。
**重要**
一部の IP アドレスは、米国と関連付けられていますが、個々の州とは関連付けられていません。米国のすべての州に対するレコードを作成する場合は、これらの関連付けられていない IP アドレスのクエリをルーティングするために、米国のレコードも作成することをお勧めします。米国のレコードを作成しない場合、Route 53 は関連付けられていない米国の IP アドレスからの DNS クエリに対して、デフォルトの位置情報レコードの設定 (作成している場合) または "応答なし" の応答を使用して応答します。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にあるエイリアスレコードまたはレコードの **[Evaluate target health]** (ターゲットのヘルスを評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
位置情報レコードで、エンドポイントが正常でない場合、Route 53 は、より大きい、関連付けられた地理的リージョンのレコードを探します。例えば、米国の 1 つの州、米国、北米、およびすべての場所 ([**Location**] が [**Default**]) のレコードがあるとします。州のレコードのエンドポイントが正常でない場合、Route 53 は、正常なエンドポイントがあるレコードが見つかるまで、米国、北米、すべての場所のレコードを、この順序で確認します。すべての場所のレコードを確認しても、適用可能なレコードがすべて正常でない場合、Route 53 は最小の地理的リージョンのレコードの値を使用して DNS クエリに応答します。
## 記録 ID
位置情報レコードのグループ内で、このレコードを一意に識別する値を入力します。
# 位置情報エイリアスレコードに固有の値
位置情報エイリアスレコードを作成するときは、以下の値を指定します。
詳しくは、[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md) を参照してください。
**Topics**
+ [ルーティングポリシー](#rrsets-values-geo-alias-routing-policy)
+ [レコード名](#rrsets-values-geo-alias-name)
+ [レコードタイプ](#rrsets-values-geo-alias-type)
+ [値/トラフィックのルーティング先](#rrsets-values-geo-alias-alias-target)
+ [ロケーション](#rrsets-values-geo-alias-location)
+ [米国の州](#rrsets-values-geo-alias-sublocation)
+ [ヘルスチェック](#rrsets-values-geo-alias-associate-with-health-check)
+ [ターゲットの正常性の評価](#rrsets-values-geo-alias-evaluate-target-health)
+ [記録 ID](#rrsets-values-geo-alias-set-id)
## ルーティングポリシー
[**位置情報**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
位置情報レコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
トラフィックをルーティングする AWS リソースに基づいて、該当する値を選択します。位置情報レコードのグループ内のすべてのレコードに同じ値を選択します。
**API Gateway のカスタムリージョン API またはエッジ最適化 API**
[**A — IPv4 アドレス**] を選択します。
**Amazon VPC インターフェイスのエンドポイント**
[**A — IPv4 アドレス**] を選択します。
**CloudFront 配信**
[**A — IPv4 アドレス**] を選択します。
ディストリビューションに対して IPv6 が有効になっている場合は、2 つのレコードを作成します。1 つは [**タイプ**] として [**A — IPv4 アドレス**] の値を持つもの、もう 1つは [**AAAA — IPv6 アドレス**] の値を持つものとします。
**App Runner サービス**
[**A — IPv4 アドレス**] を選択します。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**A — IPv4 アドレス**] を選択します。
**ELB ロードバランサー**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**Amazon S3 バケット**
[**A — IPv4 アドレス**] を選択します。
**OpenSearch Service**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**このホストゾーン内の別のレコード**
エイリアスを作成するレコードのタイプを選択します。[**NS**] および [**SOA**] 以外のすべてのタイプがサポートされます。
ホストゾーン (*Zone Apex* といいます) と同じ名前のエイリアスレコードを作成する場合、[**タイプ**] の値が [**CNAME**] のレコードにトラフィックをルーティングすることはできません。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、Zone Apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
## 値/トラフィックのルーティング先
リストから選択する値、または フィールドに入力する値は、トラフィックをルーティングする AWS リソースによって異なります。
ターゲットにできる AWS リソースの詳細については、「」を参照してください[への値/ルートトラフィック](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target)。
特定の AWS リソースにトラフィックをルーティングするように Route 53 を設定する方法の詳細については、「」を参照してください[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)。
## ロケーション
クエリの発信元の場所に基づいて DNS クエリに応答するように Route 53 を設定する場合は、Route 53 がこのレコードの設定を使用して応答する対象の大陸または国を選択します。Route 53 が米国の各州について DNS クエリに応答する場合は、[**ロケーション**] リストから [**米国**] を選択し、[**米国の州**] リストから州を選択します。
プライベートホストゾーンの場合は、リソース AWS リージョン がある に最も近い大陸、国、またはサブディビジョンを選択します。例えば、リソースが us-east-1 にある場合であれば、北米、米国、またはバージニアを指定します。
**重要**
[**ロケーション**] に関する [**デフォルト**] の値を持つ位置情報レコードを 1 つ作成することをお勧めします。これにより、レコードを作成していない地理的場所および Route 53 が位置を識別できない IP アドレスをカバーできます。
[**レコード名**] および [**レコードタイプ**] の値が位置情報コードと同じである非位置情報レコードを作成することはできません。
詳細については、「[位置情報ルーティング](routing-policy-geo.md)」を参照してください
Amazon Route 53 が各大陸に関連付ける国を次に示します。国コードは、ISO 3166 のものです。詳細については、Wikipedia の記事、「[ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)」を参照してください。
**アフリカ (AF)**
AO、BF、BI、BJ、BW、CD、CF、CG、CI、CM、CV、DJ、DZ、EG、ER、ET、GA、GH、GM、GN、GQ、GW、KE、KM、LR、LS、LY、MA、MG、ML、MR、MU、MW、MZ、NA、NE、NG、RE、RW、SC、SD、SH、SL、SN、SO、SS、ST、SZ、TD、TG、TN、TZ、UG、YT、ZA、ZM、ZW
**南極 (AN)**
AQ、GS、TF
**アジア (AS)**
AE、AF、AM、AZ、BD、BH、BN、BT、CC、CN、GE、HK、ID、IL、IN、IO、IQ、IR、JO、JP、KG、KH、KP、KR、KW、KZ、LA、LB、LK、MM、MN、MO、MV、MY、NP、OM、PH、PK、PS、QA、SA、SG、SY、TH、TJ、TM、TW、UZ、VN、YE
**欧州 (EU)**
AD、AL、AT、AX、BA、BE、BG、BY、CH、CY、CZ、DE、DK、EE、ES、FI、FO、FR、GB、GG、GI、GR、HR、HU、IE、IM、IS、IT、JE、LI、LT、LU、LV、MC、MD、ME、MK、MT、NL、NO、PL、PT、RO、RS、RU、SE、SI、SJ、SK、SM、TR、UA、VA、XK
一部のプロバイダーは、TR がアジアにあると見なしており、IP アドレスにはそれが反映されます。
**北米 (NA)**
AG、AI、AW、BB、BL、BM、BQ、BS、BZ、CA、CR、CU、CW、DM、DO、GD、GL、GP、GT、HN、HT、JM、KN、KY、LC、MF、MQ、MS、MX、NI、PA、PM、PR、SV、SX、TC、TT、US、VC、VG、VI
**オセアニア (OC)**
AS、AU、CK、FJ、FM、GU、KI、MH、MP、NC、NF、NR、NU、NZ、PF、PG、PN、PW、SB、TK、TL、TO、TV、UM、VU、WF、WS
**南米 (SA)**
AR、BO、BR、CL、CO、EC、FK、GF、GY、PE、PY、SR、UY、VE
**注記**
Route 53 では、以下の国の位置情報レコードの作成をサポートしていません。ブーベ島 (BV)、クリスマス島 (CX)、西サハラ (EH)、ハード島とマクドナルド諸島 (HM)。これらの国の IP アドレスに関するデータは利用できません。
## 米国の州
クエリの発信元である米国の州に基づいて DNS クエリに応答するように Route 53 を設定する場合は、[**米国の州**] リストから州を選択します。米国の海外領土 (プエルトリコなど) は [**Location (ロケーション)**] リストに国として表示されます。
**重要**
一部の IP アドレスは、米国と関連付けられていますが、個々の州とは関連付けられていません。米国のすべての州に対するレコードを作成する場合は、これらの関連付けられていない IP アドレスのクエリをルーティングするために、米国のレコードも作成することをお勧めします。米国のレコードを作成しない場合、Route 53 は関連付けられていない米国の IP アドレスからの DNS クエリに対して、デフォルトの位置情報レコードの設定 (作成している場合) または "応答なし" の応答を使用して応答します。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にあるエイリアスレコードまたはレコードの **[Evaluate target health]** (ターゲットのヘルスを評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
位置情報レコードで、エンドポイントが正常でない場合、Route 53 は、より大きい、関連付けられた地理的リージョンのレコードを探します。例えば、米国の 1 つの州、米国、北米、およびすべての場所 ([**Location**] が [**Default**]) のレコードがあるとします。州のレコードのエンドポイントが正常でない場合、Route 53 は、正常なエンドポイントがあるレコードが見つかるまで、米国、北米、すべての場所のレコードを、この順序で確認します。すべての場所のレコードを確認しても、適用可能なレコードがすべて正常でない場合、Route 53 は最小の地理的リージョンのレコードの値を使用して DNS クエリに応答します。
## ターゲットの正常性の評価
Route 53 で、このレコードを使用して [**エンドポイント**] で指定されたリソースの正常性を確認することによって DNS クエリに応答するかどうかを判定する場合は、[**Yes**] を選択します。
次の点に注意してください。
**API Gateway のカスタムリージョン API とエッジ最適化 API**
エンドポイントが API Gateway カスタムリージョン API またはエッジ最適化 API である場合、[**Evaluate target health**] (ターゲットヘルスを評価) を [**Yes**] (はい) に設定するための特別な要件はありません。
**CloudFront ディストリビューション**
エンドポイントが CloudFront ディストリビューションの場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定することはできません。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**エンドポイント**] で Elastic Beanstalk 環境を指定し、その環境に ELB ロードバランサーが含まれている場合、Elastic Load Balancing はクエリをロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみルーティングします。(複数の Amazon EC2 インスタンスが含まれている場合、環境には自動的に ELB ロードバランサーが含まれます。) [**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な Amazon EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他に利用可能なリソースがあれば、そこにクエリをルーティングします。
環境に 1 つの Amazon EC2 インスタンスが含まれている場合、特別な要件はありません。
**ELB ロードバランサー**
ヘルスチェックの動作はロードバランサーのタイプによって異なります。
+ [**Classic Load Balancers**] – [**エンドポイント**] で ELB Classic Load Balancer を指定した場合、Elastic Load Balancing は、ロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみクエリをルーティングします。[**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他のリソースにクエリをルーティングします。
+ **アプリケーションと Network Load Balancer** – ELB アプリケーションまたは Network Load Balancer を指定し、[**ターゲットの正常性の評価**] を **Yes** に設定すると、Route 53 は､ロードバランサーに関連付けられているターゲットグループの正常性に基づいて､クエリをロードバランサーにルーティングします。
+ アプリケーションまたはNetwork Load Balancerを正常であると見なすには、ターゲットを含むすべてのターゲットグループに少なくとも 1 つの正常なターゲットが含まれている必要があります。ターゲットグループに異常なターゲットのみが含まれている場合、ロードバランサーは異常であるとみなされ、Route 53 はクエリを他のリソースにルーティングします。
+ 登録されたターゲットを持たないターゲットグループは異常であるとみなされます｡
ロードバランサーを作成するときは、Elastic Load Balancing のヘルスチェックの設定を行います。これは Route 53 のヘルスチェックではありませんが、同様の機能を実行します。ELB ロードバランサーに登録する EC2 インスタンスに対しては Route 53 のヘルスチェックを作成しないでください。
**S3 バケット**
エンドポイントが S3 バケットである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**Amazon VPC インターフェイスのエンドポイント**
エンドポイントが Amazon VPC インターフェイスエンドポイントである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**同じホストゾーンの他のレコード**
Endpoint で指定した AWS リソース****がレコードまたはレコードのグループ (加重レコードのグループなど) で、別のエイリアスレコードではない場合は、ヘルスチェックをエンドポイント内のすべてのレコードに関連付けることをお勧めします。詳細については、「[ヘルスチェックを省略するとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting)」を参照してください。
## 記録 ID
位置情報レコードのグループ内で、このレコードを一意に識別する値を入力します。
# 地理的近接性レコードに固有の値
地理的近接性レコードを作成するときは、以下の値を指定します。
**Topics**
+ [ルーティングポリシー](#rrsets-values-geoprox-routing-policy)
+ [レコード名](#rrsets-values-geoprox-name)
+ [レコードタイプ](#rrsets-values-geoprox-type)
+ [TTL (秒)](#rrsets-values-geoprox-ttl)
+ [値/トラフィックのルーティング先](#rrsets-values-geoprox-value)
+ [エンドポイントの場所](#rrsets-values-geoprox-endpoint-location)
+ [Bias (バイアス)](#rrsets-values-geoprox-bias)
+ [ヘルスチェック](#rrsets-values-geoprox-associate-with-health-check)
+ [記録 ID](#rrsets-values-geoprox-set-id)
## ルーティングポリシー
**[地理的近接性]** を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**名前**] フィールドに値 (@ 記号など) を入力しないでください。
地理的近接性レコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-shared.md#rrsets-values-common-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
地理的近接性レコードのグループ内のすべてのレコードに同じ値を選択します。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これにより、レイテンシーが短縮され、Route 53 サービスの請求額が削減されます。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
このレコードをヘルスチェックに関連付ける場合、ヘルスステータスの変化にクライアントがすばやく対応できるよう、60 秒以下の TTL を指定することをお勧めします。
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。[**CNAME**] を除くすべてのタイプは、複数の値を入力できます。各値は個別の行に入力します。
次の値にトラフィックをルーティングするか、次の値を指定できます。
+ **A — IPv4 アドレス**
+ **AAAA — IPv6 アドレス**
+ **CAA —認証局の承認**
+ **CNAME — 正規名**
+ **MX — メール交換**
+ **NAPTR — 名前付け権限ポインタ**
+ **PTR — ポインタ**
+ **SPF — センダーポリシーフレームワーク**
+ **SRV — サービスロケーター**
+ **TXT — テキスト**
上記の値の詳細については、「[common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value)」(値/トラフィックのルーティング先) を参照してください。
## エンドポイントの場所
次の方法のいずれかを使用して、リソースエンドポイント場所を指定できます。
**カスタム座標**
地理的領域の経度と緯度を指定します。
**AWS リージョン**
**[場所]** リストから使用可能なリージョンを選択します。
リージョンの詳細については、「[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
**AWS ローカルゾーングループ**
**[場所]** リストから使用可能なローカルゾーングループを選択します。
ローカルゾーンの詳細については、「*AWS ローカルゾーンユーザーガイド*」の「[利用可能なローカルゾーン](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html)」を参照してください。ローカルゾーングループは、通常、終了文字がないローカルゾーンです。例えば、ローカルゾーンが `us-east-1-bue-1a` の場合、ローカルゾーングループは `us-east-1-bue-1` です。
[describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) CLI コマンドを使用して、特定のローカルゾーンのローカルゾーングループを特定することもできます。
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
このコマンドは `"GroupName": "us-west-2-den-1"` を返して、ローカルゾーン `us-west-2-den-1a` がローカルゾーングループ `us-west-2-den-1` に属するように指定します。
**[レコード名]** および **[レコードタイプ]** の値が地理的近接性レコードと同じである非地理的近接性レコードを作成することはできません。
同じレコード名とレコードタイプに同じ場所を指定する 2 つの地理的近接性リソースレコードセットを作成することもできません。
## Bias (バイアス)
バイアスは、リソースにトラフィックをルーティングする Route 53 から地理的領域のサイズを拡大または縮小します。正のバイアスは領域を拡張し、負のバイアスは領域を縮小します。詳細については、「[Amazon Route 53 がバイアスを使用してトラフィックをルーティングする方法](routing-policy-geoproximity.md#routing-policy-geoproximity-bias)」を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、地理的近接性エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にある 1 つのエイリアスレコードまたは複数のレコードの **[ターゲットの正常性の評価]** で、**[はい]** を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
地理的近接性レコードの場合、エンドポイントが異常になると、正常が続いている最も近いエンドポイントを Route 53 が探します。
## 記録 ID
地理的近接性レコードのグループ内で、このレコードを一意に識別する値を入力します。
# 地理的近接性エイリアスレコードに固有の値
地理的近接性エイリアスレコードを作成するときは、以下の値を指定します。
詳細については、「[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)」を参照してください。
**Topics**
+ [ルーティングポリシー](#rrsets-values-geoprox-alias-routing-policy)
+ [レコード名](#rrsets-values-geoprox-alias-name)
+ [レコードタイプ](#rrsets-values-geoprox-alias-type)
+ [値/トラフィックのルーティング先](#rrsets-values-geoprox-alias-alias-target)
+ [エンドポイントの場所](#rrsets-values-geoprox-alias-endpoint-location)
+ [Bias (バイアス)](#rrsets-values-geoprox-alias-bias)
+ [ヘルスチェック](#rrsets-values-geoprox-alias-associate-with-health-check)
+ [ターゲットの正常性の評価](#rrsets-values-geoprox-alias-evaluate-target-health)
+ [記録 ID](#rrsets-values-geoprox-alias-set-id)
## ルーティングポリシー
**[地理的近接性]** を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
地理的近接性レコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
トラフィックをルーティングする AWS リソースに基づいて、該当する値を選択します。地理的近接性レコードのグループ内のすべてのレコードに同じ値を選択します。
**API Gateway のカスタムリージョン API またはエッジ最適化 API**
[**A — IPv4 アドレス**] を選択します。
**Amazon VPC インターフェイスのエンドポイント**
[**A — IPv4 アドレス**] を選択します。
**CloudFront 配信**
[**A — IPv4 アドレス**] を選択します。
ディストリビューションに対して IPv6 が有効になっている場合は、2 つのレコードを作成します。1 つは [**タイプ**] として [**A — IPv4 アドレス**] の値を持つもの、もう 1つは [**AAAA — IPv6 アドレス**] の値を持つものとします。
**App Runner サービス**
[**A — IPv4 アドレス**] を選択します。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**A — IPv4 アドレス**] を選択します。
**ELB ロードバランサー**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**Amazon S3 バケット**
[**A — IPv4 アドレス**] を選択します。
**OpenSearch Service**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**このホストゾーン内の別のレコード**
エイリアスを作成するレコードのタイプを選択します。[**NS**] および [**SOA**] 以外のすべてのタイプがサポートされます。
ホストゾーン (*Zone Apex* といいます) と同じ名前のエイリアスレコードを作成する場合、[**タイプ**] の値が [**CNAME**] のレコードにトラフィックをルーティングすることはできません。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、Zone Apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
## 値/トラフィックのルーティング先
リストから選択する値、または フィールドに入力する値は、トラフィックをルーティングする AWS リソースによって異なります。
ターゲットにできる AWS リソースの詳細については、「」を参照してください[への値/ルートトラフィック](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target)。
特定の AWS リソースにトラフィックをルーティングするように Route 53 を設定する方法の詳細については、「」を参照してください[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)。
## エンドポイントの場所
次の方法のいずれかを使用して、リソースエンドポイント場所を指定できます。
**カスタム座標**
地理的領域の経度と緯度を指定します。
**AWS リージョン**
**[場所]** リストから使用可能なリージョンを選択します。
リージョンの詳細については、「[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
**AWS ローカルゾーングループ**
**[場所]** リストから使用可能なローカルゾーンリージョンを選択します。
ローカルゾーンの詳細については、「*AWS ローカルゾーンユーザーガイド*」の「[利用可能なローカルゾーン](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html)」を参照してください。ローカルゾーングループは、通常、終了文字がないローカルゾーンです。例えば、ローカルゾーンが `us-east-1-bue-1a` の場合、ローカルゾーングループは `us-east-1-bue-1` です。
[describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) CLI コマンドを使用して、特定のローカルゾーンのローカルゾーングループを特定することもできます。
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
このコマンドは `"GroupName": "us-west-2-den-1"` を返して、ローカルゾーン `us-west-2-den-1a` がローカルゾーングループ `us-west-2-den-1` に属するように指定します。
**[レコード名]** および **[レコードタイプ]** の値が地理的近接性レコードと同じである非地理的近接性レコードを作成することはできません。
同じレコード名とレコードタイプに同じ場所を指定する 2 つの地理的近接性リソースレコードセットを作成することもできません。
詳細については、available-local-zones.html を参照してください
## Bias (バイアス)
バイアスは、リソースにトラフィックをルーティングする Route 53 から地理的領域のサイズを拡大または縮小します。正のバイアスは領域を拡張し、負のバイアスは領域を縮小します。詳細については、「[Amazon Route 53 がバイアスを使用してトラフィックをルーティングする方法](routing-policy-geoproximity.md#routing-policy-geoproximity-bias)」を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、地理的近接性エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にある 1 つのエイリアスレコードまたは複数のレコードの **[ターゲットの正常性の評価]** で、**[はい]** を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
地理的近接性レコードの場合、エンドポイントが異常になると、正常が続いている最も近いエンドポイントを Route 53 が探します。
## ターゲットの正常性の評価
Route 53 で、このレコードを使用して [**エンドポイント**] で指定されたリソースの正常性を確認することによって DNS クエリに応答するかどうかを判定する場合は、[**Yes**] を選択します。
次の点に注意してください。
**API Gateway のカスタムリージョン API とエッジ最適化 API**
エンドポイントが API Gateway カスタムリージョン API またはエッジ最適化 API である場合、[**Evaluate target health**] (ターゲットヘルスを評価) を [**Yes**] (はい) に設定するための特別な要件はありません。
**CloudFront ディストリビューション**
エンドポイントが CloudFront ディストリビューションの場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定することはできません。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**エンドポイント**] で Elastic Beanstalk 環境を指定し、その環境に ELB ロードバランサーが含まれている場合、Elastic Load Balancing はクエリをロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみルーティングします。(複数の Amazon EC2 インスタンスが含まれている場合、環境には自動的に ELB ロードバランサーが含まれます。) [**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な Amazon EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他に利用可能なリソースがあれば、そこにクエリをルーティングします。
環境に 1 つの Amazon EC2 インスタンスが含まれている場合、特別な要件はありません。
**ELB ロードバランサー**
ヘルスチェックの動作はロードバランサーのタイプによって異なります。
+ [**Classic Load Balancers**] – [**エンドポイント**] で ELB Classic Load Balancer を指定した場合、Elastic Load Balancing は、ロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみクエリをルーティングします。[**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他のリソースにクエリをルーティングします。
+ **アプリケーションと Network Load Balancer** – ELB アプリケーションまたは Network Load Balancer を指定し、[**ターゲットの正常性の評価**] を **Yes** に設定すると、Route 53 は､ロードバランサーに関連付けられているターゲットグループの正常性に基づいて､クエリをロードバランサーにルーティングします。
+ アプリケーションまたはNetwork Load Balancerを正常であると見なすには、ターゲットを含むすべてのターゲットグループに少なくとも 1 つの正常なターゲットが含まれている必要があります。ターゲットグループに異常なターゲットのみが含まれている場合、ロードバランサーは異常であるとみなされ、Route 53 はクエリを他のリソースにルーティングします。
+ 登録されたターゲットを持たないターゲットグループは異常であるとみなされます｡
ロードバランサーを作成するときは、Elastic Load Balancing のヘルスチェックの設定を行います。これは Route 53 のヘルスチェックではありませんが、同様の機能を実行します。ELB ロードバランサーに登録する EC2 インスタンスに対しては Route 53 のヘルスチェックを作成しないでください。
**S3 バケット**
エンドポイントが S3 バケットである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**Amazon VPC インターフェイスのエンドポイント**
エンドポイントが Amazon VPC インターフェイスエンドポイントである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**同じホストゾーンの他のレコード**
Endpoint で指定した AWS リソース****がレコードまたはレコードのグループ (加重レコードのグループなど) で、別のエイリアスレコードではない場合は、ヘルスチェックをエンドポイント内のすべてのレコードに関連付けることをお勧めします。詳細については、「[ヘルスチェックを省略するとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting)」を参照してください。
## 記録 ID
地理的近接性レコードのグループ内で、このレコードを一意に識別する値を入力します。
# レイテンシーレコードに固有の値
レイテンシーレコードを作成するときは、以下の値を指定します。
**Topics**
+ [ルーティングポリシー](#rrsets-values-latency-routing-policy)
+ [レコード名](#rrsets-values-latency-name)
+ [レコードタイプ](#rrsets-values-latency-type)
+ [TTL (秒)](#rrsets-values-latency-ttl)
+ [値/トラフィックのルーティング先](#rrsets-values-latency-value)
+ [リージョン](#rrsets-values-latency-region)
+ [ヘルスチェック](#rrsets-values-latency-associate-with-health-check)
+ [記録 ID](#rrsets-values-latency-set-id)
## ルーティングポリシー
[**レイテンシー**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
レイテンシーレコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-shared.md#rrsets-values-common-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
Route 53 が DNS クエリに応答する方法に基づいて、**タイプ**の値を選択します。
レイテンシーレコードのグループ内のすべてのレコードに同じ値を選択します。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これにより、レイテンシーが短縮され、Route 53 サービスの請求額が削減されます。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
このレコードをヘルスチェックに関連付ける場合、ヘルスステータスの変化にクライアントがすばやく対応できるよう、60 秒以下の TTL を指定することをお勧めします。
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。[**CNAME**] を除くすべてのタイプは、複数の値を入力できます。各値は個別の行に入力します。
次の値にトラフィックをルーティングするか、次の値を指定できます。
+ **A — IPv4 アドレス**
+ **AAAA — IPv6 アドレス**
+ **CAA —認証局の承認**
+ **CNAME — 正規名**
+ **MX — メール交換**
+ **NAPTR — 名前付け権限ポインタ**
+ **PTR — ポインタ**
+ **SPF — センダーポリシーフレームワーク**
+ **SRV — サービスロケーター**
+ **TXT — テキスト**
上記の値の詳細については、「[common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value)」(値/トラフィックのルーティング先) を参照してください。
## リージョン
このレコードで指定されたリソースが存在する Amazon EC2 リージョン。Route 53 によって、指定したその他の値に基づく Amazon EC2 リージョンが推奨されます。これは、プライベートホストゾーンにも適用されます。この値は変更しないことをお勧めします。
次の点に注意してください。
+ 作成できるレイテンシーレコードは、各 Amazon EC2 リージョンにつき 1 つだけです。
+ すべての Amazon EC2 リージョンに対してレイテンシーレコードを作成する必要はありません。レイテンシーレコードを作成したリージョンの中から、レイテンシーの最も小さいリージョンが Route 53 によって選択されます。
+ [**レコード名**] および [**レコードタイプ**] の値がレイテンシーレコードと同じである非レイテンシーレコードを作成することはできません。
+ **cn-north-1** リージョンのタグ付きのレコードを作成した場合、Route 53 は、レイテンシーにかかわらず、常にこのレコードを使用して、中国内からのクエリに応答します。
レイテンシーレコードの使用の詳細については、「[レイテンシーに基づくルーティング](routing-policy-latency.md)」を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にあるエイリアスレコードまたはレコードの **[Evaluate target health]** (ターゲットのヘルスを評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
## 記録 ID
レイテンシーレコードのグループ内で、このレコードを一意に識別する値を入力します。
# レイテンシーエイリアスレコードに固有の値
レイテンシーエイリアスレコードを作成するときは、以下の値を指定します。
詳細については、「[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)」を参照してください。
**Topics**
+ [ルーティングポリシー](#rrsets-values-latency-alias-routing-policy)
+ [レコード名](#rrsets-values-latency-alias-name)
+ [レコードタイプ](#rrsets-values-latency-alias-type)
+ [値/トラフィックのルーティング先](#rrsets-values-latency-alias-alias-target)
+ [リージョン](#rrsets-values-latency-alias-region)
+ [ヘルスチェック](#rrsets-values-latency-alias-associate-with-health-check)
+ [ターゲットの正常性の評価](#rrsets-values-latency-alias-evaluate-target-health)
+ [記録 ID](#rrsets-values-latency-alias-set-id)
## ルーティングポリシー
[**レイテンシー**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
レイテンシーレコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
トラフィックをルーティングする AWS リソースに基づいて、該当する値を選択します。
**API Gateway のカスタムリージョン API またはエッジ最適化 API**
[**A — IPv4 アドレス**] を選択します。
**Amazon VPC インターフェイスのエンドポイント**
[**A — IPv4 アドレス**] を選択します。
**CloudFront 配信**
[**A — IPv4 アドレス**] を選択します。
ディストリビューションに対して IPv6 が有効になっている場合は、2 つのレコードを作成します。1 つは [**タイプ**] として [**A — IPv4 アドレス**] の値を持つもの、もう 1つは [**AAAA — IPv6 アドレス**] の値を持つものとします。
**App Runner サービス**
[**A — IPv4 アドレス**] を選択します。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**A — IPv4 アドレス**] を選択します。
**ELB ロードバランサー**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**Amazon S3 バケット**
[**A — IPv4 アドレス**] を選択します。
**OpenSearch Service**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**このホストゾーン内の別のレコード**
エイリアスを作成するレコードのタイプを選択します。[**NS**] および [**SOA**] 以外のすべてのタイプがサポートされます。
ホストゾーン (*Zone Apex* といいます) と同じ名前のエイリアスレコードを作成する場合、[**タイプ**] の値が [**CNAME**] のレコードにトラフィックをルーティングすることはできません。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、Zone Apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
レイテンシーレコードのグループ内のすべてのレコードに同じ値を選択します。
## 値/トラフィックのルーティング先
リストから選択する値、または フィールドに入力する値は、トラフィックをルーティングする AWS リソースによって異なります。
ターゲットにできる AWS リソースの詳細については、[値/ルートトラフィックのエイリアスレコードの一般的な値](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target)を参照してください。
特定の AWS リソースにトラフィックをルーティングするように Route 53 を設定する方法の詳細については、「」を参照してください[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)。
## リージョン
このレコードで指定されたリソースが存在する Amazon EC2 リージョン。Route 53 によって、指定したその他の値に基づく Amazon EC2 リージョンが推奨されます。これは、プライベートホストゾーンにも適用されます。この値は変更しないことをお勧めします。
次の点に注意してください。
+ 作成できるレイテンシーレコードは、各 Amazon EC2 リージョンにつき 1 つだけです。
+ すべての Amazon EC2 リージョンに対してレイテンシーレコードを作成する必要はありません。レイテンシーレコードを作成したリージョンの中から、レイテンシーの最も小さいリージョンが Route 53 によって選択されます。
+ [**レコード名**] および [**レコードタイプ**] の値がレイテンシーレコードと同じである非レイテンシーレコードを作成することはできません。
+ **cn-north-1** リージョンのタグ付きのレコードを作成した場合、Route 53 は、レイテンシーにかかわらず、常にこのレコードを使用して、中国内からのクエリに応答します。
レイテンシーレコードの使用の詳細については、「[レイテンシーに基づくルーティング](routing-policy-latency.md)」を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にあるエイリアスレコードまたはレコードの **[Evaluate target health]** (ターゲットのヘルスを評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
## ターゲットの正常性の評価
Route 53 で、このレコードを使用して [**エンドポイント**] で指定されたリソースの正常性を確認することによって DNS クエリに応答するかどうかを判定する場合は、[**Yes**] を選択します。
次の点に注意してください。
**API Gateway のカスタムリージョン API とエッジ最適化 API**
エンドポイントが API Gateway カスタムリージョン API またはエッジ最適化 API である場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**CloudFront ディストリビューション**
エンドポイントが CloudFront ディストリビューションの場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定することはできません。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**エンドポイント**] で Elastic Beanstalk 環境を指定し、その環境に ELB ロードバランサーが含まれている場合、Elastic Load Balancing はクエリをロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみルーティングします。(複数の Amazon EC2 インスタンスが含まれている場合、環境には自動的に ELB ロードバランサーが含まれます。) [**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な Amazon EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他に利用可能なリソースがあれば、そこにクエリをルーティングします。
環境に 1 つの Amazon EC2 インスタンスが含まれている場合、特別な要件はありません。
**ELB ロードバランサー**
ヘルスチェックの動作はロードバランサーのタイプによって異なります。
+ [**Classic Load Balancers**] – [**エンドポイント**] で ELB Classic Load Balancer を指定した場合、Elastic Load Balancing は、ロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみクエリをルーティングします。[**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他のリソースにクエリをルーティングします。
+ **アプリケーションと Network Load Balancer** – ELB アプリケーションまたは Network Load Balancer を指定し、[**ターゲットの正常性の評価**] を **Yes** に設定すると、Route 53 は､ロードバランサーに関連付けられているターゲットグループの正常性に基づいて､クエリをロードバランサーにルーティングします。
+ アプリケーションまたはNetwork Load Balancerを正常であると見なすには、ターゲットを含むすべてのターゲットグループに少なくとも 1 つの正常なターゲットが含まれている必要があります。ターゲットグループに異常なターゲットのみが含まれている場合、ロードバランサーは異常であるとみなされ、Route 53 はクエリを他のリソースにルーティングします。
+ 登録されたターゲットを持たないターゲットグループは異常であるとみなされます｡
ロードバランサーを作成するときは、Elastic Load Balancing のヘルスチェックの設定を行います。これは Route 53 のヘルスチェックではありませんが、同様の機能を実行します。ELB ロードバランサーに登録する EC2 インスタンスに対しては Route 53 のヘルスチェックを作成しないでください。
**S3 バケット**
エンドポイントが S3 バケットである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**Amazon VPC インターフェイスのエンドポイント**
エンドポイントが Amazon VPC インターフェイスエンドポイントである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**同じホストゾーンの他のレコード**
Endpoint で指定した AWS リソース****がレコードまたはレコードのグループ (加重レコードのグループなど) で、別のエイリアスレコードではない場合は、ヘルスチェックをエンドポイント内のすべてのレコードに関連付けることをお勧めします。詳細については、「[ヘルスチェックを省略するとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting)」を参照してください。
## 記録 ID
レイテンシーレコードのグループ内で、このレコードを一意に識別する値を入力します。
# IP ベースレコード特有の値
IP ベースレコードを作成する際は、以下の値を指定します。
**注記**
プライベートホストゾーン内に IP ベースレコードを作成することは可能ですが、動作は保証されていません。
**Topics**
+ [ルーティングポリシー](#rrsets-values-ipbased-routing-policy)
+ [レコード名](#rrsets-values-ibased-name)
+ [レコードタイプ](#rrsets-values-ibased-type)
+ [TTL (秒)](#rrsets-values-ibased-ttl)
+ [値/トラフィックのルーティング先](#rrsets-values-ibased-value)
+ [場所](#rrsets-values-ibased-location)
+ [ヘルスチェック](#rrsets-values-ibased-associate-with-health-check)
+ [記録 ID](#rrsets-values-ipbased-set-id)
## ルーティングポリシー
**[IP-based]** (IP ベース) を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
IP ベースレコードのグループ内で、すべてのレコードに同じ名前を入力します。
**CNAME レコード**
[**レコードタイプ**] の値が [**CNAME**] のレコードを作成する場合、レコードの名前をホストゾーンの名前と同じにすることはできません。
**特殊文字**
a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。
**ワイルドカード文字**
名前にはアスタリスク (\$1) を使用できます。DNSは、名前の中の位置に応じて、「\$1」をワイルドカードまたはアスタリスク (ASCII 42) として処理します。詳細については、「[ホストゾーンおよびレコード名のアスタリスク (\$1) を使用する](DomainNameFormat.md#domain-name-format-asterisk)」を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
Route 53 が DNS クエリに応答する方法に基づいて、**タイプ**の値を選択します。
IP ベースレコードのグループ内のすべてのレコードに対し、同じ値を選択します。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これは、レイテンシーを減らし、Route 53 サービスの請求金額を下げる効果があります。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
このレコードをヘルスチェックに関連付ける場合、ヘルスステータスの変化にクライアントがすばやく対応できるよう、60 秒以下の TTL を指定することをお勧めします。
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。[**CNAME**] を除くすべてのタイプは、複数の値を入力できます。各値は個別の行に入力します。
次の値にトラフィックをルーティングするか、次の値を指定できます。
+ **A — IPv4 アドレス**
+ **AAAA — IPv6 アドレス**
+ **CAA —認証局の承認**
+ **CNAME — 正規名**
+ **MX — メール交換**
+ **NAPTR — 名前付け権限ポインタ**
+ **PTR — ポインタ**
+ **SPF — センダーポリシーフレームワーク**
+ **SRV — サービスロケーター**
+ **TXT — テキスト**
上記の値の詳細については、[値/トラフィックのルーティング先](resource-record-sets-values-shared.md#rrsets-values-common-value)「[common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value)」(値/トラフィックのルーティング先) を参照してください。
## 場所
ユーザーがこのレコード内で指定し、また CIDR ロケーション内の CIDR ブロック値によっても指定されるリソースがある、CIDR ロケーションの名前。
IP ベースレコードの使用の詳細については、「[IP ベースルーティング](routing-policy-ipbased.md)」を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、IP ベースエイリアス、レイテンシーエイリアス、または加重エイリアスレコードのグループ内のレコード、またはエイリアスレコードのための **[Evaluate target health]** (ターゲットの正常性の評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
## 記録 ID
IP ベースレコードのグループ内で、このレコードを一意に識別する値を入力します。
# IP ベースエイリアスレコードに特有の値
IP ベースエイリアスレコードを作成する際は、以下の値を指定します。
**注記**
プライベートホストゾーン内に IP ベースエイリアスレコードを作成することは可能ですが、サポートはされていません。
詳細については、「[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)」を参照してください。
**Topics**
+ [ルーティングポリシー](#rrsets-values-ipbased-alias-routing-policy)
+ [レコード名](#rrsets-values-ipbased-alias-name)
+ [レコードタイプ](#rrsets-values-ipbased-alias-type)
+ [値/トラフィックのルーティング先](#rrsets-values-ipbased-alias-alias-target)
+ [ロケーション](#rrsets-values-ipbased-alias-location)
+ [ヘルスチェック](#rrsets-values-ipbased-alias-associate-with-health-check)
+ [ターゲットの正常性の評価](#rrsets-values-ipbased-alias-evaluate-target-health)
+ [記録 ID](#rrsets-values-ipbased-alias-set-id)
## ルーティングポリシー
**[IP-based]** (IP ベース) を選択します。
**注記**
プライベートホストゾーン内に IP ベースエイリアスレコードを作成することは可能ですが、サポートはされていません。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
IP ベースレコードのグループ内で、すべてのレコードに同じ名前を入力します。
**CNAME レコード**
[**レコードタイプ**] の値が [**CNAME**] のレコードを作成する場合、レコードの名前をホストゾーンの名前と同じにすることはできません。
**CloudFront ディストリビューションと Amazon S3 バケットへのエイリアス**
指定する値は、トラフィックをルーティングする AWS リソースによって異なります。
+ **CloudFront ディストリビューション** – ディストリビューションには、レコードの名前と一致する代替ドメイン名が含まれる必要があります。例えば、レコード名が **acme.example.com** の場合、CloudFront ディストリビューションには代替ドメイン名の 1 つとして **acme.example.com** が含まれる必要があります。詳細については、*Amazon CloudFront デベロッパーガイド*の「[代替ドメイン名 (CNAME) を使用する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)」を参照してください。
+ **Amazon S3 バケット** – レコード名は、Amazon S3 バケット名と一致する必要があります。例えば、 バケット名が [**acme.example.com**] である場合、このレコード名も [**acme.example.com**] である必要があります。
また、ウェブサイトホスティング用にバケットを設定する必要があります。詳細については、*Amazon Simple Storage Service ユーザーガイド*の[ウェブサイトホスティング用にバケットを設定する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html)を参照してください。
**特殊文字**
a～z、0～9、- (ハイフン) 以外の文字を指定する方法、および国際化されたドメイン名を指定する方法については、「[DNS ドメイン名の形式](DomainNameFormat.md)」を参照してください。
**ワイルドカード文字**
名前にはアスタリスク (\$1) を使用できます。DNSは、名前の中の位置に応じて、「\$1」をワイルドカードまたはアスタリスク (ASCII 42) として処理します。詳細については、「[ホストゾーンおよびレコード名のアスタリスク (\$1) を使用する](DomainNameFormat.md#domain-name-format-asterisk)」を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
トラフィックをルーティングする AWS リソースに基づいて、該当する値を選択します。IP ベースレコードのグループ内のすべてのレコードに対し、同じ値を選択します。
**API Gateway のカスタムリージョン API またはエッジ最適化 API**
[**A — IPv4 アドレス**] を選択します。
**Amazon VPC インターフェイスのエンドポイント**
[**A — IPv4 アドレス**] を選択します。
**CloudFront 配信**
[**A — IPv4 アドレス**] を選択します。
ディストリビューションに対して IPv6 が有効になっている場合は、2 つのレコードを作成します。1 つは [**タイプ**] として [**A — IPv4 アドレス**] の値を持つもの、もう 1つは [**AAAA — IPv6 アドレス**] の値を持つものとします。
**App Runner サービス**
[**A — IPv4 アドレス**] を選択します。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**A — IPv4 アドレス**] を選択します。
**ELB ロードバランサー**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**Amazon S3 バケット**
[**A — IPv4 アドレス**] を選択します。
**OpenSearch Service**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**このホストゾーン内の別のレコード**
エイリアスを作成するレコードのタイプを選択します。[**NS**] および [**SOA**] 以外のすべてのタイプがサポートされます。
ホストゾーン (*Zone Apex* といいます) と同じ名前のエイリアスレコードを作成する場合、[**タイプ**] の値が [**CNAME**] のレコードにトラフィックをルーティングすることはできません。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、Zone Apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
## 値/トラフィックのルーティング先
リストから選択する値、または フィールドに入力する値は、トラフィックをルーティングする AWS リソースによって異なります。
ターゲットにできる AWS リソースの詳細については、[値/ルートトラフィックのエイリアスレコードの一般的な値](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target)を参照してください。
特定の AWS リソースにトラフィックをルーティングするように Route 53 を設定する方法の詳細については、「」を参照してください[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)。
## ロケーション
Route 53 による DNS クエリへの応答を、そのクエリの発信元の場所に基づいて行われるように設定する場合は、Route 53 がこのレコードの設定を使用して応答する対象の CIDR ロケーションを選択します。
**重要**
**[Location]** (ロケーション) の値を「**Default**」(デフォルト) とした IP ベースレコードを、1 つ作成することをお勧めします。これにより、レコードを作成していないロケーション、および Route 53 がロケーションを識別できない IP アドレスをカバーできます。
**[Record name]** (レコード名) および **[Record type]** (レコードタイプ) に IP ベースレコードと同じ値を指定して、非 IP ベースのレコードを作成することはできません。
詳細については、「[IP ベースルーティング](routing-policy-ipbased.md)」を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、IP ベースルーティングエイリアス、レイテンシーエイリアス、または加重エイリアスレコードのグループ内のレコード、またはエイリアスレコードのための **[Evaluate target health]** (ターゲットの正常性の評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
IP ベースエイリアスレコードでエンドポイントが正常でない場合、Route 53 より大きな関連付けられているロケーションからレコードを探します。例えば、米国の 1 つの州、米国、北米、およびすべての場所 ([**Location**] が [**Default**]) のレコードがあるとします。州のレコードのエンドポイントが正常でない場合、Route 53 は、正常なエンドポイントがあるレコードが見つかるまで、米国、北米、すべての場所のレコードを、この順序で確認します。すべての場所のレコードを確認しても、適用可能なレコードがすべて正常でない場合、Route 53 は最小の地理的リージョンのレコードの値を使用して DNS クエリに応答します。
## ターゲットの正常性の評価
Route 53 で、このレコードを使用して [**エンドポイント**] で指定されたリソースの正常性を確認することによって DNS クエリに応答するかどうかを判定する場合は、[**Yes**] を選択します。
次の点に注意してください。
**API Gateway のカスタムリージョン API とエッジ最適化 API**
エンドポイントが API Gateway カスタムリージョン API またはエッジ最適化 API である場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**CloudFront ディストリビューション**
エンドポイントが CloudFront ディストリビューションの場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定することはできません。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**エンドポイント**] で Elastic Beanstalk 環境を指定し、その環境に ELB ロードバランサーが含まれている場合、Elastic Load Balancing はクエリをロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみルーティングします。(複数の Amazon EC2 インスタンスが含まれている場合、環境には自動的に ELB ロードバランサーが含まれます。) [**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な Amazon EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他に利用可能なリソースがあれば、そこにクエリをルーティングします。
環境に 1 つの Amazon EC2 インスタンスが含まれている場合、特別な要件はありません。
**ELB ロードバランサー**
ヘルスチェックの動作はロードバランサーのタイプによって異なります。
+ [**Classic Load Balancers**] – [**エンドポイント**] で ELB Classic Load Balancer を指定した場合、Elastic Load Balancing は、ロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみクエリをルーティングします。[**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他のリソースにクエリをルーティングします。
+ **アプリケーションと Network Load Balancer** – ELB アプリケーションまたは Network Load Balancer を指定し、[**ターゲットの正常性の評価**] を **Yes** に設定すると、Route 53 は､ロードバランサーに関連付けられているターゲットグループの正常性に基づいて､クエリをロードバランサーにルーティングします。
+ アプリケーションまたはNetwork Load Balancerを正常であると見なすには、ターゲットを含むすべてのターゲットグループに少なくとも 1 つの正常なターゲットが含まれている必要があります。ターゲットグループに異常なターゲットのみが含まれている場合、ロードバランサーは異常であるとみなされ、Route 53 はクエリを他のリソースにルーティングします。
+ 登録されたターゲットを持たないターゲットグループは異常であるとみなされます｡
ロードバランサーを作成するときは、Elastic Load Balancing のヘルスチェックの設定を行います。これは Route 53 のヘルスチェックではありませんが、同様の機能を実行します。ELB ロードバランサーに登録する EC2 インスタンスに対しては Route 53 のヘルスチェックを作成しないでください。
**S3 バケット**
エンドポイントが S3 バケットである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**Amazon VPC インターフェイスのエンドポイント**
エンドポイントが Amazon VPC インターフェイスエンドポイントである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**同じホストゾーンの他のレコード**
Endpoint で指定した AWS リソース****がレコードまたはレコードのグループ (加重レコードのグループなど) であるが、別のエイリアスレコードではない場合は、ヘルスチェックをエンドポイント内のすべてのレコードに関連付けることをお勧めします。詳細については、「[ヘルスチェックを省略するとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting)」を参照してください。
## 記録 ID
IP ベースレコードのグループ内で、このレコードを一意に識別する値を入力します。
# 複数値回答レコードに固有の値
複数値回答レコードを作成するときは、以下の値を指定します。
**注記**
複数値回答エイリアスレコードの作成はサポートされていません。
**Topics**
+ [ルーティングポリシー](#rrsets-values-multivalue-routing-policy)
+ [レコード名](#rrsets-values-multivalue-name)
+ [レコードタイプ](#rrsets-values-multivalue-type)
+ [TTL (秒)](#rrsets-values-multivalue-ttl)
+ [値/トラフィックのルーティング先](#rrsets-values-multivalue-value)
+ [ヘルスチェック](#rrsets-values-multivalue-associate-with-health-check)
+ [記録 ID](#rrsets-values-multivalue-set-identifier)
## ルーティングポリシー
[**複数値回答**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
複数値レコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-shared.md#rrsets-values-common-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
[**NS**] と [**CNAME**] を除く任意の値を選択します。
複数値回答レコードのグループ内のすべてのレコードに同じ値を選択します。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これにより、レイテンシーが短縮され、Route 53 サービスの請求額が削減されます。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
このレコードをヘルスチェックに関連付ける場合は、クライアントがヘルスステータスの変化に迅速に応答するように、TTL を 60 秒以下に指定することをお勧めします。
**注記**
同じ名前とタイプの複数値回答レコードを複数作成し、コンソールを使用している場合、**[TTL]** に異なる値を指定すると、Route 53 は､すべてのレコードの **[TTL]** 値を、指定された最後の値に変更します｡
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。複数の値を入力する場合は、各値を個別の行に入力してください。
次の値にトラフィックをルーティングするか、次の値を指定できます。
+ **A — IPv4 アドレス**
+ **AAAA — IPv6 アドレス**
+ **CAA —認証局の承認**
+ **MX — メール交換**
+ **NAPTR — 名前付け権限ポインタ**
+ **PTR — ポインタ**
+ **SPF — センダーポリシーフレームワーク**
+ **SRV — サービスロケーター**
+ **TXT — テキスト**
上記の値の詳細については、「[common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value)」(値/トラフィックのルーティング先) を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、または加重エイリアスレコードのグループ内のレコード、またはエイリアスレコードに対する [**ターゲットの正常性の評価**] に [**Yes**]を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
## 記録 ID
複数値回答レコードのグループに､このレコードを一意に識別する値を入力します。
# 加重レコードに固有の値
加重レコードを作成するときは、以下の値を指定します。
**Topics**
+ [ルーティングポリシー](#rrsets-values-weighted-routing-policy)
+ [レコード名](#rrsets-values-weighted-name)
+ [レコードタイプ](#rrsets-values-weighted-type)
+ [TTL (秒)](#rrsets-values-weighted-ttl)
+ [値/トラフィックのルーティング先](#rrsets-values-weighted-value)
+ [Weight](#rrsets-values-weighted-weight)
+ [ヘルスチェック](#rrsets-values-weighted-associate-with-health-check)
+ [記録 ID](#rrsets-values-weighted-set-identifier)
## ルーティングポリシー
[**Weighted**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**レコード名**] フィールドに値 (@ 記号など) を入力しないでください。
加重レコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-shared.md#rrsets-values-common-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
加重レコードのグループ内のすべてのレコードに同じ値を選択します。
## TTL (秒)
再帰的な DNS リゾルバーでこのレコードに関する情報をキャッシュしておく時間 (秒単位)。より長い値 (例えば、172800 秒、つまり 2 日) を指定する場合、このレコードの最新情報を取得するには、再帰的な DNS リゾルバーで Route 53 に対して実行する必要がある呼び出しの数を減らします。これにより、レイテンシーが短縮され、Route 53 サービスの請求額が削減されます。詳細については、「[Amazon Route 53 によりドメインのトラフィックをルーティングする方法](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic)」を参照してください
ただし、TTL に長い値を使用する場合、再帰的なリゾルバーは、Route 53 に最新の情報を問い合わせるまでに、長い間キャッシュ内の値を使用するため、レコードに対する変更 (例えば、新しい IP アドレス) が有効になるまでの時間が長くなります。既に使用されているドメインまたはサブドメインの設定を変更する場合、最初は 300 秒など短い値を指定し、新しい設定が正しいことを確認したら、値を増やすことをお勧めします。
このレコードをヘルスチェックに関連付ける場合、ヘルスステータスの変化にクライアントがすばやく対応できるよう、60 秒以下の TTL を指定することをお勧めします。
この加重レコードのグループに含まれるすべてのレコードについて、[**TTL**] に同じ値を指定する必要があります。
**注記**
同じ名前とタイプの複数の加重レコードを作成し、[**TTL**] に異なる値を指定すると、Route 53 は､すべてのレコードの [**TTL**] の値を指定した最後の値に変更します｡
加重レコードのグループに、トラフィックを ELB ロードバランサーにルーティングしている加重エイリアスレコードが 1 つ以上含まれる場合は、同じ名前とタイプの非エイリアス加重レコードすべてに、60 秒の TTL を指定することをお勧めします。60 秒 (ロードバランサーの TTL) 以外の値を指定すると、[**Weight (重み)**] に指定する値の効果が変わります。
## 値/トラフィックのルーティング先
**IP アドレス、またはレコードタイプに応じた別の値**を選択します。[**レコードタイプ**] の値として適切な値を入力します。[**CNAME**] を除くすべてのタイプは、複数の値を入力できます。各値は個別の行に入力します。
次の値にトラフィックをルーティングするか、次の値を指定できます。
+ **A — IPv4 アドレス**
+ **AAAA — IPv6 アドレス**
+ **CAA —認証局の承認**
+ **CNAME — 正規名**
+ **MX — メール交換**
+ **NAPTR — 名前付け権限ポインタ**
+ **PTR — ポインタ**
+ **SPF — センダーポリシーフレームワーク**
+ **SRV — サービスロケーター**
+ **TXT — テキスト**
上記の値の詳細については、「[common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value)」(値/トラフィックのルーティング先) を参照してください。
## Weight
Route 53 が現在のレコードを使用して応答する DNS クエリの割合を決定する値。Route 53 は、同じ DNS 名とタイプの組み合わせがあるレコードの重みの合計を計算します。その後、Route 53 はリソースの重みと合計の比率に基づいてクエリに応答します。
[**レコード名**] および [**レコードタイプ**] の値が加重レコードと同じである非加重レコードを作成することはできません。
0 ～ 255 の整数を入力します。リソースへのルーティングを無効にするには、[**Weight (重み)**] に 0 を設定します。グループ内のすべてのレコードに対して [**Weight (重み)**] を 0 に設定した場合、トラフィックは等しい確率ですべてのリソースにルーティングされます。これにより、加重レコードのグループのルーティングを誤って無効にする心配がなくなります。
加重レコードにヘルスチェックを割り当てる場合、[**Weight (重み)**] を 0 に設定した結果は異なります。詳細については、「[ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法ヘルスチェックが設定されている場合に Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)」を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にあるエイリアスレコードまたはレコードの **[Evaluate target health]** (ターゲットのヘルスを評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
## 記録 ID
加重レコードのグループ内で、このレコードを一意に識別する値を入力します。
# 加重エイリアスレコードに固有の値
加重エイリアスレコードを作成するときは、以下の値を指定します。詳細については、「[エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)」を参照してください。
**Topics**
+ [ルーティングポリシー](#rrsets-values-weighted-alias-routing-policy)
+ [レコード名](#rrsets-values-weighted-alias-name)
+ [レコードタイプ](#rrsets-values-weighted-alias-type)
+ [値/トラフィックのルーティング先](#rrsets-values-weighted-alias-alias-target)
+ [Weight](#rrsets-values-weighted-alias-weight)
+ [ヘルスチェック](#rrsets-values-weighted-alias-associate-with-health-check)
+ [ターゲットの正常性の評価](#rrsets-values-weighted-alias-evaluate-target-health)
+ [記録 ID](#rrsets-values-weighted-alias-set-identifier)
## ルーティングポリシー
[**加重**] を選択します。
## レコード名
トラフィックをルーティングするドメインまたはサブドメインの名前を入力します。デフォルト値はホストゾーンの名前です。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[**名前**] フィールドに値 (@ 記号など) を入力しないでください。
加重レコードのグループで、すべてのレコードに同じ名前を入力します。
レコード名の詳細については、[レコード名](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name) を参照してください。
## レコードタイプ
DNS レコードタイプ。詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
トラフィックをルーティングする AWS リソースに基づいて、該当する値を選択します。
**API Gateway のカスタムリージョン API またはエッジ最適化 API**
[**A — IPv4 アドレス**] を選択します。
**Amazon VPC インターフェイスのエンドポイント**
[**A — IPv4 アドレス**] を選択します。
**CloudFront 配信**
[**A — IPv4 アドレス**] を選択します。
ディストリビューションに対して IPv6 が有効になっている場合は、2 つのレコードを作成します。1 つは [**タイプ**] として [**A — IPv4 アドレス**] の値を持つもの、もう 1つは [**AAAA — IPv6 アドレス**] の値を持つものとします。
**App Runner サービス**
[**A — IPv4 アドレス**] を選択します。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**A — IPv4 アドレス**] を選択します。
**ELB ロードバランサー**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**Amazon S3 バケット**
[**A — IPv4 アドレス**] を選択します。
**OpenSearch Service**
[**A — IPv4 アドレス**] または [**AAAA — IPv6 アドレス**] を選択します。
**このホストゾーン内の別のレコード**
エイリアスを作成するレコードのタイプを選択します。[**NS**] および [**SOA**] 以外のすべてのタイプがサポートされます。
ホストゾーン (*Zone Apex* といいます) と同じ名前のエイリアスレコードを作成する場合、[**タイプ**] の値が [**CNAME**] のレコードにトラフィックをルーティングすることはできません。これは、トラフィックがルーティングされているレコードとエイリアスレコードのタイプが同じでなければならず、Zone Apex の CNAME レコードの作成はエイリアスレコードであってもサポートされていないためです。
加重レコードのグループ内のすべてのレコードに同じ値を選択します。
## 値/トラフィックのルーティング先
リストから選択する値、または フィールドに入力する値は、トラフィックをルーティングする AWS リソースによって異なります。
ターゲットにできる AWS リソースの詳細については、[値/ルートトラフィックのエイリアスレコードの一般的な値](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target)を参照してください。
特定の AWS リソースにトラフィックをルーティングするように Route 53 を設定する方法の詳細については、「」を参照してください[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)。
## Weight
Route 53 が現在のレコードを使用して応答する DNS クエリの割合を決定する値。Route 53 は、同じ DNS 名とタイプの組み合わせがあるレコードの重みの合計を計算します。その後、Route 53 はリソースの重みと合計の比率に基づいてクエリに応答します。
[**レコード名**] および [**レコードタイプ**] の値が加重レコードと同じである非加重レコードを作成することはできません。
0 ～ 255 の整数を入力します。リソースへのルーティングを無効にするには、[**Weight (重み)**] に 0 を設定します。グループ内のすべてのレコードに対して [**Weight (重み)**] を 0 に設定した場合、トラフィックは等しい確率ですべてのリソースにルーティングされます。これにより、加重レコードのグループのルーティングを誤って無効にする心配がなくなります。
加重レコードにヘルスチェックを割り当てる場合、[**Weight (重み)**] を 0 に設定した結果は異なります。詳細については、「[ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法ヘルスチェックが設定されている場合に Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)」を参照してください。
## ヘルスチェック
Route 53 で、指定されたエンドポイントの正常性をチェックし、エンドポイントが正常であるときにのみ、このレコードを使用して DNS クエリに応答する場合は、ヘルスチェックを選択します。
Route 53 は、レコード内で指定されたエンドポイント、例えば、[**値**] フィールドの IP アドレスで指定されたエンドポイントの正常性はチェックしません。Route 53 は、レコードのヘルスチェックを選択したとき、ヘルスチェックで指定されたエンドポイントの正常性をチェックします。エンドポイントが正常であるかどうかを、Route 53 がどのように判断するかについては、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
ヘルスチェックをレコードに関連付けることに意味があるのは、Route 53 が複数のレコードの中から選択して DNS クエリに応答しており、その選択の一部をヘルスチェックのステータスに基づいて行うように Route 53 を設定する必要がある場合だけです。以下の設定でのみ、ヘルスチェックを使用してください。
+ 名前、種類、およびルーティングポリシー (フェイルオーバーレコードや加重レコードなど) が同じレコードのグループ内のすべてのレコードのヘルスをチェックし、すべてのレコードのヘルスチェック ID を指定します。レコードのヘルスチェックが正常ではないエンドポイントを特定した場合、Route 53 はそのレコードの値を使用してクエリへの応答を停止します。
+ フェイルオーバーエイリアス、位置情報エイリアス、レイテンシーエイリアス、IP ベースエイリアス、または加重エイリアスレコードのグループ内にあるエイリアスレコードまたはレコードの **[Evaluate target health]** (ターゲットのヘルスを評価) で、**[Yes]** (はい) を選択します。エイリアスレコードが同じホストゾーン内の非エイリアスレコードを参照する場合、参照先レコードのヘルスチェックも指定する必要があります。エイリアスレコードにヘルスチェックを関連付けた上で、**[Evaluate Target Health]** (ターゲットの正常性の評価) で **[Yes]** (はい) を選択した場合、これらの設定は両方とも有効になります。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
ヘルスチェックでドメイン名によってのみエンドポイントを指定する場合、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**ドメイン名**] の値には、レコードの名前 (example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。
**重要**
この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。
## ターゲットの正常性の評価
Route 53 で、このレコードを使用して [**エンドポイント**] で指定されたリソースの正常性を確認することによって DNS クエリに応答するかどうかを判定する場合は、[**Yes**] を選択します。
次の点に注意してください。
**API Gateway のカスタムリージョン API とエッジ最適化 API**
エンドポイントが API Gateway カスタムリージョン API またはエッジ最適化 API である場合、[**Evaluate target health**] (ターゲットヘルスを評価) を [**Yes**] (はい) に設定するための特別な要件はありません。
**CloudFront ディストリビューション**
エンドポイントが CloudFront ディストリビューションの場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定することはできません。
**ローカル化されたサブドメインがある Elastic Beanstalk 環境**
[**エンドポイント**] で Elastic Beanstalk 環境を指定し、その環境に ELB ロードバランサーが含まれている場合、Elastic Load Balancing はクエリをロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみルーティングします。(複数の Amazon EC2 インスタンスが含まれている場合、環境には自動的に ELB ロードバランサーが含まれます。) [**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な Amazon EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他に利用可能なリソースがあれば、そこにクエリをルーティングします。
環境に 1 つの Amazon EC2 インスタンスが含まれている場合、特別な要件はありません。
**ELB ロードバランサー**
ヘルスチェックの動作はロードバランサーのタイプによって異なります。
+ [**Classic Load Balancers**] – [**エンドポイント**] で ELB Classic Load Balancer を指定した場合、Elastic Load Balancing は、ロードバランサーに登録されている正常な Amazon EC2 インスタンスにのみクエリをルーティングします。[**ターゲットの正常性の評価**] を [**Yes**] に設定したとき、正常な EC2 インスタンスがない場合やロードバランサー自体が正常でない場合、Route 53 は他のリソースにクエリをルーティングします。
+ **アプリケーションと Network Load Balancer** – ELB アプリケーションまたは Network Load Balancer を指定し、[**ターゲットの正常性の評価**] を **Yes** に設定すると、Route 53 は､ロードバランサーに関連付けられているターゲットグループの正常性に基づいて､クエリをロードバランサーにルーティングします。
+ アプリケーションまたはNetwork Load Balancerを正常であると見なすには、ターゲットを含むすべてのターゲットグループに少なくとも 1 つの正常なターゲットが含まれている必要があります。ターゲットグループに異常なターゲットのみが含まれている場合、ロードバランサーは異常であるとみなされ、Route 53 はクエリを他のリソースにルーティングします。
+ 登録されたターゲットを持たないターゲットグループは異常であるとみなされます｡
ロードバランサーを作成するときは、Elastic Load Balancing のヘルスチェックの設定を行います。これは Route 53 のヘルスチェックではありませんが、同様の機能を実行します。ELB ロードバランサーに登録する EC2 インスタンスに対しては Route 53 のヘルスチェックを作成しないでください。
**S3 バケット**
エンドポイントが S3 バケットである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**Amazon VPC インターフェイスのエンドポイント**
エンドポイントが Amazon VPC インターフェイスエンドポイントである場合、[**ターゲットの正常性の評価**] を [**Yes**] に設定するための特別な要件はありません。
**同じホストゾーンの他のレコード**
Endpoint で指定した AWS リソース****がレコードまたはレコードのグループ (加重レコードのグループなど) で、別のエイリアスレコードではない場合は、ヘルスチェックをエンドポイント内のすべてのレコードに関連付けることをお勧めします。詳細については、「[ヘルスチェックを省略するとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting)」を参照してください。
## 記録 ID
加重レコードのグループ内で、このレコードを一意に識別する値を入力します。
# ゾーンファイルをインポートしてレコードを作成する
別の DNS サービスプロバイダーから移行しようとしていて、現在の DNS 設定をゾーンファイルにエクスポートすることが現在の DNS サービスプロバイダーから許可されている場合は、ゾーンファイルをインポートすることで、Amazon Route 53 ホストゾーン用のすべてのレコードを迅速に作成できます。
**注記**
ゾーンファイルでは、レコードをテキスト形式で表すための BIND と呼ばれる標準形式が使用されています。ゾーンファイルの形式については、Wikipedia の[ゾーンファイル](https://en.wikipedia.org/wiki/Zone_file)のエントリを参照してください。詳細については、「[RFC 1034: ドメイン名—概念と機能](https://datatracker.ietf.org/doc/html/rfc1034)」のセクション 3.6.1、および「[RFC1035: ドメイン名—実装と仕様](https://datatracker.ietf.org/doc/html/rfc1035)」のセクション 5 を参照してください。
ゾーンファイルをインポートしてレコードを作成する場合は、次の点に注意してください。
+ ゾーンファイルは、RFC に準拠した形式である必要があります。
+ ゾーンファイル内のレコードのドメイン名は、ホストゾーンの名前に一致する必要があります。
+ Route 53 では、`$ORIGIN` と `$TTL` のキーワードがサポートされます。ゾーンファイルに `$GENERATE` または `$INCLUDE` のキーワードが含まれる場合、インポートは失敗し、Route 53 からエラーが返されます。
+ ゾーンファイルをインポートしたとき、Route 53 はゾーンファイル内の SOA レコードを無視します。Route 53 では、ホストゾーンと同じ名前を持つ NS レコードもすべて無視されます。
+ 最大 1000 個のレコードをインポートすることができます。
+ ゾーンファイルに表示されるレコードが既にホストゾーンに含まれている場合、インポートプロセスは失敗し、レコードは作成されません。
+ バックスラッシュ文字を含む TXT レコードの場合、ゾーンファイルインポートプロセスは特定のバックスラッシュシーケンスをコントロール文字として解釈します。TXT レコード値にリテラルバックスラッシュ文字を含めるには:
+ ゾーンファイルで二重バックスラッシュ (`\\\\`) を使用し、最終的な TXT レコードで 1 つのリテラルバックスラッシュを表します。
+ 例えば、TXT レコードに `\\jYTDWqH...` (リテラルバックスラッシュと j を持つ) を含める必要がある場合、ゾーンファイルに `\\\\jYTDWqH...` を指定します。
これは、リテラルバックスラッシュ文字を含んだ ACME チャレンジレコードやその他の TXT レコードにおいて特に重要です。
+ 長い TXT レコード (DKIM レコードなど) の場合、ゾーンファイルのインポートプロセスでは、コンテンツを複数の文字列に分割できます。複数の文字列を持つ TXT レコードを作成するには:
+ ゾーンファイルで、同じレコード名とタイプで別々の行を使用します。
**Example**
```
example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC"
example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f"
example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x"
```
インポートプロセスでは、これらが複数の文字列を持つ単一の TXT レコードに自動的に結合されます。各文字列には最大 65,535 文字を含めることができます。長い文字列を単一の引用符で囲まれた値に連結しないでください。
+ ゾーンファイルの内容を参照し、レコード名に適切に末尾のドットが含まれている/省かれていることを確認することをお勧めします。
+ ゾーンファイル内のレコードの名前の末尾がドットである場合 (`example.com.`)、その名前はインポートプロセスによって完全修飾ドメイン名と解釈され、その名前で Route 53 レコードが作成されます。
+ ゾーンファイル内のレコードの名前の末尾がドットでない場合 (`www`)、その名前はインポートプロセスによってゾーンファイル内のドメイン名 (`example.com`) と連結され、連結後の名前 (`www.example.com`) で Route 53 レコードが作成されます。
エクスポートプロセスでレコードの完全修飾ドメイン名の末尾にドットが追加されない場合、Route 53 インポートプロセスでドメイン名がレコードの名前に追加されます。たとえば、レコードをホストゾーン `example.com` にインポートし、ゾーンファイルの MX レコードの名前は `mail.example.com` で末尾のドットがない場合、Route 53 インポートプロセスでは `mail.example.com.example.com` という名前の MX レコードが作成されます。
**重要**
CNAME、MX、PTR、および SRV レコードの場合も、RDATA 値に含まれるドメイン名にこの動作が適用されます。たとえば、`example.com` のゾーンファイルがあるとします。ゾーンファイル内の CNAME レコード (`support`、末尾にドットなし) に RDATA 値 `www.example.com` (同様に末尾にドットなし) が含まれている場合、インポートプロセスによって、`www.example.com.example.com` にトラフィックをルーティングする `support.example.com` という名前の Route 53 レコードが作成されます。ゾーンファイルをインポートする前に、RDATA 値を確認し、必要に応じて更新してください。バックスラッシュ文字を含む TXT レコードの場合は、ゾーンファイルで二重バックスラッシュ (`\\\\`) を使用してリテラルバックスラッシュを表します。
Route 53 はレコードのゾーンファイルへのエクスポートをサポートしていません。
**注記**
ホストゾーンと同じ名前のレコードを作成する場合は、[名前] フィールドに値 (@ 記号など) を入力しないでください。
**ゾーンファイルをインポートしてレコードを作成するには**
1. 現在ドメインにサービスを提供している DNS サービスプロバイダーからゾーンファイルを取得します。手順と用語はサービスプロバイダーによって異なります。レコードをゾーンファイルまたは BIND ファイルにエクスポートまたは保存する方法については、プロバイダーのインターフェイスおよびドキュメントを参照してください。
手順がわからない場合は、*レコードリスト*または*ゾーンファイル*について、現在の DNS プロバイダーのカスタマーサポートに問い合わせてください。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. [**ホストゾーン**] ページで、新しいホストゾーンを作成します。
1. [**ホストゾーンの作成**] を選択します。
1. ドメインの名前 (およびオプションでコメント) を入力します。
1. **[作成]** を選択します。
1. [**ゾーンファイルのインポート**] を選択します。
1. [**ゾーンファイルのインポート**] ペインで、ゾーンファイルの内容を [**ゾーンファイル**] テキストボックスに貼り付けます。
1. [**Import**] を選択します。
**注記**
ゾーンファイル内のレコードの数によっては、レコードが作成されるまで数分かかる場合があります。
1. ドメインで別の DNS サービスを使用している場合は（別のレジストラにドメインを登録していた場合はよくあることです）、DNS サービスを Route 53 に移行します。そのステップが完了すると、レジストラはドメインの DNS クエリに応じる DNS サービスとして Route 53 を認識し始め、クエリが Route 53 DNS サーバーに送信され始めます (以前の DNS サービスに関する情報が DNS リゾルバーにキャッシュされているため、DNS クエリが Route 53 にルーティングされ始めるまでに通常は 1～2 日の遅れが生じます）。詳細については、「[Amazon Route 53 を既存ドメインの DNS サービスとして使用するRoute 53 を既存ドメインの DNS サービスにする](MigratingDNS.md)」を参照してください
# レコードの編集
以下の手順では、Amazon Route 53 コンソールを使用してレコードを編集する方法について説明します。Route 53 API を使用してレコードを編集する方法については、*Amazon Route 53 API リファレンス*の「[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)」を参照してください。
**注記**
レコードの変更が Route 53 DNS サーバーに伝達されるまでにしばらく時間がかかります。現在、変更が伝達されたことを確認するには、[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API アクションを使用する方法しかありません。通常、変更は 60 秒以内にすべての Route 53 ネームサーバーに伝播されます。
**Route 53 コンソールを使用してレコードを編集するには**
1. エイリアスレコードを編集しない場合は、ステップ 2 に進みます。
Elastic Load Balancing Classic Load Balancer、Application Load Balancer、または Network Load Balancer にトラフィックをルーティングするエイリアスレコードを編集する場合、別のアカウントで Route 53 ホストゾーンとロードバランサーを作成していたら、手順「[Elastic Load Balancing ロードバランサーの DNS 名を取得する](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure)」を実行してロードバランサーの DNS 名を取得します。
他の AWS リソースのエイリアスレコードを編集する場合は、ステップ 2 に進みます。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. [**ホストゾーン**] ページで、編集するレコードが含まれているホストゾーンの行を選択します。
1. 編集するレコードの行を選択し、[**レコードの編集**] ペインに変更を入力します。
1. 適切な値を入力します。詳細については、「[Amazon Route 53 レコードの作成時または編集時に指定する値](resource-record-sets-values.md)」を参照してください
1. **[Save changes]** (変更の保存) をクリックします。
1. レコードを複数編集する場合は、ステップ 5 ～ 7 を繰り返します。
# レコードの削除
次の手順では、Route 53 コンソールを使用してレコードを削除する方法を説明します。Route 53 API を使用してレコードを削除する方法については、*Amazon Route 53 API リファレンス*の「[ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)」を参照してください。
**注記**
レコードの変更が Route 53 DNS サーバーに伝達されるまでにしばらく時間がかかります。現在、変更が伝達されたことを確認するには、[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API アクションを使用する方法しかありません。通常、変更は 60 秒以内にすべての Route 53 ネームサーバーに伝播されます。
**レコードを削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. [ホストゾーン] ページで、削除するレコードが含まれているホストゾーンの行を選択します。
1. レコードのリストで、削除するレコードを選択します。
複数の連続するレコードを選択するには、最初の行を選択し、**Shift** キーを押したまま最後の行を選択します。複数の連続しないレコードを選択するには、最初の行を選択し、**Ctrl** キーを押したまま追加の行を選択します。
[**タイプ**] の値が [**NS**] または [**SOA**] のレコードを削除することはできません。
1. [**Delete (削除)**] を選択します。
1. [**削除**] を選択してダイアログボックスを閉じます。
# レコードの一覧表示
以下の手順は、Amazon Route 53 コンソールを使用してホストゾーンのレコードを一覧表示する方法を説明しています。Route 53 API を使用してレコードを一覧表示する方法については、「*Amazon Route 53 API リファレンス*」の「[ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)」を参照してください。
**レコードを一覧表示するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。
1. ナビゲーションペインで [**Hosted zones**] を選択します。
1. [**Hosted Zones**] ページで、ホストゾーンの名前を選択します。
1. 検索モードを変更するには、**[レコード]** テーブルの右上にある歯車アイコンを選択します。オプションのいずれかを選択します。
+ **自動**
このモードでは、サービスは多数のレコードに基づくフィルターを使用します。2,000 レコードまではフル、2,000 レコードを超える場合は高速になります
+ **フル**
このモードでは、すべての検索フィルターが使用できますが、その場合検索のパフォーマンスが低下する可能性があります。
+ **高速**
このモードでは、一部の高度な機能は使用できませんが、検索は速くなります。
選択したレコードのみを表示するには、レコードのリストの上に、該当する検索条件を入力します。自動モードの検索動作は、ホストゾーンに最大で 2,000 のレコードが含まれているか、または 2,000 を超えるレコードが含まれているかによって異なります。
**最大 2,000 レコードおよびフルモード**
+ 特定の値を含んでいるレコードを表示するには、サーチバーに値を入力し [**Enter**] を押します。例えば、**192.0** で始まる IP アドレスを持つレコードを表示するには、[**Search (検索)**] フィールドにその値を入力して **Enter** を押します。
+ DNS レコードタイプが同じレコードのみを表示するには、ドロップダウンリストで [**レコードタイプ**] を選択し、レコードタイプを入力します。
+ エイリアスレコードのみを表示するには、ドロップダウンリストで [**エイリアス**] を選択し、**Yes** と入力します。
+ 加重レコードのみを表示するには、ドロップダウンリストで [**ルーティングポリシー**] を選択し、**WEIGHTED** と入力します。
**2,000 を超えるレコードおよび高速モード**
+ レコード値ではなく、レコード名でのみ検索できます。また、レコードタイプ、エイリアスレコードまたは加重レコードに基づいてフィルタリングすることはできません。
この操作を行うには、**[フィルター]** テキストボックスにカーソルを置き、**[プロパティ]**、**[レコード名]** の順に選択します。
+ 3 つのラベル (ドットで区切られた 3 つの部分) を持つレコードの場合は、検索フィールドに値を入力して [**Enter**] を押すと、Route 53 コンソールで、レコード名の右から 3 番目のラベルの末尾にワイルドカードを追加した検索が自動的に実行されます。例えば、ホストゾーン example.com に、record1.example.com 〜 record100.example.com の 100 個のレコードが含まれているとします。(Record1 は右から 3 番目のラベルです。) ここで、以下の値を検索した場合の動作を示します。
+ **record1** – Route 53 コンソールで **record1\$1.example.com** が検索されます。**record1.example.com**、**record10.example.com** ～ **record19.example.com**、および **record100.example.com** が返されます。
+ **record1.example.com** – 前の例と同様に、コンソールで **record1\$1.example.com** が検索され、同じレコードが返されます。
+ **1** – コンソールで **1\$1.example.com** が検索されます。返されるレコードはありません。
+ **example** – コンソールで **example\$1.example.com** が検索されます。返されるレコードはありません。
+ **example.com** – この場合、コンソールでワイルドカード検索は実行されません。ホストゾーンのすべてのレコードが返されます。
+ **自動検索モード** — この検索モードを使用する場合、検索できるようにするために、先にレコード名などのプロパティを指定しておく必要があります。
**注記**
右から 3 番目のラベルに 1 つ以上のハイフンが含まれている場合 (`third-label.example.com` など) で、3 番目のラベルのハイフンの直前までの部分 (この例では `third`) を検索した場合、Route 53 から返されるレコードはありません。代わりに、ハイフンを含める (`third-` で検索) か、ハイフン直前の文字を省略 (`third`) します。
+ 4 つ以上のラベルを持つレコードの場合は、レコードの正確な名前を指定する必要があります。ワイルドカード検索はサポートされていません。例えば、ホストゾーンに label4.record1.example.com という名前のレコードが含まれている場合、検索フィールドに [**label4.record1.example.com**] と指定した場合にのみ、そのレコードを見つけることができます。
# 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]** (内部エラー) を修正するためのオペレーションを除き、ホストゾーンに対して他の変更を加えることはできません。
# AWS Cloud Map によるレコードとヘルスチェックの作成
インターネットトラフィックまたは Amazon VPC 内のトラフィックを、アプリケーションコンポーネントやマイクロサービスにルーティングする場合は、AWS Cloud Map を使用してレコードを自動的に作成したり、(必要に応じて) ヘルスチェックを作成したりできます。詳細については、「[AWS Cloud Map デベロッパーガイド](https://docs.aws.amazon.com/cloud-map/latest/dg/)」を参照してください。
# DNS の制約と動作
DNS メッセージングは、ホストゾーンおよびレコードの作成方法と使用方法に影響を与える要素に依存します。このセクションでは、これらの要素について説明します。
## 最大レスポンスサイズ
DNS 標準に準拠するために、UDP 経由で送信されるレスポンスのサイズはわずか 512 バイトです。512 バイトを超えるレスポンスは切り捨てられ、リゾルバーは TCP 経由でリクエストを再発行する必要があります。リゾルバーが EDNS0 ([RFC 2671](https://tools.ietf.org/html/rfc2671) で定義) をサポートし、EDNS0 オプションを Amazon Route 53 にアドバタイズする場合、Route 53 では UDP 経由のレスポンスのサイズを 4096 バイトまで許可し切り捨ては行われません。
## Authority セクションの処理
クエリが正常に実行された場合、Route 53 は、関連するホストゾーンのネームサーバー (NS) レコードを、DNS レスポンスの Authority セクションに追加します。名前が検出されなかった場合 (NXDOMAIN レスポンス)、Route 53 は、関連するホストゾーンの Start of Authority (SOA) レコード ([RFC 1035](https://tools.ietf.org/html/rfc1035) で定義) を、DNS レスポンスの Authority セクションに追加します。
## Additional セクションの処理
Route 53 は、レコードを Additional セクションに追加します。レコードが既知のものであり、適切なレコードである場合は、サービスによって、Answer セクションにある MX、CNAME、NS、SRV の各レコードのターゲットに対応した A レコードまたは AAAA レコードが追加されます。これらの DNS レコードタイプの詳細については、「[サポートされる DNS レコードタイプ](ResourceRecordTypes.md)」を参照してください。
# 関連トピック
Route 53 へのドメイン登録 (DNS ホスティングだけでなく) の移管については、以下のトピックを参照してください。
+ [ドメイン移管の移管前チェックリスト](domain-transfer-checklist.md) – 一般的な移管の失敗を避けるため、ドメイン登録を移管する前にこのチェックリストを完了してください。
+ [ドメイン登録の Amazon Route 53 への移管](domain-transfer-to-route-53.md) – 別のレジストラから Route 53 へドメイン登録を移管するためのステップバイステップのプロセス。
+ [ドメインの移管](domain-transfer.md) – AWS アカウント間の移管を含む、すべてのドメイン移管オプションの概要。