Azure Private DNS Resolver deployment fails with InternalServerError / circuit breaker on redeploy.

Hi Damián Dedó,

Since the delete operation is also failing with the same backend error, this indicates the DNS Private Resolver resource is likely stuck in a failed provisioning state within the Network Resource Provider.

This is typically associated with repeated backend processing failures rather than a customer-side configuration issue.

Please Verify the inbound endpoint subnet: is delegated to:

Microsoft.Network/dnsResolvers

Contains no other resources

1. Retry the delete operation after some time In some cases, transient backend states may clear automatically.
2. Since the delete operation is also failing with the same backend error, this indicates the DNS Private Resolver resource is likely stuck in a failed provisioning state within the Network Resource Provider. The key indicators are: InternalServerError and circuitBreaker=``[state=Open] I tried to create the DNS Resolver with an inbound endpoint using the below Bicep code with API version Microsoft.Network/dnsResolvers@2022-07-01, and the deployment completed successfully.

      @description('name of the new virtual network where DNS resolver will be created')
      param resolverVNETName string = 'dnsresolverVNET'
      @description('the IP address space for the resolver virtual network')
      param resolverVNETAddressSpace string = '10.7.0.0/24'
      @description('name of the dns private resolver')
      param dnsResolverName string = 'dnsResolver'
      @description('the location for resolver VNET and dns private resolver - Azure DNS Private Resolver available in specific region, refer the documenation to select the supported region for this deployment. For more information https://docs.microsoft.com/azure/dns/dns-private-resolver-overview#regional-availability')
      @allowed([
        'australiaeast'
        'uksouth'
        'northeurope'
        'southcentralus'
        'westus3'
        'eastus'
        'northcentralus'
        'westcentralus'
        'eastus2'
        'westeurope'
        'centralus'
        'canadacentral'
        'brazilsouth'
        'francecentral'
        'swedencentral'
        'switzerlandnorth'
        'eastasia'
        'southeastasia'
        'japaneast'
        'koreacentral'
        'southafricanorth'
        'centralindia'
        'westus'
        'canadaeast'
        'qatarcentral'
        'uaenorth'
        'australiasoutheast'
        'polandcentral'
      ])
      param location string
      @description('name of the subnet that will be used for private resolver inbound endpoint')
      param inboundSubnet string = 'snet-inbound'
      @description('the inbound endpoint subnet address space')
      param inboundAddressPrefix string = '10.7.0.0/28'
      @description('name of the subnet that will be used for private resolver outbound endpoint')
      param outboundSubnet string = 'snet-outbound'
      @description('the outbound endpoint subnet address space')
      param outboundAddressPrefix string = '10.7.0.16/28'
      @description('name of the vnet link that links outbound endpoint with forwarding rule set')
      param resolvervnetlink string = 'vnetlink'
      @description('name of the forwarding ruleset')
      param forwardingRulesetName string = 'forwardingRule'
      @description('name of the forwarding rule name')
      param forwardingRuleName string = 'contosocom'
      @description('the target domain name for the forwarding ruleset')
      param DomainName string = 'contoso.com.'
      @description('the list of target DNS servers ip address and the port number for conditional forwarding')
      param targetDNS array = [
        {
          ipAddress: '10.0.0.4'
          port: 53
        }
        {
          ipAddress: '10.0.0.5'
          port: 53
        }
      ]
      resource resolver 'Microsoft.Network/dnsResolvers@2022-07-01' = {
        name: dnsResolverName
        location: location
        properties: {
          virtualNetwork: {
            id: resolverVnet.id
          }
        }
      }
      resource inEndpoint 'Microsoft.Network/dnsResolvers/inboundEndpoints@2022-07-01' = {
        parent: resolver
        name: inboundSubnet
        location: location
        properties: {
          ipConfigurations: [
            {
              privateIpAllocationMethod: 'Dynamic'
              subnet: {
                id: '${resolverVnet.id}/subnets/${inboundSubnet}'
              }
            }
          ]
        }
      }
      
      resource resolverVnet 'Microsoft.Network/virtualNetworks@2022-01-01' = {
        name: resolverVNETName
        location: location
        properties: {
          addressSpace: {
            addressPrefixes: [
              resolverVNETAddressSpace
            ]
          }
          enableDdosProtection: false
          enableVmProtection: false
          subnets: [
            {
              name: inboundSubnet
              properties: {
                addressPrefix: inboundAddressPrefix
                delegations: [
                  {
                    name: 'Microsoft.Network.dnsResolvers'
                    properties: {
                      serviceName: 'Microsoft.Network/dnsResolvers'
                    }
                  }
                ]
              }
            }
            {
              name: outboundSubnet
              properties: {
                addressPrefix: outboundAddressPrefix
                delegations: [
                  {
                    name: 'Microsoft.Network.dnsResolvers'
                    properties: {
                      serviceName: 'Microsoft.Network/dnsResolvers'
                    }
                  }
                ]
              }
            }
          ]
        }
      }
   

Output

If the above steps did not help resolve your issue, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.

Pleaseand “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.

Damián Dedó hi & thanks for join me here at Q&A portal,

so i guess its provider-side control-plane bug & not bad Bicep. circuitBreaker=[state=Open, processedCount=6, maxProcessedCount=5] means the Microsoft.Network RP retried the same dnsResolvers/write operation too many times and then stopped processing it. The weird part is exactly what u noticed live resolver + inbound endpoint show Succeeded, but redeploy fails, so the resource is healthy while the idempotent PUT/write path is broken. There are older reports of the same Private DNS Resolver circuit breaker error so this is not a totally new failure pattern. (learn.microsoft.com) One thing I would change immediately dont use 2025-10-01-preview unless u specifically need it. Try a stable API version for Microsoft.Network/dnsResolvers/inboundEndpoints, because preview Network RP APIs can expose backend issues on redeploy. Current template docs list Private DNS Resolver inbound endpoint resource versions separately, so pin to a non-preview/stable version supported by ur Bicep template and redeploy. (learn.microsoft.com) If stable API still fails, split deployment into two stages: resolver first, wait until fully succeeded, then inbound endpoint, and avoid re-PUTing unchanged resolver properties on every deployment if possible. Also confirm subnet delegation and static IP are unchanged, because endpoint IP/subnet changes can force update paths the RP doesnt handle cleanly. If the live resources are already succeeded and only redeploy fails, open Azure Support with the exact circuitBreaker message, resolver resource ID, endpoint name, API version, deployment correlation ID, and ask for Microsoft.Network provider cleanup/reset for dnsResolvers/write. To summ alll what i type resource is fine, idempotent redeploy path is busted; try stable API + split deployment, otherwise support needs to clear RP state

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal