Ga naar inhoud

Remove Redis Enterprise private DNS policy; treat all redisEnterprise endpoints as Managed Redis

Context and Problem Statement

Azure Managed Redis and Azure Cache for Redis Enterprise share identical resource type (Microsoft.Cache/redisEnterprise) and groupId (redisEnterprise) on their private endpoints. The only way to distinguish them at policy evaluation time is the FQDN in customDnsConfigs — *.redisenterprise.cache.azure.net for Enterprise, *.redis.azure.net for Managed Redis.

This FQDN is populated by Azure with a delay after private endpoint creation. The DINE policy evaluates before the FQDN is available, so neither policy fires on the first evaluation. Clients must work around this by re-creating or updating the resource to trigger re-evaluation. No automated remediation task is configured for clients.

A hub DNS zone scan confirmed zero A-record registrations in privatelink.redisenterprise.cache.azure.net across all environments.

Decision Drivers

  • Redis Enterprise is being retired by Microsoft; creation of new Redis Enterprise resources is blocked.
  • Zero client usage confirmed by DNS zone scan (zones exist, zero A records).
  • FQDN-based discrimination is fragile and causes unreliable automation.
  • Clients should not need workarounds for basic private DNS registration.

Considered Options

  1. Remove the Redis Enterprise policy; drop FQDN check from Managed Redis policy — chosen
  2. Tune evaluationDelay in both policies to wait longer for the FQDN
  3. Add an automated remediation task triggered after PE creation

Decision Outcome

Chosen option: Option 1.

Since Redis Enterprise creation is blocked by Microsoft, every future private endpoint with resourceType=Microsoft.Cache/redisEnterprise and groupId=redisEnterprise will be Managed Redis. The FQDN discriminator is no longer needed. Removing it fixes the timing issue permanently.

What changes: - policy_private_dns_redis_enterprise module is removed entirely. - The FQDN customDnsConfigs[*] condition is removed from policy_private_dns_redis_managed. The policy now matches on resource type and groupId only and fires immediately at PE creation. - privatelink.redisenterprise.cache.azure.net DNS zone is retained in the connectivity layer as the manual registration target.

Consequences

  • Good: Managed Redis private endpoints register automatically without any client workaround.
  • Good: Eliminates a fragile FQDN-timing dependency from the policy set.
  • Good: Reduces policy set size by one definition.
  • Bad: Any client that deploys Redis Enterprise (currently impossible; blocked by Microsoft) must manually create the DNS zone group linking to privatelink.redisenterprise.cache.azure.net in the hub connectivity subscription.

Validation

Config tests (XebiaPrivateDnsZones.Mcp.Config.Tests.ps1) pass with privatelink.redisenterprise.cache.azure.net listed as an expected connectivity-only zone. DNS zone scan confirms zero Enterprise registrations.