Azure Networking built-in role

DNS Zone Contributor

Manages public Azure DNS zones and record sets without granting Azure RBAC access. The definition also grants authorization reads, classic alert-rule management, resource-health reads, deployment management, resource-group reads, and support-ticket management. It has no DataActions.

Control-plane actions (7)

• Microsoft.Authorization/*/read
• Microsoft.Insights/alertRules/*
• Microsoft.Network/dnsZones/*
• Microsoft.ResourceHealth/availabilityStatuses/read
• Microsoft.Resources/deployments/*
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Support/*

Data-plane actions (0)

None — this role grants no data-plane (data access) actions.

Excluded actions (0)

None

Assignable scopes (1)

• /

Practical scope

Azure DNS documents assignment at subscription, resource group, individual zone, or individual record-set scope, with inheritance from parent scopes. At resource-group or subscription scope, the deployment, classic alert, support, and health permissions apply to corresponding resources throughout that broad scope and are not restricted to DNS zones.

Common use cases (2)

• Give a DNS operations group control of all public Azure DNS zones in a dedicated resource group without granting virtual-machine administration.
• Delegate management of one public zone or a specific record set to the team responsible for that DNS namespace.

Prerequisites (2)

• Identify the public DNS zone or record sets the principal must manage and confirm that the selected scope contains no unrelated resources exposed by the ancillary Actions.
• The assigning administrator needs Microsoft.Authorization/roleAssignments/write at the target scope, and the DNS administrator must understand the production effect of record and zone changes.

Best practices (3)

• Prefer zone or record-set scope over subscription scope and use a dedicated DNS resource group when one team manages a defined set of zones.
• Use a custom role when the administrator should manage only a specific record type rather than every operation in DNS Zone Contributor.
• Protect critical zones and records with appropriate resource locks and test the lock behavior before relying on it as a deletion safeguard.

Security considerations (3)

• Deleting a DNS zone removes all record sets and can cause an unrecoverable service outage; modifying records can redirect or disable traffic.
• A CanNotDelete lock on a record set does not prevent records from being removed until the set is empty, which can have the same resolution effect as deletion.
• At broad scope, deployment, classic alert-rule, and support-ticket management extends the role beyond DNS configuration alone. The role has no DataActions, but public DNS control remains security-sensitive because it governs name resolution.

Assignment guidance

Assign DNS Zone Contributor at the smallest zone or record-set scope that meets the task, or at a dedicated DNS resource group when the same team manages every contained zone. Avoid subscription scope unless both the DNS and ancillary deployment, alert, support, and health permissions are explicitly approved.

Editorial sources (5)

• Azure built-in roles for Networking →

  Supports: Description, Practical scope, Prerequisites, Security considerations, Assignment guidance. Retrieved 2026-07-16.

• Steps to assign an Azure role →

  Supports: Prerequisites, Assignment guidance. Retrieved 2026-07-16.

• Understand scope for Azure RBAC →

  Supports: Practical scope, Best practices, Assignment guidance. Retrieved 2026-07-16.

• Best practices for Azure RBAC →

  Supports: Best practices. Retrieved 2026-07-16.

• Protecting Azure DNS zones and records →

  Supports: Practical scope, Common use cases, Prerequisites, Best practices, Security considerations, Assignment guidance. Retrieved 2026-07-16.

Official Microsoft Learn documentation →