MENU

Azure DNSでDNSゾーンを作成できない原因と対処法｜Deny assignmentエラーを徹底解説

Azure

Azure DNS で DNS ゾーン（ドメイン）を ARM/Bicep から作成しようとしたら、InvalidTemplateDeployment と一緒に Deny assignment check failed が出て失敗…「自分はグローバル管理者なのになぜ？」というケースは、実は Azure ガバナンス設計が原因であることがほとんどです。この記事では、Deny assignment によって Azure DNS ゾーン作成がブロックされる仕組みと、即時解決策・恒久対策・チェック手順までを実務レベルで整理します。

目次

Azure DNS で DNS ゾーンを作成できないときに出るエラーの正体

典型的なエラーメッセージ

ARM テンプレートや Bicep、あるいは Portal から Azure DNS ゾーンを作成したときに、次のようなエラーになるケースがあります。

{
  "error": {
    "code": "InvalidTemplateDeployment",
    "message": "The template deployment failed with error: 'Deny assignment check failed for template resource 'ten4service.com' of type 'Microsoft.Network/dnsZones'. The client '[email protected]' with object id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' has the permission to perform action 'Microsoft.Network/dnsZones/write' at scope '/subscriptions/.../resourceGroups/..._managed/providers/Microsoft.Network/dnsZones/ten4service.com' but is blocked by deny assignment.'."
  }
}

ポイントは以下の 3 行です。

  • `type ‘Microsoft.Network/dnsZones’` … 対象は DNSゾーン
  • `has the permission to perform action ‘Microsoft.Network/dnsZones/write’` … RBAC 上は権限あり
  • `but is blocked by deny assignment` … しかし Deny assignment によってブロック

つまり、

「書き込み権限はあるが、Deny assignment のせいで実行できない」

という状態です。同じ症状は Microsoft Q&A でも Azure DNS の質問として報告されており、再現性の高い事象です。

結論：Deny assignment 付きのリソース グループに DNS ゾーンを作ろうとしている

結論から言うと、このエラーの本質は次の 1 行に集約できます。

「Deny assignment が設定されているリソース グループ（またはサブスクリプション）に DNS ゾーンを作成しようとしたため」

Deny assignment は「このスコープでは ○○ の操作を誰にもさせない」という 最優先の禁止ルールで、通常の RBAC（Owner / Contributor / DNS Zone Contributor 等）よりも強く適用されます。

そのため、

  • ユーザーが Owner や Contributor を持っていても
  • Entra ID の グローバル管理者であっても

Deny assignment でブロックされている操作は実行できません。

即時解決策：ユーザー管理用の別リソース グループに DNS ゾーンを作成する

まずは「今すぐ DNS ゾーンを作りたい」という視点での実務的な解決策です。

シンプルな回避策

  • Deny assignment が付与されていない、ユーザー管理用のリソース グループ（RG）を新規作成
  • その RG を Bicep / ARM / Terraform / Portal のデプロイ先として指定

実際、質問に近いケースでも、別の RG を指定しただけで DNS ゾーン作成が成功しています。

Portal からの手順例

  1. Azure ポータルで「リソース グループ」→「作成」
  2. サブスクリプション：該当のサブスクリプション
  3. リソース グループ名：例）rg-dns-prod
  4. リージョン：任意（DNS ゾーン自体は location = global）
  5. 作成
  6. 「DNS ゾーン」→「作成」で、サブスクリプションと RG に rg-dns-prod を選択し、ゾーン名（例：ten4service.com）を入力して作成

これで問題なく作成できるようであれば、元の RG に Deny assignment が付いていたことがほぼ確定です。

Bicep / ARM で RG を切り替える例

Bicep（リソース グループスコープ）のサンプル：

targetScope = 'resourceGroup'

@description('DNS ゾーン名（例: ten4service.com）')
param dnsZoneName string

resource dnsZone 'Microsoft.Network/dnsZones@2023-07-01-preview' = {
  name: dnsZoneName
  location: 'global'
  properties: {
    zoneType: 'Public'
  }
}

この Bicep を 別のリソース グループに対してデプロイすれば OK です。DNS ゾーン リソース定義自体は公式ドキュメントと同じ構造です。

