Implement support for regional DNS zones

[erjosito]

Some Azure services such as Azure Batch or Azure Container Registry require their private endpoints to be linked to region-specific DNS zones. For example, for Azure Batch to {regionName}.privatelink.batch.azure.com, or for Azure Container Registry to privatelink.azurecr.io and {regionName}.privatelink.azurecr.io.

The Terraform module could be extended to support regions in the input parameter. The existing format of a simple dictionary could be transformed to an array of dictionaries with keys endpoint_type, dns_zone_name and optionally region. If a region were present, the module should create a zone specific to that region, and add an additional criteria in the Azure Policy definition so that only resources in that specific region are matched.

[mdepedrof]

Hola! Based on your idea, I incorporated the creation of the policies to the system of creation of zones and records that I already had implemented. My system was based on a yaml file where I managed all the zones and records (of all types). Mainly it was created for an operations team to manage it but then I added some mechanisms to automatically update the yaml file in the repository if a change of records was generated in the zones outside this system. This way this yaml file (in the repo with all commits) is the only point of truth. The file looked like this:

dns_attributes: ["a", "aaaa", "cname", "mx", "ptr", "srv", "txt", "links"]
links:
  link-hub-region1-pro:
    &hub_region1_pro {
      vnet_name: vnet-hub-region1-pro,
      vnet_rg: rg-hub-region1-pro-network
    }
  link-hub-region1-nopro:
    &hub_region1_nopro {
      vnet_name: vnet-hub-region1-nopro,
      vnet_rg: rg-hub-region1-nopro-network
    }
private_dns_zones:
  privatelink.blob.core.windows.net:
    a: { }
    aaaa: { }
    cname: { }
    mx: { }
    ptr: { }
    srv: { }
    txt: { }
    links:
      link-hub-region1-nopro: *hub_region1_nopro

When I saw your article I thought it would be better to have this system as there are less pieces that can fail (Azure monitor, logicapp, workflow, etc...) So trying to add your proposal, I have simplified the yaml file leaving this:

dns_attributes: ["links"]
links:
  link-hub-region1-pro:
    &hub_region1_pro {
      vnet_name: vnet-hub-region1-pro,
      vnet_rg: rg-hub-region1-pro-network
    }
  link-hub-region1-nopro:
    &hub_region1_nopro {
      vnet_name: vnet-hub-region1-nopro,
      vnet_rg: rg-hub-region1-nopro-network
    }
private_dns_zones:
  privatelink.blob.core.windows.net:
    links:
      link-hub-region1-nopro: *hub_region1_nopro

This has worked perfectly for me and I think it may simplify the problem with zones that have identifiers or are regional. In the end, the zones are created in the file.

However, I had to make a modification in the name of the parameter so that it was not strange to me since I directly make a foreach of private_dns_zones:

_ENDPOINT_TYPE__zone_id

This way, when displaying the parameter I get privatelink.blob.core.windows.net_zone_id

Espero que te sea de ayuda. Al menos a mi me has ayudado un montón.

[erjosito]

Genial, gracias por compartirlo @mdepedrof !!!