DNS セキュリティとプライベート名解決

この記事では、プライベート DNS ゾーン、Azure DNS プライベートリゾルバー、および DNS セキュリティ制御を使用して、Azure ネットワークの DNS を設計する方法について説明します。プライベート名解決パターン、ハイブリッド DNS 転送、プライベートエンドポイント DNS 統合、DNS 層の脅威保護について説明します。

この記事の内容

DNS はネットワーク接続の基礎です。すべての接続は名前解決クエリで始まります。 Azureでは、DNS 設計によって、ワークロードが仮想ネットワーク間で相互に検出する方法、オンプレミスシステムがAzureホストされた名前を解決する方法、およびプライベートエンドポイントが完全修飾ドメイン名 (FQDN) によって到達可能になる方法が決まります。解決を超えて、DNS は攻撃対象領域でもあります。悪意のあるドメインへの DNS トンネリング、流出、クエリは、DNS 層のセキュリティ制御を必要とする実際の脅威を表します。

この記事では、次の 3 つの DNS の問題について説明します。

プライベート名解決:パブリックインターネットに DNS クエリを公開することなく、仮想マシン、コンテナー、プラットフォームサービスがAzure内の名前を解決する方法。
ハイブリッド DNS 転送:オンプレミスネットワークがプライベート名Azure解決する方法と、Azureワークロードがオンプレミス名を解決する方法。
DNS セキュリティ: 悪意のある DNS クエリをブロックし、DNS 流出を防ぎ、FQDN ベースのネットワークフィルター処理を有効にする方法。

この記事が必要なユーザー

次の場合は、この記事をお読みください。

プライベートエンドポイント (シナリオに該当する場合) をデプロイし、 DNS ゾーンを正しく解決するためにワークロードが必要です。
オンプレミスシステムが Azure のプライベート名を解決する必要があるハイブリッド環境を運用する (またはその逆方向)。
Azure Firewallを使用し、ネットワークルールで FQDN ベースのフィルター処理が必要です。
解決レイヤーで既知の悪意のあるドメインへの DNS クエリをブロックする。
一元化された DNS 解決によって操作が簡略化されるマルチ VNet 環境を管理します。
共有サービスを使用してハブスポークトポロジの DNS アーキテクチャを計画します。

リフトアンドシフトフォーカス: 移行中に既存の DNS 名前付け動作を保持します。オンプレミスの DNS とAzureの間で双方向転送を使用し、スプリットホライズン解決用の条件付きフォワーダーを構成し、アプリケーションが現在の DNS 構成を維持できるように、プライベート DNS ゾーンでプライベート名Azureホストします。

フォーカスを最新化する: ワークロードの再プラットフォーム化時に名前解決を一元化します。ハイブリッド解決用の転送ルールセットAzure DNSプライベートリゾルバーを使用し、プライベート DNS ゾーンを PaaS サービスのプライベートエンドポイントと統合し、FQDN ベースのルールと DNS 解決が 1 つのキャッシュされたパスを共有するようにAzure Firewall DNS プロキシを有効にします。

クラウド間のフォーカス: ワークロードの移行前に、クラウド間での DNS カットオーバーを計画します。クラウド間の名前解決には Azure DNS Private Resolver を使用し、AWS Route 53 Resolver または Google Cloud DNS で条件付き転送を構成し、カットオーバー前に TTL 値を下げて、古いキャッシュが残るリスクを軽減します。

Azureサービスと機能

次の表では、DNS セキュリティとプライベート名解決に関連するAzureサービスと機能について説明します。

