翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Route 53 DNS のベストプラクティス Amazon Route 53 DNS サービスを使用するときに最良の結果が得られるようにするには、以下のベストプラクティスに従ってください。 **DNS フェイルオーバーとアプリの回復にデータプレーン機能を使用してください** ヘルスチェックを含む Route 53 のデータプレーンと Amazon アプリケーション回復コントローラー (ARC) のルーティングコントロールは、グローバルに分散されており、重大なイベント中でも 100% の可用性と機能性を実現するように設計されています。これらは互いに統合され、コントロールプレーンの機能に依存しません。コンソールを含むこれらのサービスのコントロールプレーンは、一般的に非常に信頼性が高いですが、より一元化された方法で設計されており、高可用性よりも耐久性と一貫性が優先されます。ディザスタリカバリ時のフェイルオーバーなどのシナリオでは、DNS を更新するためにデータプレーン機能を利用する、Route 53 のヘルスチェックや ARC のルーティング制御などの機能の使用をお勧めします。詳細については、「[コントロールプレーンとデータプレーンの概念](route-53-concepts.md#route-53-concepts-control-and-data-plane)」、および「[Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)」(ブログ: Amazon Route 53 を使用した災害回復メカニズムの作成) を参照してください。 **DNS レコードの TTL 値の選択** DNS TTL とは、Route 53 に対してさらなるクエリを行わずにレコードをキャッシュできる期間を決定するために DNS リゾルバーが使用する数値 (秒単位) です。すべての DNS レコードには TTL が指定されている必要があります。TTL 値の推奨範囲は 60 ～ 172,800 秒です。 TTL の選択は、レイテンシーと信頼性、および変化に対する応答性との間のトレードオフです。レコードの TTL が短くなると、DNS リゾルバーはより頻繁にクエリを実行する必要があるため、レコードの更新が速くなります。これにより、クエリのボリューム (およびコスト) が増大します。TTL を長くすると、DNS リゾルバーはキャッシュからのクエリに頻繁に応答します。これは通常、高速で、安価で、場合によってはインターネットを介したクエリを回避するため信頼性が高くなります。絶対的に正しい値は存在せず、応答性と信頼性のどちらがより重要であるかを考える価値はあります。 TTL 値を設定する際に考慮すべき事項: + 変更が有効になるのを待つ余裕があれば、DNS レコード TTL を設定します。これは、委任 (NS レコードセット) や、MX レコードなど、ほとんど変更されない他のレコードで特に当てはまります。これらのレコードでは、より長い TTL が推奨されます。一時間 (3600 秒) から 1 日 (86,400 秒) の間が一般的な数値です。 + 高速フェールオーバーメカニズム (特にヘルスチェックされるレコード) の一部として変更する必要があるレコードについては、TTL を下回るのが適切です。このシナリオでは、TTL を 60 秒または 120 秒に設定するのが一般的です。 + 重要な DNS エントリに変更を加える場合、TTL を一時的に短くすることをお勧めします。そうすれば、必要に応じてすばやく変更、監視、ロールバックを行うことができます。変更が確定し、期待どおりに機能した後、TTL を長くすることができます。 詳しくは、「[TTL (秒)](resource-record-sets-values-shared.md#rrsets-values-common-ttl) 」を参照してください。 **CNAME レコード** DNS 内の CNAME レコードは、あるドメイン名を別のドメイン名でポイントする手段になります。DNS リゾルバーが domain-1.example.com を解決し、domain-2.example.com を指している CNAME が見つかった場合、DNS リゾルバーは応答する前に domain-2.example.com を解決する必要があります。これらのレコードは、例えば、ウェブサイトに複数のドメイン名がある場合に一貫性を保つためなど、多くの状況で役立ちます。 ただし、DNS リゾルバーは CNAME に応答するために、より多くのクエリを作成する必要があり、レイテンシーとコストが増加します。可能であれば、Route 53 エイリアス レコードを使用するのが高速かつ安価な代替手段です。エイリアスレコードにより、Route 53 は AWS リソース (ロードバランサーなど) および同じホストゾーン内の他のドメインに対して直接応答できます。 詳細については、「[インターネットトラフィックを AWS リソースにルーティングする](routing-to-aws-resources.md)」を参照してください。 **高度な DNS ルーティング** + 位置情報、地理的近接性またはレイテンシーベースのルーティングを使用する場合は、一部のクライアントが*回答なし*のレスポンスを受信できるようにする場合を除き、常にデフォルトを設定します。 + アプリケーションのレイテンシーを最小限に抑えるには、レイテンシーベースのルーティングを使用します。このタイプのルーティングデータは頻繁に変更されることがあります。 + ルーティングの安定性と予測可能性を確保するには、位置情報ルーティングまたは地理的近接性ルーティングを使用します。 詳細については[位置情報ルーティング](routing-policy-geo.md)、[地理的近接性ルーティング](routing-policy-geoproximity.md)、および[レイテンシーに基づくルーティング](routing-policy-latency.md)を参照してください。 **DNS 変更の伝播** Route 53 コンソールまたは API を使用して、レコードやホストゾーンを作成または更新する場合、変更内容がインターネット上に反映されるまでにしばらく時間がかかります。これは*変更の伝播*と呼ばれます。通常、伝播はグローバルに 1 分未満で到達しますが、例えば、1 つのロケーションへの同期の問題や、まれに中央コントロールプレーン内の問題など、変更に時間がかかることがあります。自動プロビジョニングワークフローを構築している場合、またはD次のワークフローステップに進む前に、変更の伝播が完了するのを待つことが重要です。DNS の変更が反映されたこと (`Status =INSYNC`) を確認するために、[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API を使用します。 **DNS の委任** DNS で複数のレベルのサブドメインを委任する場合、常に親ゾーンから委任することが重要です。たとえば、委任している場合www.dept.example.comとすると、example.comゾーンからではなくdept.example.comゾーンからそのようにすべきです。*祖父母*から*子*ゾーンへ委任すると、一切機能しないか、動作することもありますがそれは偶然に過ぎません。詳しくは、「[サブドメインのトラフィックのルーティング](dns-routing-traffic-for-subdomains.md) 」を参照してください。 **DNS レスポンスのサイズ** 大きなシングルレスポンスの作成は避けてください。512 バイトを超えると、多くの DNS リゾルバーは UDP ではなく TCP で再試行する必要があります。これにより、レスポンスが遅くなり、信頼性が低下する可能性があります。レスポンスを 512 バイトの限度内に保つために、8 個の健全でランダムな IPアドレス を選択する複数値のアンサールーティングを使用するようお勧めします。 詳細については、「[複数値回答ルーティング](routing-policy-multivalue.md)」および「[DNS Reply Size Test Server](https://www.dns-oarc.net/oarc/services/replysizetest/)」を参照してください。