Azure DNSは、Microsoft Azure インフラストラクチャを使用して名前解決を提供します。 この記事では、パブリック DNS ゾーンについて説明します。通常は、所有するドメイン用に作成し、インターネットで使用できるアプリケーションとサービスのレコードを発行するために使用します。 解決するホスト名はパブリックにアクセス可能な DNS 名であり、解決された IP アドレスは通常、インターネットから到達可能なパブリック IP アドレスです。
Azure DNSは、特定の可用性ゾーンまたはAzureリージョンにバインドされていない非リージョン サービスです。
Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、パブリック ゾーンAzure DNS、一時的な障害、可用性ゾーンの障害、リージョン全体の障害、サービスの停止、セキュリティの脅威と構成の誤り、ポータルと管理ツールの停止、およびサービスメンテナンスに対応する方法について説明します。 また、ゾーン構成を保護および復元する方法と、主要なサービス レベル アグリーメント (SLA) 要件についても説明します。
信頼性のための運用環境のデプロイに関する推奨事項
Azure DNSパブリック ゾーンの運用環境のデプロイの場合は、次の推奨事項に従って信頼性を高めます。
すべてのネーム サーバーに委任します。Azure DNSは、各パブリック DNS ゾーンに 4 つのネーム サーバーを割り当てます。 4 つすべてのネーム サーバーを使用するようにドメイン委任を構成します。 この構成は、障害の分離を提供し、Azure DNS SLA の資格を得るために必要です。
適切な TTL 値を構成します。 クエリ ボリュームとクライアントがレコードの変更を受け取る速度のバランスを取る Time-to-Live (TTL) 値を設定します。 TTL 値を小さくすると、クライアントはより早く変更を受信できますが、クエリの量が増えます。 TTL 値を大きくすると、クエリの量が減りますが、レコードを変更した後にフェールオーバーが遅延する可能性があります。
サポートされているAzure リソースにエイリアス レコードを使用する:エイリアス レコードは、DNS 解決中に基になる Azure リソースへの変更を自動的に反映し、古い DNS レコードを防ぐのに役立ちます。
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
デプロイするプライマリ リソースは、ドメインの DNS レコード セットを含む ゾーンです。 レコード セットは、DNS 名を IP アドレスやエンドポイントなどの値に関連付けます。 パブリック DNS ゾーンで解決される名前には、インターネット経由でアクセスできます。
ドメインAzure DNS権限を持たせるために、ゾーンの作成時に割り当てるAzureネーム サーバーにドメインを委任します。 委任が行われた後、Azure DNSがサポートする DNS レコードの種類のレコード セットを作成します。 パブリック IP アドレス、Traffic Manager プロファイル、Azure Front Door エンドポイントなどのリソースAzure参照するエイリアス レコードを作成して、DNS レコードをターゲット リソースと同期させることもできます。
DNS 解決中、再帰 DNS リゾルバーは DNS 階層に従って、ゾーンのAzure DNS権限のあるネーム サーバーに到達します。
Important
Azure DNSは名前を解決しますが、エンドポイントの正常性を監視したり、アプリケーション トラフィックをルーティングしたりすることはありません。 ソリューション全体の信頼性は、仮想マシンやロード バランサーなど、DNS レコードが参照するリソースの構成によって異なります。
この記事では、これらのリソースについては説明しませんが、可用性の構成はアプリケーションの回復性に直接影響します。 ソリューション内の Azure サービスの信頼性ガイド を確認して、各サービスが信頼性要件をどのようにサポートしているかを確認します。
物理アーキテクチャ
Azure DNSは、非リージョン サービスとして機能し、世界中の複数のAzure リージョンの複数の可用性ゾーンにインフラストラクチャをデプロイします。 この設計により、別のゾーンまたはリージョン内のインフラストラクチャが引き続き解決要求に応答するため、可用性ゾーンまたはリージョンの停止中にAzure DNSの回復性を維持できます。
Anycast、DNS、BGP などのグローバル インターネット プロトコルは、受信 DNS 解決要求を最も近い正常なAzure DNS インフラストラクチャに自動的にルーティングします。
Azure DNS サービス プレーンは、2 つの独立したサービス スタック (Linux で実行されているスタックと Windows で実行されているスタック) にわたってアクティブ/アクティブ構成で動作します。 これらのスタックは、コードを共有せず、基になるハードウェアも共有しません。 これらは独立しているため、1 つのスタックに影響を与えるバグ、脆弱性、または失敗は、もう一方のスタックには影響しません。 この独立により、単一障害点によって発生する完全なサービス停止のリスクが軽減され、特定のクラスのゼロデイ脆弱性から保護するのに役立ちます。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、一時的なエラーへの対処に関するレコメンデーションを参照してください。
Azure DNSは、グローバル DNS インフラストラクチャを介して一時的な障害を処理します。
DNS 解決中に一時的な障害が発生した場合、クライアントまたは中間リゾルバーは、構成された DNS 再試行動作に従って再試行する必要があります。 通常、DNS クライアントでは 2 秒から 5 秒の間で十分なタイムアウトになります。
各 DNS レコードの Time to Live (TTL) は、ソリューションが障害を処理する方法にも影響します。 TTL が非常に低い場合、クライアントはAzure DNSに対してより多くの要求を行う必要があり、一時的な障害が発生する可能性が高くなります。 TTL が非常に高い場合、バックエンド サーバーで別の IP アドレスにリダイレクトする必要がある真の障害が発生した場合、TTL の有効期限が切れるまで、クライアントのフェールオーバーの遅延が発生する可能性があります。 可用性、待機時間、応答性のバランスを取るために、TTL を慎重に構成します。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure DNSは、非リージョン サービスとして動作します。 Microsoftは、そのインフラストラクチャを複数のAzure リージョン内の複数の可用性ゾーンに分散し、そのインフラストラクチャ全体でパブリック DNS ゾーンに変更をレプリケートします。 可用性ゾーンを選択したり、ゾーンの冗長性を構成したりすることはありません。 可用性ゾーンの停止中、別のゾーンまたはリージョンのインフラストラクチャは引き続き解決要求に応答します。
仮想マシン (VM) などの単一の可用性ゾーンにデプロイしたリソースがゾーン障害時に使用できなくなった場合、Azure DNSはエンドポイントの正常性を監視しないため、リソースの構成済み IP アドレスを返し続けます。 正常なゾーン内のリソースにフェールオーバーする場合は、クライアントが正常なリソースを使用するように DNS レコードを更新する必要があります。 または、正常なゾーン内の VM にトラフィックを送信するゾーン冗長ロード バランサーの背後にリソースを配置します。
リージョン全体の障害に対する回復性
ゾーン データはグローバルに利用でき、複数のAzure リージョンにデプロイされるため、DNS ゾーンはリージョンの停止に対して回復性があります。 リージョンで障害が発生した場合、そのリージョンにデプロイしたリソース (仮想ネットワークや VM など) は使用できない可能性がありますが、Azure DNSはゾーン内のレコードを解決し続けます。
ディザスター リカバリーなどの目的で複数のリージョンを切り替える必要があるソリューションがある場合は、Azure Traffic ManagerまたはAzure Front Doorの使用を検討してください。 これらのサービスは、リージョンが異常な場合に使用できる自動フェールオーバー機能を提供します。
セキュリティの脅威と構成の誤りに対する回復性
セキュリティ攻撃と構成エラーは、DNS ゾーンの最も重要な信頼性リスクの 2 つあります。 いくつかの種類の攻撃は特に DNS 解決を対象としており、誤った構成を行うと、ワークロードが深刻に中断される可能性があります。
パブリック DNS ゾーンに固有の包括的なセキュリティ ガイダンスについては、Azure DNS展開のセキュリティ保護と DNS ゾーンとレコードの保護に関するページを参照してください。
サービスの停止に対する回復性
Azure DNSは回復性の高いサービスであり、アプリケーションが特定の条件を満たしている場合、100% 可用性 SLA が提供されます。 サービスの停止は非常に異常ですが、ネットワークの問題や他のインフラストラクチャの問題により、Azure DNS サービスへの接続が中断される可能性があります。
Azure DNSの回復性の一部は、グローバルに分散されたアクティブ/アクティブなサービス プレーン アーキテクチャによるものです。
複数のネーム サーバーを使用する
Azure DNSは、各パブリック DNS ゾーンに 4 つのネーム サーバーを割り当てます。 ドメインを委任するときは、4 つのネーム サーバーをすべて構成します。 リゾルバーがネーム サーバーに到達できない場合は、別のネーム サーバーに対してクエリを実行できます。
サービスの停止を監視する
Azure Service Healthを使用して、Azure DNSの正常性を監視します。 サービス インシデントについて通知するように Service Health アラート を構成します。
サービスの停止をテストする
Azure Chaos Studioは、一部の種類のテスト ワークロード内から DNS 解決エラーをシミュレートする障害を提供します。 これらの障害は、Azure DNSで停止をトリガーしません。 Chaos Studio エージェントは DNS 障害 を提供し、AKS Chaos Mesh は DNS カオス 機能を提供します。 これらの障害を使用して、部分的なネットワーク障害時など、DNS 解決が失敗したときにアプリケーションとインフラストラクチャがどのように応答するかをテストします。
ポータルと管理ツールの停止に対する回復性
Azure ポータルでパブリック DNS ゾーンを管理する場合は、特に停止中にゾーンを再構成する必要がある場合は特に、ポータルにアクセスできないシナリオの代替管理パスを準備します。
Azure ポータルが使用できない場合は、Bicepや Terraform などのコードとしてのAzure CLI、Azure PowerShell、またはインフラストラクチャ (IaC) を使用してパブリック DNS ゾーンを管理します。 Azure ポータルが機能低下した場合でも、これらのツールは引き続き動作します。
バックアップと復元
Azure DNSはステートレス サービスです。 パブリック DNS ゾーンのマネージド バックアップやポイントインタイム リストアは提供されません。
Azureリソース構成全体を保持するには、Bicepや Terraform などの IaC を使用してパブリック DNS ゾーンを定義し、その定義をソース管理に格納します。 定義を定期的にテストして、それらを使用して構成を再デプロイできるようにします。
追加のレコード レベルの回復オプションとして、 BIND 互換のゾーン ファイルをエクスポートします。 ゾーン ファイルのインポートには制限があり、すべてのAzure固有のリソース設定が保持されるわけではありません。そのため、エクスポートされたゾーン ファイルを唯一の回復成果物として使用しないでください。 ドキュメントに記載されているインポートの制限事項を確認し、ゾーンを復元した後にレコードを確認します。
サービス メンテナンスに対する回復性
Microsoft は定期的にサービス更新プログラムを適用し、その他のメンテナンスを実行します。 Azure プラットフォームは、これらのアクティビティを自動的に処理し、メンテナンスがシームレスで透過的であることを保証します。 Azure Service Health の計画メンテナンスを通じて通知されていない限り、メンテナンス イベント中にダウンタイムは想定されていません。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
Azure DNSは、特定の条件が満たされている限り、有効な DNS クエリ応答に対して 100% 可用性 SLA を提供します。 これらの条件には、少なくとも 60 秒間連続して失敗した要求を繰り返し再試行することや、ゾーンAzure DNS割り当てられているすべてのネーム サーバーの使用が含まれます。 詳細な条件については、SLA ドキュメントを確認してください。