サービス/機能	Purpose	主要な機能	いつ使用するか
Azure DNS (パブリックゾーン)	パブリックドメイン名の権限のあるホスティング	グローバルエニーキャストネットワーク、Azure RBAC 統合、Azure リソースのエイリアスレコード	パブリックドメインを所有しており、高可用性を備えたAzureで DNS レコードをホストする必要があります。
Azure プライベート DNS ゾーン	パブリックに公開されていない仮想ネットワーク内の名前解決	VNet のリンク、VM ホスト名の自動登録、プライベートリンクゾーンのホスティング	Azure ワークロードの内部名前解決。プライベートエンドポイント DNS 統合に必要です。
Azure DNS プライベートリゾルバー	Azureと外部ネットワーク間の DNS 転送	受信エンドポイント (オンプレミス → Azure 解決)、送信エンドポイント (Azure → オンプレミス転送)、転送ルールセット	カスタム DNS VM をデプロイせずに双方向 DNS 解決を必要とするハイブリッド環境。
AZURE FIREWALL DNS プロキシ	FQDN フィルター処理の一元化された DNS インターセプト	DNS 応答をキャッシュし、FQDN ベースのネットワーク規則を有効にし、スポーク VNet に単一の DNS エンドポイントを提供します	Azure Firewallを展開し、ネットワークルールで FQDN フィルター処理が必要です。一貫性のある FQDN 解決に必要です。
DNS セキュリティポリシー	DNS レイヤーでの脅威保護	Microsoft Threat Intelligence フィードを使用して、既知の悪意のあるドメイン名の解決をブロックする	ワークロードがコマンドアンドコントロールまたはマルウェア配布ドメインに接続できないようにする必要があります。

プライベート DNS ゾーンの概念

プライベート DNS ゾーンは、インターネットにレコードを公開することなく、リンクされた仮想ネットワークの名前解決を提供します。主な動作:

VNet のリンク: プライベート DNS ゾーンを複数の VNet にリンクできます。リンクされた VNet 内のすべてのリソースは、ゾーン内のレコードを解決できます。
自動登録:VNet リンクで有効にすると、Azureはその VNet にデプロイされた仮想マシンの A レコードを自動的に作成します。 Azure VM の割り当てを解除または削除すると、レコードが削除されます。自動登録は VM に対してのみ機能します (プライマリ NIC のみ)。 VNet は 1 つのプライベート DNS ゾーンにのみ自動登録できますが、複数の VNet を同じゾーンにリンクできます。
プライベートエンドポイント DNS: プライベートエンドポイントを介してアクセスされるAzure サービスには、特定のプライベートリンク DNS ゾーン (たとえば、Azure Blob Storageのprivatelink.blob.core.windows.net) が必要です。正しいゾーンがない場合、クライアントはプライベートエンドポイントアドレスではなくパブリック IP を解決します。

DNS プライベートリゾルバーのアーキテクチャ

Azure DNSプライベートリゾルバーは、ハイブリッド転送シナリオでのカスタム DNS 仮想マシンの必要性に代わるものになります。次の図は、オンプレミスからプライベートリゾルバー Azure DNSプライベートエンドポイント IP アドレスへのハイブリッド DNS 解決フローを示しています。

リゾルバーは、次の 2 種類のエンドポイントを使用します。

受信エンドポイント: オンプレミスの DNS サーバーが条件付きフォワーダーとしてターゲットにできる IP アドレスを提供します。 Azure DNSは、この IP に送信されたクエリ (リンクされたプライベート DNS ゾーンを含む) を解決します。 Microsoft.Network/dnsResolversに委任された専用サブネットが必要です。
送信エンドポイント:Azureワークロードがオンプレミスの DNS サーバー、他のクラウドプロバイダー、または外部リゾルバーに DNS クエリを転送できるようにします。専用サブネットも必要です。送信エンドポイントにアタッチされている転送ルールセットは、転送するドメインサフィックスと使用するターゲット DNS サーバーを定義します。

Important

受信エンドポイントと送信エンドポイントには、それぞれ独自の専用サブネットが必要です。これらのサブネットに他のリソースをデプロイすることはできません。転送ルールセットにリンクされている VNet をリゾルバー VNet とピアリングする必要はありません。ルールセットリンクは、VNet ピアリングとは独立して機能します。

選択する方法

次のデシジョンツリーを使用して、環境に適した DNS コンポーネントを選択します。

デシジョンツリー

