MENU

Azure DNSとTraffic Managerの直接連携とは？CNAME不要化・DNSSEC・設定手順

Azure

Azure DNSとTraffic Managerの直接連携を使うと、Azure DNSのレコードセットをTraffic Managerプロファイルへ直接関連付けられます。従来必要だったxxxx.trafficmanager.netへの中間CNAMEをDNS応答から取り除き、クライアント側から見たDNS Lookupを1段減らせる仕組みです。

この機能は「Traffic Manager Linked Records」と呼ばれ、2026年8月にPublic Previewとして公開されました。2026年9月3日時点でもプレビュー段階です。新規構成では有力な選択肢ですが、重要な本番環境へ導入する場合は、プレビュー機能の利用基準や切り戻し手順を確認したうえで採用する必要があります。

特に効果が大きいのは、DNSSEC署名済みゾーン、ゾーン頂点での負荷分散、trafficmanager.netへの名前解決を許可しにくい環境です。一方、単にCNAMEが1つ減るだけでアプリケーション通信全体が劇的に高速化するわけではありません。DNSキャッシュやネットワーク環境も含めて評価することが重要です。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Azure DNSとTraffic Managerの直接連携で何が変わるのか

Traffic Managerは、エンドポイントの正常性やルーティング方式に応じて、DNS問い合わせに返す宛先を選択するDNSベースのロードバランサーです。

従来は、独自ドメインからTraffic Managerを利用するとき、次のようなCNAME構成が一般的でした。

www.example.com
  ↓ CNAME
production-app.trafficmanager.net
  ↓ AまたはAAAA
正常なエンドポイントのIPアドレス

この構成では、リカーシブDNSリゾルバーが最初にwww.example.comを問い合わせ、その応答に含まれるproduction-app.trafficmanager.netをさらに解決します。

Traffic Manager Linked Recordsを利用すると、Azure DNSがTraffic Managerプロファイルを内部で参照し、選択されたエンドポイントの値を直接返します。

www.example.com
  ↓ AまたはAAAA
正常なエンドポイントのIPアドレス

Azure DNSのレコードセットには、従来のtargetResourceではなく、新しいtrafficManagementProfileプロパティでTraffic Managerプロファイルとの関連を設定します。Azure DNSが中間の名前を内部で解決する処理は、DNS flatteningと呼ばれます。Linked Recordsでは、この統合解決モードが常に使用されます。(Microsoft Learn)

なお、直接連携によって変わるのはDNS応答です。Traffic ManagerがHTTPやHTTPS通信を中継するようになるわけではありません。名前解決後のアプリケーション通信は、引き続き選択されたエンドポイントへ直接送信されます。

「CNAMEが不要になる」の正確な意味

Traffic Manager Linked Recordsで不要になるのは、Traffic Managerプロファイルのtrafficmanager.netドメインを指す中間CNAMEです。

Linked Recordsがサポートするレコードタイプには、A、AAAAだけでなくCNAMEも含まれます。そのため、CNAMEタイプのLinked Recordを選んだ場合、DNS応答そのものがCNAMEではなくなるわけではありません。

Linked RecordのタイプAzure DNSが返す値Traffic Manager側の要件
A選択されたIPv4アドレス有効なエンドポイントがIPv4ターゲットであること
AAAA選択されたIPv6アドレス有効なエンドポイントがIPv6ターゲットであること
CNAME選択されたエンドポイントのFQDN有効なエンドポイントがFQDNターゲットであること

CNAMEタイプでも、profile-name.trafficmanager.netという中間名はクライアントへ返されません。Traffic Managerが選択した最終的なエンドポイントのFQDNが直接返されます。(Microsoft Learn)

直接連携による主なメリット

DNS Lookupを1段減らせる

