Manuel Barbetta

Cloud, Guide
27 Agosto 2026

DNS in una Landing Zone Azure con Terraform: Private DNS Resolver e Private DNS zones per la risoluzione ibrida

La risoluzione dei nomi è un servizio centrale dell’hub in una topologia hub & spoke. Due componenti lavorano insieme: le Private DNS zones rispondono per i nomi dei servizi Azure raggiunti tramite Private Endpoint, mentre il DNS Private Resolver instrada le query tra Azure e on-premises. Centralizzarli nell’hub garantisce una risoluzione coerente per tutti gli spoke e per le reti aziendali.

Questa guida descrive il deployment con Terraform del DNS Private Resolver e delle Private DNS zones tramite gli Azure Verified Modules (AVM), nel resource group rg-hub-itn (subscription Connectivity, region Italy North). Presuppone la Hub Virtual Network già deployata con le subnet snet-dns-inbound e snet-dns-outbound.

Cos’e’ il DNS e perche’ implementarlo nell’hub

Il DNS (Domain Name System) è il servizio che traduce i nomi leggibili dalle persone (come www.azienda.it) negli indirizzi IP numerici che le macchine usano per comunicare. È l’equivalente di una rubrica telefonica: si cerca un nome e si ottiene il numero da chiamare. Senza DNS, ogni comunicazione richiederebbe di conoscere a memoria indirizzi numerici.

In Azure il DNS assume un ruolo particolare quando si usano i Private Endpoint, cioe’ i punti di accesso privati ai servizi PaaS (storage, database, key vault). Un private endpoint dà a un servizio pubblico un indirizzo IP interno alla rete: perche’ le applicazioni lo usino davvero, il nome del servizio deve risolvere verso quell’IP privato e non verso quello pubblico. Questo e’ il compito delle Private DNS zones. Il DNS Private Resolver completa il quadro facendo da tramite tra il DNS di Azure e quello aziendale on-premises, nei due sensi.

I motivi principali per centralizzare il DNS nell’hub sono:

Risoluzione corretta dei servizi privati – le applicazioni raggiungono storage, database e altri servizi tramite i loro indirizzi privati e sicuri, non tramite Internet.
Coerenza per tutti gli spoke – le zone DNS vivono nell’hub e, grazie al peering, tutte le reti condividono la stessa risoluzione senza configurazioni duplicate.
Integrazione ibrida – il resolver permette alle risorse Azure di risolvere i nomi dei server on-premises e viceversa, indispensabile in scenari misti cloud e datacenter.
Servizio gestito – il DNS Private Resolver sostituisce le vecchie macchine virtuali usate come DNS forwarder, eliminando VM da mantenere e garantendo alta disponibilita’.

Architettura DNS dell’hub

Il flusso completo di risoluzione di un nome Private Link e’ il seguente:

Una VM cerca ad esempio miostorage.blob.core.windows.net.
La query arriva al DNS Resolver inbound (definito in dns.tf).
Il resolver cerca nella zona privatelink.blob.core.windows.net (definita in dns-zones.tf).
Trova il record A del private endpoint e restituisce l’IP privato.

Prerequisito: le subnet delegate

Il DNS Private Resolver richiede due subnet dedicate e delegate al servizio Microsoft.Network/dnsResolvers, una per l’inbound e una per l’outbound. Nel piano di indirizzamento dell’hub sono snet-dns-inbound (10.0.1.0/28) e snet-dns-outbound (10.0.1.16/28), definite in network.tf. Le subnet delegate non possono contenere altre risorse.

Passo 1: Il DNS Private Resolver

Il resolver e’ creato con il modulo AVM avm-res-network-dnsresolver e ha due endpoint. L’endpoint inbound riceve le query provenienti dalla rete on-premises e le risolve usando le Private DNS zones di Azure. L’endpoint outbound inoltra le query da Azure verso i DNS server on-premises secondo le regole del forwarding ruleset frs-hub-itn. Il file completo dns.tf:

# Il Private DNS Resolver ha due endpoint:

# - Inbound: permette alle reti on-premises di risolvere i nomi DNS privati di Azure

# (es. record nelle Private DNS Zone come *.privatelink.blob.core.windows.net)

# - Outbound: permette alle risorse Azure di risolvere nomi DNS on-premises

# tramite regole di forwarding verso i DNS server aziendali

module "dns_resolver" {

source = "Azure/avm-res-network-dnsresolver/azurerm"

version = "~> 0.8"

name = var.dns_resolver_name

location = var.location

resource_group_name = module.resource_group.name

tags = local.global_tags

virtual_network_resource_id = module.vnet.resource_id

enable_telemetry = false

# L'endpoint inbound riceve le query DNS provenienti dalla rete on-premises

# e le risolve usando i DNS privati di Azure (Private DNS Zones).

inbound_endpoints = {

inbound = {

name = "dns-inbound"

subnet_name = module.vnet.subnets["snet-dns-inbound"].name

}

# L'endpoint outbound inoltra le query DNS da Azure verso i DNS server

# on-premises secondo le regole di forwarding configurate nel ruleset.

# Il ruleset e' vuoto per ora: aggiungere le regole per i domini aziendali.

outbound_endpoints = {

outbound = {

name = "dns-outbound"

subnet_name = module.vnet.subnets["snet-dns-outbound"].name

forwarding_ruleset = {

default = {

name = "frs-hub-itn"

# Aggiungere qui le regole per i domini on-premises, ad esempio:

# rules = {

# azienda = {

# domain_name = "corp.azienda.local."

# destination_ip_addresses = { "dns1" = { ip_address = "192.168.1.10", port = 53 } }

# }

rules = {}

}

NOTA: Il forwarding ruleset frs-hub-itn nasce con rules = {} (vuoto). Per abilitare la risoluzione dei domini on-premises aggiungere le regole con domain_name e destination_ip_addresses verso i DNS server aziendali, come mostrato nel commento del codice.

Passo 2: Le Private DNS zones

Le Private DNS zones completano il resolver: il resolver sa dove girare le query, le zone sanno come rispondere. Sono create tramite il modulo pattern AVM avm-ptn-network-private-link-private-dns-zones, che genera automaticamente le oltre 100 zone privatelink.* per tutti i servizi Azure PaaS (storage, key vault, sql, acr, ecc.) e le collega alla VNet hub in un’unica operazione. Il file completo dns-zones.tf:

# Le Private DNS Zone completano il DNS Resolver: il resolver sa dove girare

# le query, le zone sanno come rispondere. Il flusso completo:

# 1. Una VM cerca "miostorage.blob.core.windows.net"

# 2. La query arriva al DNS Resolver inbound (dns.tf)

# 3. Il resolver cerca nella zona "privatelink.blob.core.windows.net" (qui)

# 4. Trova il record A del private endpoint e restituisce l'IP privato

# Finche' non esistono private endpoint le zone sono vuote e innocue:

# la risoluzione ricade sul DNS pubblico di Azure. Appena si crea un private

# endpoint in una spoke, Azure registra automaticamente il record A qui.

# Il modulo pattern AVM crea automaticamente le zone per tutti i servizi

# Azure PaaS (100+ zone: storage, key vault, sql, acr, ecc.) e le collega

# alla hub VNet in un'unica operazione. Le spoke in peering con l'hub

# ereditano la risoluzione senza bisogno di VNet link aggiuntivi.

module "dns_zones" {

source = "Azure/avm-ptn-network-private-link-private-dns-zones/azurerm"

version = "~> 0.23"

location = var.location

parent_id = module.resource_group.resource_id

tags = local.global_tags

enable_telemetry = false

virtual_network_link_default_virtual_networks = {

hub = {

virtual_network_resource_id = module.vnet.resource_id

}

NOTA: Finche’ non esistono Private Endpoint le zone restano vuote e innocue: la risoluzione ricade sul DNS pubblico di Azure. Appena si crea un private endpoint in uno spoke, Azure registra automaticamente il record A nella zona corrispondente. Gli spoke in peering con l’hub ereditano la risoluzione senza VNet link aggiuntivi.

Passo 3: Gli output DNS

Il file outputs.tf espone i valori DNS rilevanti. In particolare dns_inbound_endpoint_ip è l’IP dell’endpoint inbound, da configurare come DNS server sul router on-premises per permettere la risoluzione dei nomi Azure privati.

output "dns_resolver_id" {

value = module.dns_resolver.resource_id

}

output "dns_inbound_endpoint_ip" {

value = module.dns_resolver.inbound_endpoints["inbound"].ip_configurations[0].private_ip_address

}

output "private_dns_zone_resource_ids" {

value = module.dns_zones.private_dns_zone_resource_ids

}

Passo 4: Applicare e verificare

Dopo terraform init, applicare il piano. La creazione delle oltre 100 Private DNS zones è rapida ma popola l’elenco delle risorse in modo consistente.

terraform plan -out tfplan

terraform apply tfplan

Al termine, aprire rg-hub-itn nel portale. Tra le prime risorse si trovano dnsresolver-hub-itn (DNS private resolver) e frs-hub-itn (DNS forwarding ruleset).

Figura 1: Il contenuto di rg-hub-itn: si riconoscono dnsresolver-hub-itn (DNS private resolver) e frs-hub-itn (DNS forwarding ruleset).

Scorrendo l’elenco si trova l’insieme completo delle Private DNS zones (privatelink.*) di scope Global, tutte linkate alla VNet hub.

Figura 2: L’insieme delle Private DNS zones Private Link di scope Global, create dal modulo pattern AVM.

Verifica del deployment

Il deployment DNS e’ completo quando:

dnsresolver-hub-itn e’ in stato Succeeded con endpoint inbound e outbound attivi.
frs-hub-itn e’ presente (con regole vuote o popolate).
Le Private DNS zones privatelink.* sono create e linkate alla VNet hub.
L’output dns_inbound_endpoint_ip restituisce l’IP da configurare on-premises.

COMPLETATO: Il servizio DNS dell’hub e’ operativo: DNS Private Resolver con endpoint inbound e outbound, e le Private DNS zones Private Link linkate alla VNet. Gli spoke in peering ereditano la risoluzione dei nomi privati e le reti on-premises possono risolvere i nomi Azure tramite l’endpoint inbound.

Conclusioni

Abbiamo deployato con Terraform e Azure Verified Modules i due componenti DNS dell’hub: il DNS Private Resolver, che sostituisce le vecchie DNS forwarder VM con un servizio PaaS gestito ad alta disponibilita’, e le Private DNS zones Private Link create in blocco dal modulo pattern AVM. Insieme abilitano la risoluzione ibrida coerente tra cloud e on-premises.

NOTA: Come evoluzione, popolare il forwarding ruleset frs-hub-itn con le regole per i domini on-premises, e configurare i DNS server aziendali per inoltrare le query dei domini Azure privati verso l’IP dell’endpoint inbound.