プライベートエンドポイントを使用していますか?
- はい→適切なprivatelink.*ゾーン名を持つプライベート DNSゾーンをデプロイします。プライベートエンドポイントアドレスを解決する必要がある VNet にゾーンをリンクします。
オンプレミスシステムは Azure プライベート名に解決する必要がありますか?
- はい→受信エンドポイントを使用して DNS プライベートリゾルバーをデプロイします。受信エンドポイント IP を指す条件付きフォワーダーを使用して、オンプレミスの DNS サーバーを構成します。
Azureワークロードはオンプレミスの名前を解決する必要がありますか?
- はい→送信エンドポイントを使用して DNS プライベートリゾルバーをデプロイします。オンプレミスドメインサフィックス (たとえば、 corp.contoso.com) の転送ルールセットを作成します。
Azure Firewallを展開し、ネットワークルールで FQDN フィルター処理が必要ですか?
- はい →ファイアウォール DNS プロキシを有効にします。ファイアウォールプライベート IP を DNS サーバーとして使用するようにスポーク VM を構成します。
既知の悪意のあるドメインへの DNS クエリをブロックしますか?
- はい →ターゲット VNet の脅威インテリジェンスフィードMicrosoft DNS セキュリティポリシーを有効にします。

一般的なパターン

パターン	Components	利用シーン
プライベートエンドポイントの解決のみ	プライベート DNS ゾーン + VNet リンク	プライベートエンドポイントを介して PaaS サービスにアクセスするクラウド専用ワークロード。ハイブリッド接続なし。
ハイブリッド双方向解決	プライベート DNS ゾーン + DNS プライベートリゾルバー (受信 + 送信)	オンプレミスでは Azure のプライベート名を解決し、Azure ではオンプレミスの Active Directory 名を解決します。
一元化されたハブ DNS	ハブ VNet 内の DNS プライベートリゾルバー + スポークにリンクされた転送ルールセット	すべての DNS 解決がハブを経由して一元的なログ記録と制御を行うハブスポークトポロジ。
ファイアウォール仲介型 DNS	AZURE FIREWALL DNS プロキシ + プライベート DNS ゾーン	FQDN フィルター処理にファイアウォールを使用する環境。ファイアウォールは DNS をインターセプトし、ネットワーク規則に対して一貫した FQDNto-IP 解決を有効にします。
完全なセキュリティスタック	上記のすべてのオプションと DNS セキュリティポリシー	ハイブリッド解決、FQDN フィルタリング、DNS 層の脅威保護を必要とするエンタープライズ環境。

プライベートエンドポイント DNS ゾーンの例

次の表に、一般的なAzure サービスとその必要なプライベート DNS ゾーン名を示します。

Azure サービス	プライベート DNS ゾーン名
Azure Blob Storage	`privatelink.blob.core.windows.net`
Azure SQL Database	`privatelink.database.windows.net`
Azure Key Vault	`privatelink.vaultcore.azure.net`
Azure Files	`privatelink.file.core.windows.net`
Azure Container Registry	`privatelink.azurecr.io`
Azure Cosmos DB (SQL API)	`privatelink.documents.azure.com`

Note

すべてのAzure サービスのプライベート DNS ゾーン名の完全な一覧については、プライベートエンドポイントの DNS 構成Azure参照してください。

Prerequisites

DNS セキュリティとプライベート名解決を実装する前に、次の機能があることを確認してください。

仮想ネットワーク: すべての DNS 機能は、仮想ネットワーク内または仮想ネットワーク間で動作します。基本的なガイダンスについては、仮想ネットワークとサブネットに関するページを参照してください。 (F1)
ハイブリッドシナリオのネットワーク接続: DNS プライベートリゾルバーの受信エンドポイントでは、オンプレミス (ExpressRoute または VPN) からリゾルバー VNet へのネットワーク到達可能性が必要です。
DNS プライベートリゾルバーの専用サブネット: 各エンドポイント (受信と送信) には、 Microsoft.Network/dnsResolversに委任された独自のサブネットが必要です。エンドポイントサブネットごとに少なくとも /28 を計画します。
デプロイされたプライベートエンドポイント (プライベートリンクゾーンを使用する場合):privatelink.*名のプライベート DNSゾーンは、プライベートエンドポイントが存在する場合にのみ値を提供します。デプロイのガイダンスについては、プライベートエンドポイントを使用したプライベート PaaS アクセスに関するページを参照してください。 (C5)
Azure Firewallデプロイ済み (DNS プロキシを使用している場合): DNS プロキシ機能には、既存のAzure Firewall インスタンスが必要です。 Azure Firewallとトラフィック検査を参照してください。 (S1)
アクセス許可: プライベート DNS ゾーンを管理するための DNS ゾーン共同作成者ロール。 DNS プライベートリゾルバーの展開用ネットワーク共同作成者