従来のCNAME構成では、独自ドメインとtrafficmanager.netを別々に問い合わせる必要がありました。Linked RecordsではAzure DNSが内部でTraffic Managerを参照するため、クライアントやリカーシブDNSリゾルバーから見た中間CNAME問い合わせが不要になります。

ただし、短縮されるのはDNS解決経路の1段です。Webページ全体の表示速度は、DNSキャッシュ、TLS接続、サーバー応答時間、コンテンツ配信方式などにも左右されます。導入効果を確認するときは、初回DNS解決とキャッシュ済みアクセスを分けて測定する必要があります。

DNSSECの信頼チェーンを維持しやすい

従来のCNAMEチェーンでは、DNSSEC署名済みの独自ドメインから、署名されていないtrafficmanager.netが中間に入ることが問題になります。

Linked Recordsでは、Azure DNS内でTraffic Managerプロファイルが解決されるため、DNS応答に署名されていないtrafficmanager.netの中間ホップが現れません。Microsoftは、これにより負荷分散レコードでDNSSECの信頼チェーンを維持できると説明しています。

ただし、Linked Recordsを作成するだけでDNSSECが自動的に有効になるわけではありません。対象のAzure DNSゾーンをDNSSECで署名し、必要な委任設定まで正しく完了していることが前提です。

trafficmanager.netを外部へ見せずに済む

Linked Recordsを使用すると、DNS応答にtrafficmanager.netが含まれません。

DNS問い合わせ先や名前解決対象を厳密に制限している環境では、共有ドメインであるtrafficmanager.netを許可対象に追加せずに済みます。Microsoftは、不要な共有ドメインへの許可を減らすことで、ファイアウォール構成を簡素化し、攻撃対象を狭められると説明しています。(Microsoft Learn)

ゾーン頂点でも利用できる

通常のDNS仕様では、ゾーン頂点にCNAMEを配置できません。

たとえば、次のようなルートドメインをTraffic Managerへ直接向ける構成です。

example.com

Linked Recordsでは、AまたはAAAAレコードとして最終IPアドレスを直接返せるため、www.example.comだけでなく、ゾーン頂点のexample.comでもTraffic Managerを利用できます。(Microsoft Learn)

エンドポイントの型不一致を防止できる

Traffic Manager Linked Recordsでは、Strictly Typed Profilesという仕組みが使われます。

Traffic ManagerプロファイルにA、AAAA、CNAMEのレコードタイプを設定し、それと一致しないエンドポイントが追加されることをTraffic Manager側で防ぎます。

従来のエイリアスレコードでは、レコード作成時点を中心とした検証でした。Strictly Typed Profilesでは、その後に追加されるエンドポイントにも型の整合性が適用されるため、運用中の設定ミスを減らせます。(Microsoft Learn)

従来のAzure DNSエイリアスレコードとの違い

Azure DNSには以前から、targetResourceを使用してTraffic Managerプロファイルを参照するエイリアスレコードがあります。Linked Recordsは、その単なる名称変更ではありません。

比較項目エイリアスレコードTraffic Manager Linked Records
関連付けプロパティtargetResourcetrafficManagementProfile
解決方式A、AAAAは統合可能。CNAMEでは中間参照が発生常に統合解決
TTLレコードセット側の設定を使用する構成があるTraffic Managerプロファイルから継承
型の検証Azure DNS側で作成時を中心に検証Traffic Manager側で継続的に強制
trafficmanager.netの表示CNAME構成では表示される表示されない
DNSSEC中間CNAMEが課題になるDNSSEC互換として提供
ネストされたプロファイルTraffic Manager向けエイリアスでは非対応すべてのプロファイルタイプで対応
参照可能なAzureリソースPublic IP、Front Doorなども参照可能Traffic Manager専用
1プロファイル当たりの上限50リンク50リンク

Microsoftは、Traffic Managerへ新しくDNSレコードを関連付ける場合、Linked Recordsを推奨しています。一方、Public IPやFront Doorなど、Traffic Manager以外のAzureリソースを参照する用途では、従来のエイリアスレコードが引き続き必要です。(Microsoft Learn)

