Document Details

### 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.

### 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 *myResourceGroup* contains the zone *contoso.com* and a subzone *customers.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.contoso.com* zone. The account can manage *customers.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 **DNS Zone Contributor** role and select the required users or groups to grant permissions. :::image type="content" source="./media/dns-protect-zones-recordsets/zone-rbac.png" alt-text="Screenshot of access control page for 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 **Users** button in the record set page: :::image type="content" source="./media/dns-protect-zones-recordsets/record-set-rbac-1.png" alt-text="Screenshot of user button in 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/dnsZones/CNAME/*` grants full control over CNAME records * `Microsoft.Network/dnsZones/read` grants permission to read DNS zones, but not to modify them, enabling you to see the zone in which the CNAME is being created. The remaining Actions are copied from the [DNS Zone Contributor built-in role](../role-based-access-control/built-in-roles.md#dns-zone-contributor). > [!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-zones-recordsets/zone-locks.png" alt-text="Screenshot of zone level resource locks."::: 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: