翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# レコードを使用する
ドメイン (例えば、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**] と指定した場合にのみ、そのレコードを見つけることができます。