Strictly Typed Profilesで注意すべき点

プロファイルのレコードタイプは後から変更できない

Traffic Managerプロファイルにレコードタイプを設定すると、その値は固定されます。Linked Recordを削除しても、プロファイルのタイプ設定が解除されるわけではありません。

既存プロファイルをLinked Recordsへ移行するときは、現在登録されているエンドポイントが、設定予定のレコードタイプと一致しているか先に確認してください。

同じプロファイルをAとAAAAの両方には使えない

AタイプのプロファイルはIPv4用、AAAAタイプのプロファイルはIPv6用として固定されます。同じTraffic ManagerプロファイルをAレコードとAAAAレコードの両方へ同時にリンクすることはできません。

IPv4とIPv6のデュアルスタック構成では、A用とAAAA用でTraffic Managerプロファイルを分けるなど、プロファイル設計を事前に整理する必要があります。(Microsoft Learn)

TTLはAzure DNSレコード側ではなくTraffic Manager側で決まる

Linked RecordsのTTLは、Traffic ManagerプロファイルのDNS設定から継承されます。Azure DNSレコードセット側で入力したTTLは使用されません。

フェールオーバー時間を調整するときは、Azure DNSレコードのTTLではなく、Traffic ManagerプロファイルのTTLとエンドポイント監視設定を確認します。TTLを短くしても、リゾルバーのキャッシュやエンドポイント障害の検出時間があるため、設定秒数どおりに必ず切り替わるわけではありません。(Microsoft Learn)

Azure portalで直接連携を設定する手順

事前に準備するもの

次のリソースを準備します。

  • Azure DNSでホストしているパブリックDNSゾーン
  • Azure Traffic Managerプロファイル
  • Traffic Managerに登録する正常性監視可能なエンドポイント
  • DNSゾーンとTraffic Managerプロファイルを操作できるAzure権限

また、Microsoft.Networkリソースプロバイダーを登録しておく必要があります。

az provider register --namespace Microsoft.Network

Azure DNSゾーンとTraffic Managerプロファイルが異なるサブスクリプションにある場合は、両方のサブスクリプションでMicrosoft.Networkを登録します。(Microsoft Learn)

Traffic Managerプロファイルのタイプを設定する

Azure portalでTraffic Managerプロファイルを作成し、次のいずれかのレコードタイプを選択します。

  • IPv4エンドポイントを返す場合はA
  • IPv6エンドポイントを返す場合はAAAA
  • FQDNを返す場合はCNAME

この選択がStrictly Typed Profilesのタイプになります。作成後は変更できないため、特にIPv4とIPv6の選択を間違えないようにしてください。

続いて、設定したタイプと一致するエンドポイントをTraffic Managerプロファイルへ追加します。

Azure DNSでLinked Recordを作成する

Azure portalで対象のDNSゾーンを開き、次の手順で設定します。

  1. DNSゾーンの［概要］を開く
  2. ［+ レコード セット］を選択する
  3. 名前を入力する
  4. A、AAAA、CNAMEからタイプを選択する
  5. ［Enable Traffic Management（Preview）］を有効にする
  6. Traffic Managerプロファイルが存在するサブスクリプションを選択する
  7. 関連付けるTraffic Managerプロファイルを選択する
  8. 設定を保存する

ゾーン頂点へ作成する場合、レコード名は空欄にします。サブドメインならwwwなどを入力します。

Linked RecordのTTLはTraffic Managerプロファイルから継承されるため、Azure DNS側の画面では個別に設定できません。また、Linked Record経由のDNS問い合わせはTraffic Managerプロファイルの課金対象としてカウントされます。(Microsoft Learn)

Azure CLIでAタイプのLinked Recordを作成する例

Azure CLIで作成する場合は、最初にTraffic ManagerプロファイルのリソースIDを取得します。