Deny assignment とは何者か：RBAC を上書きする「禁止ルール」

Deny assignment の概要

Deny assignment は、Azure RBAC と同じく「スコープ＋プリンシパル」に紐づく設定ですが、役割は真逆です。

項目ロール割り当て（Role assignment）Deny assignment（拒否の割り当て）
目的操作を 許可する操作を 禁止する
誰が作るか管理者（Owner など）が明示的に作成主に Azure のサービス（Blueprint, Managed Application など）が自動作成
優先順位通常の許可判定許可よりも優先して評価
管理画面IAM > ロールの割り当てIAM > 拒否の割り当て

Deny assignment は、特定スコープで「この操作は誰にもさせない」という禁止アクションを定義しており、Microsoft.Network/dnsZones/write が含まれていれば DNS ゾーンの作成はできません。

なぜ自分で Deny assignment を作れないのか

公式ドキュメントでも明記されていますが、Deny assignment は基本的に Azure が作るものであり、通常の管理者が直接作成することはできません（Deployment Stack などの機能経由を除く）。

代表的な付与元は次のとおりです。

  • Azure Blueprints（旧機能だが現場ではまだ利用例あり）
  • Managed Application（サードパーティ製ソリューションなど）
  • Service や SaaS が作成する「管理対象リソース グループ」
  • 新しめのガバナンス機能（Deployment Stack 等）の保護設定

「自分はグローバル管理者なのになぜ？」の理由

Entra ID のグローバル管理者と Azure RBAC は別物

よくある誤解が、

「グローバル管理者だから Azure の全リソースにフルアクセスできるはず」

という認識です。しかし実際には、次のように権限の次元が異なります。

役割どこを管理するロールかDNS ゾーン作成への影響
グローバル管理者
(Entra ID)		ディレクトリ（ユーザー / グループ / アプリ / 認証）Azure リソースの作成権限は 自動的には付かない
サブスクリプション Ownerそのサブスクリプション配下の Azure リソース通常は全操作が可能だが、Deny assignment には勝てない
DNS Zone ContributorDNS ゾーン・レコードの作成/更新/削除Deny がなければ DNS ゾーンを書き込める

つまり、たとえ Entra ID のグローバル管理者であっても、

  • 対象サブスクリプション / RG に RBAC が付与されていないと操作できない
  • RBAC が付与されていても、Deny assignment があればブロックされる

という二重の条件があります。

DNS ゾーン作成に必要なロール

DNS ゾーンそのものの作成には、おおむね次の権限が必要です。

  • DNS Zone Contributor（推奨）
  • または Contributor / Owner などの上位ロール

ただし、ここでもう一度強調しますが、

「許可よりも Deny が優先」

なので、Deny assignment が付いている限り、どんなロールを割り当てても解決しません。

管理対象リソース グループ（_managed / MC_ など）に要注意

今回のような DNS ゾーン作成エラーが起きやすいのが、「サービスが自動で作ったリソース グループ」に対して、誤って IaC のデプロイ先を向けてしまったパターンです。

ありがちな RG 名と意味

RG 名の例よくある用途ユーザーがしてはいけないこと
..._managedManaged Application / Blueprint / Deployment Stack などの管理対象リソース独自の VM / NIC / DNS ゾーンなどを追加作成
MC_{rgName}_{aksName}_{region}Azure Kubernetes Service (AKS) の管理用 RG手動で Public IP や LB、DNS を作成してクラスタ用リソースを汚染
databricks-rg-*Azure Databricks ワークスペース管理用 RG別システム用のストレージやネットワークを追加
その他ベンダー名や製品名を含む RGサードパーティ製 Managed Application などサービスが想定していないリソースの追加・変更

このような RG には、多くの場合 Deny assignment や Resource Lock が自動付与されています。
DNS ゾーンなどの ユーザー管理リソースは、専用の RG（例：rg-dns-prod）に分離するのがベストプラクティスです。

Azure ポータルで Deny assignment を確認する手順

リソース グループの Deny assignment を確認

  1. Azure ポータルで該当の「リソース グループ」を開く
  2. 左メニューから「アクセス制御 (IAM)」を選択
  3. 上部タブの「拒否の割り当て」をクリック
  4. 一覧に何か表示されていれば、その RG には Deny assignment が付与されている

ここで表示される Deny assignment には、多くの場合以下のような情報が含まれます。

  • 名前（DenyAssignmentName）
  • 作成元（例：Azure Blueprints, Managed Application など）
  • 適用されるアクション（actions / notActions）
  • スコープ（サブスクリプション / RG / 個別リソース）
  • SystemProtected = true（システム保護かどうか）

もしここに DNS 関連のアクション（例：Microsoft.Network/dnsZones/*）を含む Deny assignment があれば、それが DNS ゾーン作成失敗の直接原因になります。

サブスクリプション / 管理グループに付いている Deny assignment も確認

DNS 用 RG 自体に Deny が無くても、上位スコープ（サブスクリプション / 管理グループ）にある Deny が継承されている場合があります。

  1. 対象サブスクリプションを開く
  2. 「アクセス制御 (IAM)」→「拒否の割り当て」タブを確認
  3. 必要に応じて管理グループ側でも同様に確認

Deny assignment のスコープと継承の概念は、公式ドキュメントにまとまっています。

Azure Policy の「Deny」と Deny assignment の違い

実務で混同されやすいのが、「Azure Policy の Deny 効果」と「Deny assignment」です。

項目Azure Policy (effect: Deny)Deny assignment
主な目的タグや構成ルール違反の リソース作成を阻止特定操作自体を 原則禁止にする
定義主体管理者が Policy 定義 / 割り当てを作成Azure のサービス（Blueprint, Managed App など）が主に作成
エラーの出方「Policy により拒否されました（RequestDisallowedByPolicy など）」「Deny assignment check failed」
確認場所「Azure Policy」ブレード各スコープの IAM > 拒否の割り当て

今回のようにエラーメッセージに Deny assignment check failed と明示されている場合は、Azure Policy ではなく Deny assignment 側でブロックされています。

再発防止のための実務チェックリスト

1. RG が「ユーザー管理用」か「サービス管理用」かを見分ける

  • RG 名に _managed や MC_、製品名などが含まれていないか確認
  • 怪しい場合は、その RG の概要を確認し、Managed Application や AKS / Databricks などの管理用でないかを判断
  • 管理用であれば、ユーザー管理リソースを置かない方針にする

2. Deny assignment の有無をポータルで確認

  • DNS を置きたい RG・サブスクリプション・管理グループそれぞれで IAM > 拒否の割り当てを確認
  • DNS ゾーンやネットワーク系のアクションを含む Deny があれば、そのスコープで DNS を作るのは避ける

3. ガバナンス設計（Policy / Blueprint / Managed App）を棚卸し

  • Azure Policy の Deny が意図しない制限をかけていないか
  • Blueprint や Managed App で過度に広いスコープを保護していないか
  • DNS 用に あらかじめ標準 RG（例：rg-dns-prod, rg-dns-shared）を用意しておき、そこにだけ DNS を作る運用にする

4. 権限は「DNS Zone Contributor」を基本としつつ、Deny がないかを先に確認

  • DNS 管理者には RG スコープで DNS Zone Contributor を付与（VM など余計な権限を与えない）
  • それでも作成できない場合は、ロール追加ではなく Deny の有無を最優先で確認

5. IaC では「どの RG にデプロイしているか」を常に明示する

Bicep / ARM / Terraform などで DNS を作る場合、つい resourceGroup().name のように「今の RG」を使ってしまいがちです。

  • DNS 用 RG を変数やパラメータで明示する
  • CI/CD パイプライン側で「DNS 用 RG 名」を環境変数に固定する
  • 誤って _managed RG に向けていないかをコードレビューでチェック

実務でよくある「ハマりパターン」と回避例

パターン1：AKS クラスタ導入後、MC_ RG に DNS を作ろうとした

  • 症状：MC_rg-xxx_aks-yyy_region という RG に DNS ゾーンを作ろうとして Deny assignment エラー
  • 原因：AKS の管理用 RG であり、クラスタを守るために Deny assignment やロックが設定されている
  • 回避：アプリケーション用 / DNS 用の RG を別途作成し、そちらに DNS ゾーンをデプロイ

パターン2：Marketplace から導入したセキュリティ製品の Managed RG に作ろうとした

  • 症状：ベンダー名の付いた RG に対し、DNS ゾーンを含む IaC をまとめてデプロイしようとして失敗
  • 原因：Managed Application によって作成された RG で、ユーザーが勝手にリソースを追加できないよう Deny assignment が付いている
  • 回避：製品の資料を確認し、「ユーザーが利用する RG」と「製品が管理する RG」を分ける設計に修正

パターン3：Blueprint / Policy ベースのガバナンス導入後、突然作れなくなった

  • 症状：以前は DNS ゾーンを作れた RG で、ある日から Deny assignment エラーが出るようになった
  • 原因：ガバナンス強化に伴い Blueprint や Deployment Stack、Policy などが適用され、Deny assignment が追加された
  • 回避：ガバナンス担当チームと連携し、「DNS 用の例外 RG」や「スコープ除外」を検討

DNS 用リソース グループ設計のベストプラクティス

Azure DNS 自体も可用性が重要な「インフラの中のインフラ」です。運用上おすすめの RG 設計パターンをいくつか挙げます。

用途別に RG を分ける

  • 共有 DNS ゾーン：rg-dns-shared
  • 本番系アプリ DNS：rg-dns-prod
  • 検証・開発用 DNS：rg-dns-dev

各 RG に対して、

  • DNS 管理者には DNS Zone Contributor
  • 監査担当には Reader

といったロールを割り当てると、責務が明確になりトラブルシューティングもしやすくなります。

Deny assignment やロックは「DNS 用 RG には付けない」が基本

もちろん、DNS ゾーンを誤削除から守るために リソース ロック（Delete ロック）や厳しめの RBAC を設定するのは良いプラクティスです。
しかし、Deny assignment のように 「誰も更新できなくなる」レベルの制約を DNS 用 RG に付与すると、いざというときの障害対応も不可能になります。

  • 管理対象 RG：Deny assignment あり（サービスが管理）
  • ユーザー管理 RG：Deny assignment なし（代わりにロール＋ロックで保護）

という線引きをしておくと、今回のようなエラーに悩まされにくくなります。

トラブルシューティングの流れ（まとめ）

最後に、現場でそのまま使える「DNS ゾーン作成エラー対応フロー」をまとめておきます。

  1. エラーメッセージを確認
    • Deny assignment check failed があるか？
    • 対象リソースが Microsoft.Network/dnsZones か？
  2. RG 名を確認
    • _managed / MC_ / ベンダー名などが含まれていないか？
  3. 対象 RG の IAM > 拒否の割り当てを確認
    • Deny assignment が 1 件でもあれば、そこでの新規作成は原則 NG
  4. サブスクリプション / 管理グループ側の Deny も確認
  5. ユーザー管理用の新規 RG を作成し、そこに DNS ゾーンを作成
  6. ガバナンス担当と調整
    • 必要なら DNS 用 RG を Policy / Blueprint のスコープから除外
    • Managed Application 側の設計も見直し

おわりに：エラーの本質は「誰が悪い」ではなく「どこに作ろうとしたか」

今回の Deny assignment エラーは、

「権限が足りない」のではなく、「作ろうとしている場所がそもそもユーザーが触る前提ではなかった」

という設計上の問題であることがほとんどです。

  • グローバル管理者だからといって、Deny assignment を無視できるわけではない
  • Deny assignment はガバナンス上重要な仕組みなので、むりやり解除するのではなく「適切な RG にリソースを分離する」発想が大事
  • DNS 用の専用 RG を用意し、そこには Deny ではなく RBAC とロックで安全にガードする

この 3 点を押さえておけば、「Azure DNS で新しいドメイン（DNS ゾーン）を作れない」というトラブルは、原因特定も再発防止もかなりスムーズになります。

Azure
権限管理 Azure Azure Policy Azure DNS Deny assignment

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次