Dns Protect Private Zones Recordsets

Bias Analysis

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation consistently presents Azure PowerShell examples before Azure CLI examples, and in some cases (such as record set level resource locks), only PowerShell commands are provided, with explicit notes that the functionality is not available in the Azure CLI or portal. There are no references to Linux-specific tools, shell environments, or considerations, and the use of PowerShell as the primary scripting example may implicitly favor Windows users. No Linux shell or cross-platform scripting guidance is provided.

Recommendations:

Wherever possible, provide Azure CLI examples first or alongside PowerShell, as Azure CLI is cross-platform and more familiar to Linux users.
Explicitly mention that Azure CLI and Azure PowerShell are both cross-platform, and clarify any platform-specific limitations.
For scenarios where only PowerShell is supported, offer guidance for Linux users on how to install and use Azure PowerShell on Linux, or provide alternative approaches if available.
Include examples using Bash or other common Linux shells when demonstrating CLI usage, especially for scripting or automation.
Add a section or note addressing Linux/macOS users, highlighting any differences or additional steps required.
Where features are not available in the CLI or portal, consider linking to feedback channels or roadmaps for feature parity.

Create pull request

Date	Scan ID	Status	Bias Status
2025-08-17 00:01	#83	in_progress	✅ Clean
2025-07-13 21:37	#48	completed	✅ Clean
2025-07-09 13:09	#3	cancelled	✅ Clean
2025-07-08 04:23	#2	cancelled	❌ Biased

Flagged Code Snippets

### Protecting individual records To prevent an existing DNS record set against modification, apply a ReadOnly lock to the record set. > [!NOTE] > Applying a CanNotDelete lock to a record set is not an effective control. It prevents the record set from being deleted, but it does not prevent it from being modified. Permitted modifications include adding and removing records from the record set, including removing all records to leave an empty record set. This has the same effect as deleting the record set from a DNS resolution viewpoint. Record set level resource locks can currently only be configured using Azure PowerShell. They aren't supported in the Azure portal or Azure CLI. Azure PowerShell

### Private Zone level Azure RBAC Azure RBAC rules can be applied to a subscription, a resource group or to an individual resource. That resource can be an individual DNS zone, or an individual record set. For example, the resource group *myPrivateDNS* contains the zone *private.contoso.com* and a subzone *customers.private.contoso.com*. CNAME records are created for each customer account. The administrator account used to manage CNAME records is assigned permissions to create records in the *customers.private.contoso.com* zone. The account can manage *customers.private.contoso.com* only. Zone-level Azure RBAC permissions can be granted via the Azure portal. Open **Access control (IAM)** for the zone, select **Add**, then select the **Private DNS Zone Contributor** role. Select the required users or groups to grant permissions. :::image type="content" source="./media/dns-protect-private-zones-recordsets/zone-rbac.png" alt-text="Screenshot of RBAC for private DNS zone."::: Permissions can also be [granted using Azure PowerShell](../role-based-access-control/role-assignments-powershell.md):

### Record set level Azure RBAC Permissions are applied at the record set level. The user is granted control to entries they need and are unable to make any other changes. Record-set level Azure RBAC permissions can be configured via the Azure portal, using the **Access Control (IAM)** button in the record set page: :::image type="content" source="./media/dns-protect-private-zones-recordsets/record-set-rbac-1.png" alt-text="Screenshot of RBAC for private DNS record set."::: :::image type="content" source="./media/dns-protect-private-zones-recordsets/record-set-rbac-2.png" alt-text="Screenshot of role assignment for private DNS record set."::: Record-set level Azure RBAC permissions can also be [granted using Azure PowerShell](../role-based-access-control/role-assignments-powershell.md):

The Actions property defines the following DNS-specific permissions: * `Microsoft.Network/privateDnsZones/CNAME/*` grants full control over CNAME records * `Microsoft.Network/privateDNSZones/read` grants permission to read DNS private zones, but not to modify them, enabling you to see the zone in which the CNAME is being created. > [!NOTE] > Using an Azure custom role to prevent deleting record sets while still allowing them to be updated is not an effective control. It prevents record sets from being deleted, but it does not prevent them from being modified. Permitted modifications include adding and removing records from the record set, including removing all records to leave an empty record set. This has the same effect as deleting the record set from a DNS resolution viewpoint. Custom role definitions can't currently be defined via the Azure portal. A custom role based on this role definition can be created using Azure PowerShell:

The role can then be assigned in the same way as built-in roles, as described earlier in this article. For more information on how to create, manage, and assign custom roles, see [Azure custom roles](../role-based-access-control/custom-roles.md). ## Resource locks Azure Resource Manager supports another type of security control, the ability to lock resources. Resource locks are applied to the resource, and are effective across all users and roles. For more information, see [Lock resources with Azure Resource Manager](../azure-resource-manager/management/lock-resources.md). There are two types of resource lock: **CanNotDelete** and **ReadOnly**. These lock types can be applied either to a Private DNS zone, or to an individual record set. The following sections describe several common scenarios, and how to support them using resource locks. ### Protecting against all changes To prevent changes being made, apply a ReadOnly lock to the zone. This lock prevents new record sets from being created, and existing record sets from being modified or deleted. Zone level resource locks can be created via the Azure portal. From the DNS zone page, select **Locks**, then select **+Add**: :::image type="content" source="./media/dns-protect-private-zones-recordsets/zone-locks.png" alt-text="Screenshot of locks for private DNS zone."::: Zone-level resource locks can also be created via [Azure PowerShell](/powershell/module/az.resources/new-azresourcelock):

### Protecting against zone deletion When a zone is deleted in Azure DNS, all record sets in the zone are deleted. This operation can't be undone. Accidentally deleting a critical zone has the potential to have a significant business impact. It's important to protect against accidental zone deletion. Applying a CanNotDelete lock to a zone prevents the zone from being deleted. Locks are inherited by child resources. A lock prevents any record sets in the zone from being deleted. As described in the note above, it's ineffective since records can still be removed from the existing record sets. As an alternative, apply a CanNotDelete lock to a record set in the zone, such as the SOA record set. The zone isn't deleted without also deleting the record sets. This lock protects against zone deletion, while still allowing record sets within the zone to be modified freely. If an attempt is made to delete the zone, Azure Resource Manager detects this removal. The removal would also delete the SOA record set, Azure Resource Manager blocks the call because the SOA is locked. No record sets are deleted. The following PowerShell command creates a CanNotDelete lock against the SOA record of the given zone:

Document Details

About This Page

Bias Analysis

Scan History

Flagged Code Snippets