在Azure中，使用Azure Policy可以自动在中心私有DNS区域中创建私有端点时DNS记录。这是因为 spoke 或 landing zone的所有者通常没有权限在Hub的中央私有DNS区域中创建A记录。对于大多数私有DNS区域，可以使用常规的Azure policy，该政策检查私有DNS区域名称和子资源ID。然而，在某些情况下，这并不足以解决问题，例如需要使用恢复服务保管库指定区域。另一个例子是当存在重叠的子资源值时，例如Synapse Analytics和Cosmos DB（都使用'sql'）或Synapse Studio和存储帐户Web（都使用'web'）。如果使用相同的子资源创建多个策略，则不知道A记录将在哪个私有DNS区域中创建。为了解决这个问题，Microsoft创建了一个策略，除了子资源外，还添加了一个参数，该参数匹配私有链接资源类型（也称为privateLinkServiceId）。

🔹 Azure Policy允许在创建私有端点时自动在中心私有DNS区域中创建DNS记录。这是为了解决spoke或landing zone的所有者通常没有权限在Hub的中央私有DNS区域中创建A记录的问题。

🔹 对于大多数私有DNS区域，可以使用常规的Azure policy，该政策检查私有DNS区域名称和子资源ID。这种方法适用于大多数情况，但并不总是足够。

🔹 在某些情况下，例如需要使用恢复服务保管库指定区域，或者当存在重叠的子资源值（如Synapse Analytics和Cosmos DB或Synapse Studio和存储帐户Web）时，需要更复杂的策略。

🔹 为了解决重叠子资源值的问题，Microsoft创建了一个策略，该策略除了子资源外，还添加了一个参数，该参数匹配私有链接资源类型（也称为privateLinkServiceId）。这种方法可以确保A记录在正确的私有DNS区域中创建。

🔹 通过使用Azure Policy，可以简化私有端点的管理，并确保DNS记录的正确创建，从而提高系统的可靠性和可维护性。

 When using private endpoints at scale, the recommended setup from Microsoft is to use Azure Policy to automatically create the DNS records in the central private DNS zones when the private endpoints are created. The reason for this is that users or owners of the spokes or landing zones do not have permissions to create A records in the central private DNS zones in the Hub.

For most private DNS zones, the regular Azure policy can be used which checks for private DNS zone name and subResource id, see list here. However, there are scenarios where this is not sufficient. For example, if a region has to be specified using Recovery Services Vault, see more on that here.

Another example, and the scope of this post, is when there are overlapping subResource values such as for Synapse Analytics and Cosmos DB (which both use 'sql') or Synapse Studio and Storage accounts Web (which both use 'web'). If multiple policies are created using the same subResource, you don't know in which private DNS zone that the A record will be created and you can experience records being created first in one zone and then the other whichever policy is evaluated first.

To address this, Microsoft has created a policy that, in addition to the subResource, adds a parameter that matches on the private link resource type (also referred to as privateLinkServiceId). The policy can be found here.

The private link resource type is found in the first column in the table of private DNS zones, here. Examples of values are:

Microsoft.Synapse/privateLinkHubsMicrosoft.Synapse/workspacesMicrosoft.DocumentDB/databaseAccounts

For some odd reason, MSFT hardcodes the value of the private link reosurce type in the policy. I've updated the policy slightly to parameterize that value. The updated policy can be found on here on Github.

Below you can see an example of what it looks like when the policy is assigned in the portal: