Hub-and-Spoke Landing Zone with Authoritative Private DNS

Overview

Workloads run in spokes peered to a central hub. The hub inspects egress through Azure Firewall and resolves names through a corporate DNS forwarder. My work focused on the part that breaks most often: making private endpoints resolve correctly from every place a workload might run, and keeping firewall rules tight, as code.

Design

Implementation

1. Register every private endpoint in the authoritative zone

Records in per-subscription copies of a zone don't help, because the forwarder isn't linked to them. Terraform writes the record into the authoritative zone through an aliased provider.

provider "azurerm" {
  alias           = "shared_dns"
  subscription_id = var.shared_dns_subscription_id
  features {}
}

resource "azurerm_private_dns_a_record" "kv" {
  provider            = azurerm.shared_dns
  name                = azurerm_key_vault.this.name
  zone_name           = "privatelink.vaultcore.azure.net"
  resource_group_name = var.shared_dns_rg
  ttl                 = 300
  records             = [azurerm_private_endpoint.kv.private_service_connection[0].private_ip_address]
}

2. Keep AKS VNets lean

They link only to the zones AKS itself needs, and rely on the forwarder for everything else.

3. Least-privilege egress

When Entra authentication for SQL failed from a locked-down subnet, firewall logs showed a default deny to graph.microsoft.com. That meant retrying in the portal could never succeed. The fix is one scoped FQDN rule for that subnet's IP group, not a broad allow.

4. Module hygiene

Two shared modules created both a standalone A record and a DNS zone group for the same endpoint, which caused "already exists" errors after partial applies. I cleaned up the orphans and proposed a variable to switch off the duplicate.

Troubleshooting Notes

• no such host from a pod but not from a laptop means the record is in a zone the forwarder can't see.
• Querying Azure DNS directly from an unlinked VNet returns the public IP. Fix it at the resolver, not by scattering VNet links.
• Duplicate privatelink zones are a silent risk. Audit them with Resource Graph.

Key Outcomes

• One documented DNS pattern that unblocked secret mounts and database connections on AKS.
• Duplicate-zone sprawl identified and quantified.
• Firewall changes expressed as scoped rules in a policy repository.

Conclusion

Private networking succeeds or fails on DNS. Settling on one authoritative zone, and enforcing it in code, turned a recurring source of outages into a pattern anyone can follow.

Technologies Used