セキュリティに関する考慮事項

DNS には、専用の制御を必要とする特定の攻撃ベクトルが導入されています。次のセクションでは、流出リスク、脅威インテリジェンスベースのブロック、ファイアウォール DNS プロキシの動作、および DNSSEC の制限について説明します。

DNS 流出リスク

DNS トンネリングでは、DNS クエリ内のデータがエンコードされ、それ以外の場合は無制限のプロトコルを介して情報が流出します。ほとんどのネットワークでは送信 DNS (UDP/TCP 53) が許可されているため、攻撃者は DNS を隠れチャネルとして使用します。このリスクを軽減するには、次の方法を使用します。

Azure Firewall DNS プロキシを有効にし、すべての DNS トラフィックをファイアウォール経由でルーティングする。ファイアウォールはすべての DNS クエリをログに記録し、分析を介してトンネリングを検出できるようにします。
既知の流出ツールとコマンドアンドコントロールインフラストラクチャに関連付けられているドメインの解決をブロックするために DNS セキュリティポリシーを適用する。
異常に長いサブドメインラベル、1 つのドメインに対する大量のクエリ、最近登録されたドメインへのクエリなどの異常がないか、Azure Monitorの DNS クエリパターンを監視します。

DNS セキュリティポリシー

Microsoft Threat Intelligence を使用した DNS セキュリティポリシーにより、VNet レベルで既知の悪意あるドメインへの DNS 名前解決がブロックされます。ワークロードが、Microsoft Security Response Center (MSRC) によってフラグ付けされたドメインを解決しようとすると、ネットワーク接続が発生する前に、ポリシーによって解決がブロックされます。この制御はAzure Firewallとは独立して動作し、個々のワークロード構成を変更する必要はありません。

主な特性:

MSRC から提供Microsoft脅威インテリジェンスフィードを使用します。
DNS 解決レイヤーで動作します。トラフィックではなく、クエリをブロックします。
VNet ごとに適用: インターネットにアクセスするワークロードを含むすべての VNet で有効にします。
ファイアウォール FQDN フィルタリングとは異なる: DNS セキュリティポリシーは、ファイアウォールの展開を必要とせずに、悪意のあるドメインをグローバルにブロックします。

ファイアウォール DNS プロキシと FQDN フィルター処理

AZURE FIREWALL DNS プロキシは、ネットワークルールでの FQDN ベースのフィルター処理に必要です。 DNS プロキシがないと、クライアント VM からの DNS 要求がファイアウォールの解決とは異なる時間に解決され、IP から FQDN へのマッピングとルールの不一致が一貫性を失う可能性があります。

DNS プロキシを有効にする場合:

ファイアウォールプライベート IP を DNS サーバーとして使用するようにスポーク VM を構成します。
ファイアウォールは、クライアントに代わってクエリを解決し、結果をキャッシュします (正のキャッシュは最大 1 時間、負のキャッシュは最大 30 分)。
FQDN-to-IP マッピングは 15 秒ごとに更新されます。ファイアウォールは、15 分後に古いエントリを削除します。
アプリケーションルール (L7) では、FQDN 照合にサーバー名表示 (SNI) が使用され、DNS プロキシは必要ありません。ネットワーク規則 (L4) では、FQDN 解決に DNS プロキシが必要です。
ネットワークルールでの FQDN フィルター処理では、ドメインの完全一致のみがサポートされます。ワイルドカードパターンは、ネットワークルールの FQDN ではサポートされていません。ワイルドカード FQDN 照合にはアプリケーションルールを使用します。

Note

構成されているすべてのアップストリーム DNS サーバーが使用できなくなった場合、Azure Firewall DNS プロキシは代替リゾルバーにフォールバックしません。 DNS 解決は、少なくとも 1 つのアップストリームサーバーが復旧するまで失敗します。アップストリーム構成で DNS サーバーの冗長性を計画します。

Caution