DNS_RESOURCE_GROUP="dns-rg"
DNS_ZONE="example.com"
TM_RESOURCE_GROUP="traffic-rg"
TM_PROFILE_NAME="production-tm"

TM_PROFILE_ID=$(az network traffic-manager profile show \
  --resource-group "$TM_RESOURCE_GROUP" \
  --name "$TM_PROFILE_NAME" \
  --query id \
  --output tsv)

ゾーン頂点にAレコードを作成する例は次のとおりです。

az network dns record-set a create \
  --resource-group "$DNS_RESOURCE_GROUP" \
  --zone-name "$DNS_ZONE" \
  --name "@" \
  --traffic-management-profile "$TM_PROFILE_ID"

www.example.comへ作成する場合は、--name "@"を--name "www"へ変更します。

az network dns record-set a create \
  --resource-group "$DNS_RESOURCE_GROUP" \
  --zone-name "$DNS_ZONE" \
  --name "www" \
  --traffic-management-profile "$TM_PROFILE_ID"

作成結果を確認します。

az network dns record-set a show \
  --resource-group "$DNS_RESOURCE_GROUP" \
  --zone-name "$DNS_ZONE" \
  --name "@"

出力に次のようなtrafficManagementProfileプロパティがあれば、Traffic Managerプロファイルとの関連付けが作成されています。

{
  "trafficManagementProfile": {
    "id": "/subscriptions/.../providers/Microsoft.Network/trafficManagerProfiles/production-tm"
  }
}

Microsoftのチュートリアルでは、--traffic-management-profileを使用するためにAzure CLI 2.60以降と、2024-06-01-preview以降のTraffic Manager Linked Records対応APIが必要とされています。実行環境が古い場合は、先にAzure CLIを更新してください。(Microsoft Learn)

DNS応答を確認する方法

通常利用しているDNSリゾルバーだけでテストすると、以前のCNAMEやIPアドレスがキャッシュに残っていることがあります。切り替え直後は、Azure DNSの権威DNSサーバーを直接指定して確認すると判断しやすくなります。

最初に、対象ゾーンのネームサーバーを取得します。

AUTHORITATIVE_NS=$(az network dns record-set ns show \
  --resource-group "$DNS_RESOURCE_GROUP" \
  --zone-name "$DNS_ZONE" \
  --name "@" \
  --query "nsRecords[0].nsdname" \
  --output tsv)

echo "$AUTHORITATIVE_NS"

Aレコードを問い合わせます。

nslookup example.com "$AUTHORITATIVE_NS"

digを使用できる環境では、次のように確認できます。

dig @"$AUTHORITATIVE_NS" example.com A +noall +answer

AタイプのLinked Recordであれば、応答には正常なTraffic ManagerエンドポイントのIPv4アドレスが表示され、trafficmanager.netへのCNAMEは表示されません。CNAMEタイプでは、Traffic Managerが選択したエンドポイントのFQDNが返されることを確認します。(Microsoft Learn)

既存CNAMEから安全に移行する手順

既存の本番ドメインをいきなり置き換えるのではなく、テスト用ホスト名で動作を確認してから移行する方法が安全です。

手順作業内容確認するポイント
現状確認現在のCNAME、TTL、Traffic Manager設定を記録切り戻しに必要な値を保存する
型の確認エンドポイントがIPv4、IPv6、FQDNのどれか確認Linked Recordのタイプと一致させる
テストレコード作成tm-test.example.comなどを作成直接IPまたは最終FQDNが返るか
障害試験優先エンドポイントを一時停止正常な予備エンドポイントへ切り替わるか
DNSSEC確認DNSSEC検証対応リゾルバーで問い合わせ検証エラーが発生しないか
本番切り替え既存CNAMEをLinked Recordへ置換権威DNSと一般リゾルバーの両方を確認
監視DNS応答、エンドポイント状態、アプリログを確認キャッシュ満了後も正常か

