Microsoft AZ-700: Azure DNS と名前解決 — 学習ガイド

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Network Engineer AZ-700 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

Azure DNS: パブリックゾーン、プライベートゾーン、およびトレードオフ

Azureは、パブリックDNSホスティングと、仮想ネットワークプレーンと緊密に統合されたプライベートDNS解決の両方を提供します。どちらを選択するかは、スコープ、制御、コスト、および運用オーバーヘッドの問題です。パブリックAzure DNSゾーン（Azure DNSでホスト）は、インターネット向けのドメイン名に適しており、グローバルエニーキャストエンドポイント、予測可能なAPI駆動の管理、クエリごとのスケーラビリティといった利点があります。Private DNSゾーンを使用すると、リンクされたVNet内でのみプライベートIPアドレスに解決されるゾーン名を権威づけることができます。これにより、Azure内の名前解決のためにDNS VMを実行・維持する必要がなくなり、特定のPaaSプライベートエンドポイントと統合した場合の自動レコード管理もサポートされます。主なトレードオフは制御です。カスタムDNSサーバー（Windows DNS、BIND）は、条件付きフォワーディング、高度なポリシー、AD統合されたSRV/CNAMEの動作など、絶対的な柔軟性を提供しますが、その代償としてVMの管理オーバーヘッドと回復性に対する責任が伴います。パフォーマンスの選択は、レイテンシとコストの比較になります。マネージドのAzure DNSサービスはメンテナンスを削減し、パブリッククエリに対してグローバルな解決速度を提供します。一方、ハブに常駐するDNSフォワーダーやリゾルバーアプライアンスは、ハイブリッド環境のパフォーマンスを向上させ、ポリシーを適用できますが、コンピューティングと可用性のコストが増加します。よくある落とし穴には、名前解決が必要なすべてのVNetにPrivate DNSゾーンをリンクし忘れること、オンプレミスからAzureにドメイン名を移行する際に委任の移行を怠ること、明示的なDNSレコードやフォワーディングなしでパブリックからプライベートへの自動的なスプリットホライズン動作を期待することなどがあります。

Azure DNS (パブリック): グローバルエニーキャスト、マネージドAPI、ゾーン/クエリごとの課金。
Private DNSゾーン: VNetスコープの名前解決、サポートされるPaaSに対するプライベートレコードの自動作成。
App Gateway WAF_v2: 最新のWAF機能とv2スケーリングモデルに推奨。
Azure Firewall (Standard/Policy): 中央DNSプロキシのオプション。コストは増加するがポリシーを集中管理できる。
カスタムDNS (VMベース): 最大限の制御が可能だが、運用と可用性のコストが高い。

Private DNSゾーン、プライベートエンドポイントのレコード、および命名戦略

パブリックにホストされているサービスをプライベートエンドポイントに変換したり、サーバーをAzureに移行したりする際、DNSが調整のポイントとなります。プライベートエンドポイントは、クライアントが使用するパブリックFQDNと一致する必要があるAレコードを、NICレベルでPrivate DNSゾーンに登録します。正しいパターンは、パブリック名前空間（例: contoso.com）をミラーリングするプライベートゾーンを作成するか、サービス固有のprivatelinkゾーン（プラットフォームサービス用）を使用し、その後、自動登録を有効にするか、FQDNをエンドポイントのプライベートIPにマッピングするA/CNAMEレコードを手動で作成することです。スコープは重要です。プライベートゾーンを単一のVNetにリンクすると、名前解決はそのVNetに限定されます。ハブアンドスポーク設計では、ゾーンをすべてのスポークにリンクするか、スポークからハブのリゾルバーへのDNSフォワーディングを使用する必要があります。典型的な移行の落とし穴は、AzureクライアントがプライベートIPに解決しているにもかかわらず、パブリックDNSが古いオンプレミスのIPを指したままにしてしまうことです。スプリットブレインによる混乱を避けるために、クリーンなカットオーバー手順を計画してください。つまり、プライベートDNSとフォワーディングが検証された後にのみパブリックレコードを更新するか、同じ名前に対して明示的なプライベートゾーンを使用するスプリットホライズン命名を利用します。証明書とホストヘッダーは一致させる必要があります。Application GatewayがプライベートバックエンドへのエンドツーエンドTLSを実行することを期待する場合、バックエンド証明書のCN/SANが、ゲートウェイがHostヘッダーとして送信するホスト名と一致することを確認してください。さもなければ、バックエンドのTLSは失敗します。

Azure Private Resolverとハイブリッド名前解決パターン