DNS プロキシを有効にしても、ファイアウォールを DNS サーバーとして使用するようにクライアント VM を構成していない場合、FQDN ベースのネットワーク規則は正しく機能しません。クライアントとファイアウォールが同じ FQDN の異なる IP を解決し、予期しないトラフィックがドロップする可能性があります。

DNSSEC の制限事項

Azure DNSは現在、プライベートゾーンの DNSSEC 検証をサポートしていません。 Azure DNSでホストされているパブリックゾーンは、権限のある応答の DNSSEC 署名をサポートしますが、Azure仮想ネットワーク内の再帰的解決では DNSSEC 検証は実行されません。セキュリティ要件で DNSSEC 検証が義務付けられている場合は、検証をサポートするカスタム DNS リゾルバーを使用して評価するか、アプリケーション層の検証を実装します。

設計上の考慮事項

リフトアンドシフト DNS の設計に重点を置く

オンプレミスの DNS サーバーとプライベートリゾルバー Azure DNS間の双方向 DNS 転送を構成します。
条件付きフォワーダーを使用して、Azureホスト名のオンプレミスクエリがAzureで解決されるようにし、オンプレミス名のAzureクエリは既存の DNS インフラストラクチャを介して解決されるようにします。
移行されたワークロードで使用される各Azure サービス (特にプライベートエンドポイントベースのサービス) に対して、プライベート DNS ゾーンを作成します。
クライアントリゾルバーの設定を変更するのではなく、エイリアスレコードまたは CNAME マッピングを使用して、移行中のアプリケーション DNS の動作を保持します。

DNS 設計の焦点を最新化する

スポーク仮想ネットワーク間で共有される転送ルールセットAzure DNSプライベートリゾルバーを使用して、ハブ内の DNS 解決を一元化します。
各 Private Endpoint 対応 PaaS サービスに対してプライベート DNS ゾーンをリンクし、再プラットフォーム化したワークロードが privatelink 名を自動的に解決できるようにします。
AZURE FIREWALL DNS プロキシを有効にして、FQDN ベースのネットワーク規則とワークロード DNS 解決で一貫性のあるキャッシュされた解決パスを使用できるようにします。
プライベート DNS ゾーンで自動登録とAzure RBAC を使用して、コードとしてのインフラストラクチャを採用する際の手動レコード管理を減らします。

クラウド間の DNS 設計に重点を置く

Azure DNSプライベートリゾルバーを、クラウド間の名前解決の転送制御ポイントとして使用します。
環境間で解決する必要があるプライベート名前空間ごとに、Azureプライベート DNS、AWS Route 53 リゾルバー、Google Cloud DNS の間で条件付き転送を構成します。
DNS のカットオーバーを段階的に計画する: TTL 値の低下、転送パスの検証、CNAME または A レコードの変更、クエリの待機時間とキャッシュ動作の監視。
接続されているプラットフォームでサポートされている権限のあるゾーンに DNSSEC を適用し、プライベート解決パスが DNSSEC を検証しない場所を文書化します。

プライベートエンドポイントを使用したプライベート PaaS アクセス: プライベートエンドポイントのデプロイとプライベートリンク DNS ゾーンの構成。
Azure Firewallとトラフィック検査: ファイアウォール DNS プロキシの構成と FQDN フィルター処理。
仮想ネットワークとサブネット: DNS リゾルバーエンドポイントのサブネット計画を含む VNet の基礎。
ハブスポークネットワークトポロジ: ハブスポークアーキテクチャでの一元化された DNS 解決。
設計フェーズの概要: 計画、接続性、セキュリティ、運用に関する決定全体にわたるフェーズベースの概要。

詳細情報

次のステップ

Tip

あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。

リフトアンドシフト体験の次の手順:

送信インターネットトラフィックを制御する: Azure Firewall経由ですべての送信通信を一元化し、既定の送信アクセスをオフにします。

次に、最新化の取り組みを行います。

運用環境の監視を設定する: 1 日目から運用の準備のために、Network Watcherとネットワークのパフォーマンスモニターを有効にします。

マルチクラウドへの移行における次のステップ:

クラウド間のトランジットパスをセキュリティで保護する: セキュリティで保護された仮想ハブにAzure Firewallをデプロイして、すべてのクロスクラウド、ブランチ、インターネットにバインドされたトラフィックを検査します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-01