切り替え前には、既存CNAMEのTTLを事前に短くします。Linked Record作成後のTTLはTraffic Managerプロファイル側から継承されるため、切り替え後のフェールオーバー要件に合わせてTraffic Manager側も確認してください。

同一ホスト名をCNAMEからAまたはAAAAへ変更する場合、既存レコードと新レコードを単純に並存させるのではなく、変更作業として置き換えます。切り戻し用に、元のCNAME名、TTL、Traffic Managerプロファイル名を記録しておくことが重要です。

導入前に確認したい注意点

Public Previewである

2026年9月3日時点では一般提供ではなくPublic Previewです。組織のクラウド利用基準でプレビュー機能を本番環境に使用できるか確認してください。一般提供時期は公式情報で明示されていません。

Azure DNSのパブリックゾーンが必要

Linked RecordsはAzure DNSの機能です。権威DNSを他社DNSサービスで運用したまま、同じ仕組みだけを利用することはできません。

また、Traffic ManagerはDNSベースでインターネット公開エンドポイントを選択するサービスです。プライベートIP間の内部ロードバランシングや、HTTPリバースプロキシ、WAFの代替ではありません。(Microsoft Learn)

Traffic Managerの削除順序に注意する

Linked Recordが参照しているTraffic Managerプロファイルは、そのままでは削除できません。先にAzure DNS側のLinked Recordを削除し、その後でTraffic Managerプロファイルを削除します。

この削除保護により、Traffic Managerプロファイルだけを誤って消し、DNSレコードを壊す事故を防げます。(Microsoft Learn)

フェールオーバー時間はTTLだけでは決まらない

Traffic Managerが返す宛先は、ルーティング方式、エンドポイント監視結果、プロファイルのTTLによって変化します。

Priority、Weighted、Performance、Geographicなど、利用しているルーティング方式の動作自体はLinked Recordsへ移行しても変わりません。障害発生から切り替わるまでには、正常性監視による検出時間とDNSキャッシュの有効期限が影響します。(Microsoft Learn)

Traffic Manager Linked Recordsを選ぶ判断基準

次の条件に該当する場合は、Azure DNSとTraffic Managerの直接連携を優先的に検証する価値があります。

  • 新しくTraffic Manager対応ドメインを作成する
  • DNSSEC署名済みゾーンで負荷分散したい
  • trafficmanager.netをDNS応答や許可リストへ出したくない
  • ゾーン頂点をTraffic Managerで負荷分散したい
  • エンドポイントのIPv4、IPv6型不一致を防ぎたい
  • ネストされたTraffic Managerプロファイルを利用したい

一方、次の環境では、既存構成を直ちに変更せず、プレビュー検証を先に行う方が適切です。

  • 重要な本番システムでプレビュー機能が禁止されている
  • 現在のCNAME構成に性能上、運用上の問題がない
  • DNSゾーンをAzure DNS以外で管理している
  • デュアルスタック構成でA用、AAAA用プロファイルの分離設計が未完了
  • IaCや運用ツールがtrafficManagementProfileに対応しているか未確認
  • DNSSECとフェールオーバーの試験環境を用意できていない

Azure DNSとTraffic Managerの直接連携は、単にCNAMEを省略する機能ではありません。DNS Lookupの中間ホップ削減、DNSSEC互換性、ゾーン頂点対応、型の強制、trafficmanager.netの非公開化をまとめて実現する新しい関連付け方式です。

まずは本番とは別のホスト名でLinked Recordを作成し、権威DNSへの問い合わせ、Traffic Managerの障害切り替え、TTL、DNSSEC検証を確認してください。その結果と組織のプレビュー利用基準を照らし合わせてから、本番CNAMEを置き換えるのが安全な進め方です。

Azure
DNSSEC Azure DNS CNAME Azure Traffic Manager

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次