AZ-104対策：Azure DNSとTraffic Managerについて

✅ AZ-104 ‐Azure DNSとTraffic Managerについて

🔰 DNSとは？

DNS（ドメインネームシステム）は、「名前（例: [www.contoso.com）」と「数字の住所（例): 52.170.12.4）」をお互いに変換するしくみです。これがあるおかげで、人は覚えやすい名前でアクセスでき、システムは正確に通信できます。

Azureでは、使い方に応じて次の2種類のDNSを使い分けます：

• パブリックDNS：外部のインターネットからアクセスするための名前解決用
• プライベートDNS：Azureの中だけで使うシステム同士の名前解決用

目的に応じて正しく使い分けることが、安定したシステム運用につながります。

---

📘 パブリックDNSとプライベートDNSの比較表

比較項目	パブリックDNSゾーン	プライベートDNSゾーン
解決対象	インターネット上の公開ドメイン	仮想ネットワーク内部の名前
主な用途	Webサービスの公開など	VM間の内部通信やサービス名解決
レコード登録	手動のみ	手動 or 仮想ネットワークによる自動登録可
仮想ネットワークリンク	不要	必須（リンク＋自動登録設定）
自動登録可否	❌ 非対応	✅ 対応（VM名など自動反映）
所有者確認	✅ TXTレコードによる確認が必要	❌ 不要
Traffic Managerとの併用	✅ DR構成で利用される	❌ 通常不要
注意点	公開されるため情報漏えいに注意	仮想ネットワークあたり1ゾーンのみ登録可

---

🧩 仮想ネットワークとDNS自動登録

• プライベートDNSゾーンを使用するには、仮想ネットワークへの「リンク」が必要。
• 自動登録をオンにすることで、VMのホスト名がDNSに自動的に登録される。
• 1つの仮想ネットワークは、1つの自動登録ゾーンにしかリンクできないため注意。

---

🔡 DNSレコードタイプと用途

レコード種別	用途	具体例	よくあるミス
A レコード	ホスト名 → IPアドレスを返す	www.exp01.com → 52.170.12.4	IP変更時、手動更新を忘れると接続不能
CNAME	ホスト名 → 別名ホスト名（FQDN）を返す	app.contoso.com → web01.contoso.com	CNAMEの多重指定や無限ループ設定
TXT	任意のテキスト情報（認証用など）DKIM/SPF	@ → "v=spf1 include:mail.contoso.com"	SPF構文ミス → メールが拒否される
PTR	IPアドレス → ホスト名を返す（逆引き）	4.12.170.52.in-addr.arpa → mail.contoso.com	正しく設定しないとメールがSPAM扱い

---

CNAME レコード (Canonical Name Record)補足

• Azureでの主な利用: Azure App Service、CDN、Front Door、Traffic Managerなど、FQDNで提供されるAzureサービスにカスタムドメインを割り当てる際に頻繁に利用します。
• 注意点:
  • 他のレコードとの共存はできません。CNAMEを設定したホスト名には、AレコードやMXレコード、TXTレコードなどを同時に設定することはできません。
  • この制約を回避するため、Azure DNSでは「エイリアスレコード」が提供されており、ルートドメイン（Zone Apex）にもAzureリソースを直接エイリアスできます。
• 利用シーン: myapp.azurewebsites.net のようなAzure提供のFQDNに対し、自分のカスタムドメイン（例: blog.test01.com）を使いたい時。

---

🚦 Traffic Manager + Azure DNS による可用性向上構成（DR構成）

Traffic Manager は、DNSベースのトラフィックルーティングサービスです。複数のエンドポイント間でトラフィックを分散し、自動フェイルオーバーにより高可用性 (HA) を提供、パフォーマンスと耐障害性を向上させます。障害時にもサービスを止めずに提供し続けるため、可用性向上構成として、Azure DNSとTraffic Managerの組み合わせが非常に有効です。

---

🗺 シナリオ例

東京リージョンで稼働中のWebアプリに障害が発生した場合、自動的に大阪リージョンのスタンバイアプリへ切り替える構成。

要素	説明
Azure DNS	ドメインの名前解決を提供（例：app.example.jp）
Traffic Manager	グローバルDNSルーティング。リクエストを稼働中エンドポイントに振り分け
Webアプリ（東京）	プライマリアプリケーション
Webアプリ（大阪）	スタンバイ（DR）アプリケーション

構成例（優先順位型ルーティング）

• Traffic Manager プロファイル作成時に「優先順位型（Priority）」を選択
• 優先順リスト：
  • 優先1：東京リージョンのApp Service（例: web-tokyo.azurewebsites.net）
  • 優先2：大阪リージョンのApp Service（例: web-osaka.azurewebsites.net）

---

🔁 動作の流れ

1. ユーザーが app.example.jp にアクセス。
2. Azure DNS が、app.example.jp に設定されたCNAMEレコード（your-tm-profile.trafficmanager.net を指す）を解決して返します。
3. ユーザーのDNSリゾルバーは、次にTraffic Managerのネームサーバーに your-tm-profile.trafficmanager.net の解決を問い合わせます。
4. Traffic Manager がヘルスチェックに基づき、最適なエンドポイント（東京または大阪のIPアドレス）を返します。
5. ユーザーのデバイスは返されたIPアドレスに接続します。
   • 東京が正常 → 東京に接続
   • 東京がダウン → 大阪へ自動で切り替え

---

🛠 設定手順（簡略）

1. App Service を2つ用意（東京・大阪）
2. Traffic Manager プロファイル作成
   • ルーティング方法：優先順位型（Priority）
   • 東京を優先1、大阪を優先2に設定
3. 各App Serviceに独自ドメインをバインド
   • 例：app.example.jp
4. Azure DNS にCNAMEレコードを設定
   • 名前：app.example.jp
   • 値：your-tm-profile.trafficmanager.net

---

基本的な利用方法: 最も一般的な方法は、Traffic ManagerプロファイルのFQDN（例: your-tm-profile.trafficmanager.net）を指すCNAMEレコードを、カスタムドメインのDNSゾーン（例: www.example.jp）に作成することです。

• Traffic Manager で CNAME レコードを使う場合
  ・対象はサブドメイン（例：www.example.jp、app.example.jp）
  ・Azure DNS 以外のDNSサービスでも利用可

• Traffic Manager で エイリアスレコードを使う場合
  ・対象はルートドメイン（例：example.jp）
  ・Azure DNS 専用の機能（他社DNSでは使えない）
  ・Aレコードのように動作しつつ、Traffic Manager を参照できる

🎯 メリットと補足

• 地理的冗長化：異なるリージョン間で高可用性を確保
• 自動フェイルオーバー：障害発生時も利用者に影響を与えにくい
• 柔軟なルーティング：以下の方法が選べる
• 優先順位型（障害対策）
• パフォーマンス型（最速レスポンス）
• 重みづけ型（トラフィック制御）

これにより、Azureだけでシンプルかつ堅牢な**DR構成（災害対策構成）**が実現できます。

✍️ 試験対策ポイントまとめ

• □ パブリックDNSには自動登録なし
• □ プライベートDNSは仮想ネットワークリンク＋自動登録設定が必要
• □ 仮想ネットワーク1つに対し、自動登録可能なDNSゾーンは1つまで
• □ Traffic ManagerとAzure DNSでDR構成を組める
• □ DNSレコード（A/CNAME/TXT/PTR）の違いと使い所は必修知識

---