Azure Private Resolverは、DNS VMを所有することなく、Azure VNetとオンプレミスネットワーク間で、マネージドでスケーラブルなDNSフォワーディングを可能にします。設計パターンでは、通常、リゾルバーエンドポイントをハブVNetに配置します。受信エンドポイントはオンプレミスから（VPN/ExpressRoute経由で）Azureプライベートゾーンへのクエリを受け取り、送信エンドポイントはAzureからのクエリをオンプレミスのDNSサーバーに転送して内部専用の名前を解決します。リゾルバールールセットは、特定の名前空間（例: contoso.internal → オンプレミスDNSのIP）に対する条件付きフォワーディングを定義し、VNetに関連付けることができます。グローバルなエンタープライズ展開では、ハブでルール管理を集中化し、スポークからハブリゾルバーへトラフィックをピアリングまたはルーティングします。パフォーマンスとコストのトレードオフには、回復性とレイテンシのために複数のリージョンにわたって複数の受信エンドポイントをプロビジョニングする（コストが増加する）か、ピアリングを利用した単一リージョンのリゾルバーエンドポイントを受け入れるが、より高いリージョン間レイテンシを許容する、といった選択肢があります。よくある落とし穴は、オンプレミスの条件付きフォワーダーを更新してリゾルバーの受信IPを指すようにしないこと、リゾルバーエンドポイントへのDNS TCP/UDP 53をブロックするネットワークセキュリティグループのルールを誤って設定すること、そしてAzure提供のDNS（168.63.129.16）がオンプレミスに転送してくれると想定することです。条件付きフォワーディングには明示的なリゾルバーの設定が必要です。

DNSポート: 通常の名前解決とゾーン転送のために、53 UDPおよび53 TCPを許可する必要がある。
リゾルバーエンドポイント: ハブVNetにデプロイし、NSGとファイアウォールがインバウンドDNSを許可するようにする。

カスタムDNSサーバー、DNSプロキシ、および運用上の落とし穴

カスタムDNSサーバー（Windows DNSドメインコントローラーやLinux BIND）は、Active Directory統合、複雑な条件付きフォワーディング、または高度なDNSポリシーが必要な場合に依然として有効です。しかし、これらはパッチ適用、HAクラスタリング、バックアップ、スケーリングといった運用上の責任を伴います。運用を削減する代替案としては、Azure内の名前解決のためのAzure Private DNSゾーンや、転送ポリシーを一元化するためのAzure Private ResolverまたはAzure Firewall DNSプロキシがあります。DNSプロキシ（Azure Firewall DNSプロキシ機能またはサードパーティのNVA）は、DNSを傍受して選択したリゾルバーに転送できるため、ポリシーとログ記録が簡素化されますが、単一障害点や追加のレイテンシーを生む可能性があります。主要な設計上の決定事項には、ハブでVMベースのフォワーダーを使用するか（低コスト、高メンテナンス）、Azure Private Resolverを使用するか（マネージド、優れたスケーラビリティ）、レイテンシー/回復性のためにリージョンをまたいでいくつのリゾルバーエンドポイントをデプロイするか、プライベートエンドポイントのDNS自動登録を有効にするか、などが含まれます。エンジニアが犯しがちな間違いは、DNS解決をVNetピアリングのみに依存すること（ピアリングではPrivate DNSゾーンは自動的に共有されません）、Private EndpointにDNSレコードを自動登録する権限を付与し忘れること、ゲートウェイ経由でエンドツーエンドTLSを実装する際に証明書チェーンの検証を怠ることです。これらはすべて、本番環境での名前解決や安全な接続を妨げる原因となります。

実践的な問題：ユースケースシナリオ

シナリオ：Fabrikam社は、マルチリージョンのハブアンドスポークAzureネットワークを運用しています。East USのハブにはAzure Firewall (Standard) があり、Traffic Managerプロファイルがインターネットユーザーを2つのリージョンにあるApplication Gateway WAF_v2インスタンスにルーティングしています。2つのApp Serviceインスタンスがwww.fabrikam.comをホストしており、それぞれがオンプレミスから移行され、各リージョンのスポークにプライベートエンドポイントを持っています。

課題：移行後、オンプレミスのクライアントとAzureのスポークは、www.fabrikam.comをApp Serviceのプライベートエンドポイントに解決できなければなりません。また、Application GatewayはエンドツーエンドTLSを有効にするためにホストヘッダーを維持し、DNS解決はリージョン間で回復力を持つ必要があります。

推奨アプローチ：

ハブにfabrikam.comという名前のAzure Private DNSゾーンをデプロイし、両方のリージョンのスポークVNetとハブVNetにリンクします。www.fabrikam.comのAレコードを追加してプライベートエンドポイントのIPを指すようにするか、（App Serviceプライベートエンドポイントの自動登録を有効にします）。
ハブにAzure Private Resolverの受信エンドポイントをデプロイし（必要に応じて回復性のためにリージョンごとに1つ）、オンプレミスの条件付きフォワーダーを設定して、fabrikam.comのクエリをリゾルバーの受信IPに転送します。
Application Gateway WAF_v2のHTTP設定を構成してポート443でHTTPSを使用するようにし、バックエンドのホストヘッダーをwww.fabrikam.comに設定し、バックエンドの正常性プローブが証明書のCN/SANに一致するホストヘッダーを持つHTTPSを使用するようにします。
オンプレミスとスポークからDNSクエリを実行してプライベートIPが返されることを確認し、証明書のCN/SANとプローブの成功をチェックしてApplication GatewayのエンドツーエンドTLSを検証します。

理論的根拠：プライベートDNSとリゾルバー機能をハブに一元化することで、信頼できる唯一の情報源（single-source truth）を提供し、ハイブリッドの条件付きフォワーディングを簡素化します。プライベートゾーンをすべてのVNetにリンクし、ゲートウェイが正しいホストヘッダーを使用するようにすることで、エンドツーエンドTLSの証明書検証が維持され、運用の管理性、パフォーマンス、回復力のバランスが取れます。

← ハイブリッドネットワーク · すべてのドメイン · ネットワークセキュリティ →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →