Risoluzione DNS tra foreste Active Directory diverse (AWS e on‑premises): guida completa a conditional forwarder, stub e secondary zone

Hai due foreste Active Directory separate (AWS e on‑premises) e i client locali non risolvono i nomi ospitati nel DNS in cloud? In questa guida completa vediamo come abilitare la risoluzione DNS cross‑forest con i conditional forwarder, quando preferire stub o secondary zone, come testare e come mettere in sicurezza il tutto.

Indice

Scenario e obiettivo

Infrastruttura con due domini/foreste indipendenti, ciascuna con il proprio servizio DNS:

Foresta A (AWS) – ospita i workload applicativi (server applicazione e database). Può esporre DNS Windows Server su VM/EC2 oppure usare Route 53 Resolver con endpoint inbound/outbound. Parte dei server in AWS può essere in workgroup (niente join al dominio) con record DNS statici.
Foresta B (on‑premises) – rete aziendale locale con DNS Windows Server integrato in AD.

Problema: i client on‑premises non riescono a risolvere i record (A/CNAME/SRV, ecc.) definiti nel DNS della foresta AWS, perché i due DNS non condividono informazioni di zona e non hanno deleghe reciproche.

Obiettivo: consentire ai client di entrambe le foreste di risolvere in modo affidabile e sicuro i nomi dell’altro ambiente, senza distribuire nuove impostazioni sui singoli host e senza compromettere l’isolamento dei domini.

Concetti chiave: come funziona la risoluzione cross‑forest

Conditional Forwarder: regola sul DNS richiedente che dice “per tutti i nomi che terminano con aws.example.com invia la query a questi specifici DNS autoritativi”. È stateless: non replica record, inoltra soltanto.
Stub Zone: copia minimale e dinamica dei soli record NS e SOA dell’altra zona. Le query finali vengono comunque risolte dal DNS autoritativo remoto.
Secondary Zone: replica completa read‑only della zona remota tramite zone transfer (AXFR/IXFR). Consente risoluzione locale senza inoltri, ma introduce requisiti di sicurezza e banda per i trasferimenti.
Forest Trust: relazione di trust tra foreste per Kerberos e accessi cross‑forest. Non risolve da sola il DNS; aiuta ad automatizzare/semplificare i forwarder e il routing dei suffissi, ma i meccanismi DNS vanno comunque configurati.

Prerequisiti di rete e sicurezza

Connettività IP: esistenza di un canale sicuro tra on‑prem e AWS (VPN, Direct Connect, o Site‑to‑Site). Se usi Route 53 Resolver, prevedi endpoint inbound/outbound nelle VPC interessate.
Firewall:
- UDP 53 (query) e TCP 53 (risposte grandi, recursion, zone‑transfer) aperti in entrambe le direzioni tra i DNS.
- Se usi secondary zone: abilita AXFR/IXFR dai master al/i secondary.
- Restringi le ACL alle sole subnet necessarie.
Nome di zona: identifica l’FQDN della zona remota (es. aws.example.com o dnsZonaAWS.example.com).
DNS autoritativi remoti: conosci l’IP (meglio due) del/i DNS master della foresta opposta.
Recursion: sui DNS che inoltrano le richieste non abilitare l’opzione “Disable recursion (also disables forwarders)”.

Soluzione consigliata: Conditional Forwarder

Il forwarder condizionale è la scelta più semplice, sicura e con impatto minimo: non replica dati e non richiede deleghe pubbliche. Ideale quando i namespace sono separati (corp.example.com vs aws.example.com) e i DNS remoti sono raggiungibili sui canali privati.

Passi in GUI (DNS Manager su Windows Server)

Apri DNS Manager sul DNS on‑premises.
Click destro sul nome del server → Properties → tab Forwarders → Edit….
Clicca New… e inserisci:
- Dominio: la zona remota (es. aws.example.com).
- Server di inoltro: IP del/i DNS nella foresta AWS (almeno due se possibile).
Opzionale ma utile: spunta Store this conditional forwarder in Active Directory per replicarlo su tutti i DNS della foresta on‑prem.
Conferma e Applica.

Comandi PowerShell equivalenti

# Verifica connettività verso i DNS AWS
Test-NetConnection -ComputerName 10.1.2.10 -Port 53 -InformationLevel Detailed

Crea il forwarder condizionale (replicato a livello di foresta)

Add-DnsServerConditionalForwarderZone `  -Name "aws.example.com"`
-MasterServers 10.1.2.10,10.1.2.11 `  -ReplicationScope Forest`
-PassThru

Regola timeout/resilienza dei forwarder generali (opzionale)

Set-DnsServerForwarder -Timeout 3 -UseRootHints $true

Controllo configurazione

Get-DnsServerConditionalForwarderZone -Name "aws.example.com" | Format-List *

Verifica dal lato client

nslookup nomehost.aws.example.com
nslookup -type=A nomehost.aws.example.com &lt;IPDNSonprem&gt;

Resolve-DnsName nomehost.aws.example.com -Server &lt;IPDNSonprem&gt; -DnsOnly -NoHostsFile

La risposta deve indicare come server autorevole un DNS della foresta AWS. Se non arriva risposta, verifica firewall, reachability, recursion e correttezza della zona.

Forwarder inverso (consigliato)

Replica la stessa configurazione dal lato AWS verso il dominio on‑premises: in tal modo anche i workload in cloud risolveranno i nomi interni (corp.example.com).

Alternative: quando preferire Stub o Secondary Zone

In alcuni scenari conviene diversificare. Ecco un confronto ampliato per scegliere in modo consapevole:

Opzione	Quando usarla	Pro	Contro	Requisiti
Conditional Forwarder	Quando vuoi inoltrare la risoluzione verso il DNS autoritativo remoto senza replicare dati.	Semplice; a basso impatto; nessun trasferimento; caching efficace.	Dipendenza dalla reachability del DNS remoto; latenza di round‑trip.	UDP/TCP 53 tra DNS; nessuna apertura AXFR/IXFR.
Stub Zone	Quando vuoi conoscere dinamicamente i nameserver autoritativi della zona remota mantenendo la risoluzione presso l’origine.	Aggiorna automaticamente i record NS/SOA; utile se i master remoti cambiano.	Più traffico di gestione rispetto al forwarder; risoluzione comunque demandata fuori.	Visibilità dei master; UDP/TCP 53; configurazione della master list.
Secondary Zone (read‑only)	Quando serve una copia locale completa dei record remoti (ad es. siti con latenza elevata o dipendenza da risoluzione offline).	Risoluzione locale anche se il master remoto è irraggiungibile; latenza minima per i client.	Richiede trasferimenti di zona e loro messa in sicurezza; maggiore superficie di gestione; coerenza e TTL da curare.	Abilitare AXFR/IXFR; TCP 53 aperto; whitelist degli IP dei secondary sul master.
Forest Trust + Conditional Forwarder	Se prevedi autenticazione cross‑forest, deleghe Kerberos, migrazioni o accessi trasversali.	Allinea DNS e identità; semplifica la governance dei suffissi; utile per Single Sign‑On.	La trust non basta da sola: i forwarder vanno comunque configurati; governance più complessa.	Relazione di trust bidirezionale o mirata; pianificazione della Name Suffix Routing.

Se in AWS usi Route 53 Resolver

Quando la foresta/namespace in cloud poggia su Route 53 Private Hosted Zone (PHZ) anziché su un DNS Windows, configura:

Inbound Endpoint nella VPC AWS per ricevere query dai DNS on‑prem. Assegna IP privati e security group che consenta UDP/TCP 53 dai DNS locali.
Regola di forwarding lato on‑prem: il conditional forwarder punta agli IP dell’Inbound Endpoint.
Outbound Endpoint + regole (opzionale ma consigliato) per inoltrare da AWS verso on‑prem, completi di forwarding rules per il suffisso corp.example.com.
Associazione PHZ alle VPC dove risiedono i workload, così i record sono visibili internamente.

Questa architettura consente un peering DNS controllato senza esporre i DNS Windows su Internet.

Linee guida operative e buone pratiche

Ridondanza: inserisci almeno due IP per ogni forwarder condizionale; se usi Route 53, crea endpoint in zone di disponibilità diverse.
TTL: per record critici (A/CNAME utilizzati spesso) mantieni TTL coerenti (300–1800s) per bilanciare cache e freschezza; non dimenticare i TTL negativi (NXDOMAIN).
Ordine di risoluzione: mantieni l’ordine predefinito (Conditional Forwarders → altre policy → Root Hints). Evita forwarder “catch‑all” per . a meno di una motivazione specifica.
Split‑horizon: se lo stesso nome esiste con risposte diverse (interno/esterno), sii esplicito nel design dei suffissi (es. int.example.com vs ext.example.com).
Monitoraggio: usa contatori e log. Su Windows:
- dnscmd /statistics (e /statistics /Reset) per misurare risoluzioni, fallimenti, timeout.
- Event Viewer → DNS Server (attenzione a EventID 4010/4013/7062).
- Get-DnsServerStatistics e Get-DnsServerQueryResolutionPolicy per insight via PowerShell.
Sicurezza:
- Apri UDP/TCP 53 solo tra i DNS interessati e le relative subnet.
- Per secondary zone, consenti i zone transfer solo a server noti. Se i master sono BIND/appliance che supportano TSIG, attiva firme HMAC; i DNS Windows tradizionali non supportano TSIG HMAC classiche, preferiscono restrizioni su IP e sicurezza AD‑integrata.
- Valuta DNSSEC se il perimetro lo consente (overhead e gestione chiavi), specialmente in contesti regolati.

Procedura end‑to‑end riassunta

Verifica reachability e porte (UDP/TCP 53) tra DNS on‑prem e AWS (Test-NetConnection).
Configura conditional forwarder on‑prem per aws.example.com verso i DNS AWS.
Configura forwarder inverso in AWS verso corp.example.com.
Testa (nslookup, Resolve-DnsName) e osserva il server che risponde.
Imposta ridondanza, TTL e monitoring.
Documenta e versiona le modifiche (change record), inclusi gli IP e le finestre di manutenzione.

Verifica tecnica e comandi utili

Controlli rapidi

# Lato DNS on‑prem: query diretta ai DNS AWS
Resolve-DnsName ldap.tcp.aws.example.com -Type SRV -Server 10.1.2.10

Query dal client aziendale

Resolve-DnsName app01.aws.example.com

Traccia di risoluzione (Windows 11/Server 2022)

Resolve-DnsName app01.aws.example.com -Server  -DnsOnly -NoRecursion

Strumenti CLI classici

nslookup
&gt; server &lt;IPDNSonprem&gt;
&gt; set q=a
&gt; app01.aws.example.com

Creazione stub/secondary via PowerShell

# Stub Zone
Add-DnsServerStubZone -Name "aws.example.com" -MasterServers 10.1.2.10,10.1.2.11 -ZoneFile "aws.example.com.dns"

Secondary Zone (read‑only)

Add-DnsServerSecondaryZone -Name "aws.example.com" -MasterServers 10.1.2.10,10.1.2.11 -ZoneFile "aws.example.com.dns"

Nota: per le secondary ricordati di consentire i transfer dal lato master e di prevedere le finestre di sincronizzazione.

Pattern architetturali consigliati

Pattern “a stella” con forwarder reciproci

Client on‑prem → DNS on‑prem ⇄ (VPN) ⇄ DNS AWS ← Workload AWS

Entrambe le parti impostano un conditional forwarder verso la zona dell’altra. Semplice e sufficiente nella maggior parte dei casi.

Pattern “edge DNS” in AWS con Route 53 Resolver

Client on‑prem → DNS on‑prem → (forward) → R53 Inbound → PHZ aws.example.com
Workload AWS → R53 Outbound → (forward) → DNS on‑prem

Adatto a più VPC, multi‑account AWS e necessità di segregazione forte.

Checklist di troubleshooting

Nessuna risposta: controlla firewall e security group; prova Test-NetConnection -Port 53 da entrambi i lati.
Timeout: riduci -Timeout dei forwarder, verifica latenza VPN, controlla MTU/fragmentation.
Risoluzione errata: verifica l’ordine dei suffissi di ricerca sui client (GPO DNS Suffix Search List); evita nomi ambigui.
Loop DNS (EventID 7062): assicurati che i DNS non si inoltrino a vicenda per lo stesso suffisso (evita forwarder “circolari”).
NXDOMAIN inatteso: guarda i TTL negativi in cache; svuota cache (Clear-DnsClientCache lato client, Clear-DnsServerCache lato server).
Secondary non si aggiorna: verifica AXFR/IXFR, ACL e possibilità di contattare il master dal secondary (TCP 53).

Domande frequenti

Serve una trust tra foreste per risolvere il DNS?

No. La trust riguarda l’autenticazione. La risoluzione DNS cross‑forest si ottiene con forwarder/stub/secondary indipendentemente dalla trust. Quando prevedi SSO o migrazioni, una trust con Name Suffix Routing ben configurata semplifica la governance, ma non sostituisce i forwarder.

Meglio stub o conditional forwarder?

Se vuoi semplicità e poca manutenzione, conditional forwarder. Se i server autoritativi remoti cambiano di frequente e vuoi autoadattarti, stub zone. Se vuoi risoluzione locale anche in assenza del master, secondary.

È sicuro aprire UDP/TCP 53 tra ambienti?

Sì, se limitato ai soli DNS e subnet richieste, e se non esponi tali porte a Internet. Usa VPN/IPSec/Direct Connect, regole strette e, dove possibile, firma dei transfer (TSIG in ecosistemi BIND) o restrizioni su IP per i DNS Windows.

Ho server in workgroup in AWS: posso comunque pubblicarli?

Sì. Crea record statici nel DNS della foresta AWS. Se ti serve registrazione dinamica da host non autenticati, valuta scavenging, DHCP‑DNS integration o un flusso IaC (Terraform/CloudFormation) che gestisca i record.

Esempio completo: implementazione passo‑passo

Raccolta dati:
- Zona AWS: aws.example.com
- DNS AWS (master): 10.1.2.10, 10.1.2.11
- Zona on‑prem: corp.example.com
- DNS on‑prem: 192.168.10.10, 192.168.10.11
Connettività: verifica da 192.168.10.10 verso 10.1.2.10:53 e viceversa; aggiorna firewall se necessario.
Configurazione on‑prem: conditional forwarder per aws.example.com verso 10.1.2.10 e 10.1.2.11 con replica AD a livello Forest.
Configurazione AWS: forwarder opposto per corp.example.com verso 192.168.10.10 e 192.168.10.11.
Test funzionale: Resolve-DnsName app01.aws.example.com da un client on‑prem e Resolve-DnsName dc01.corp.example.com da un host in AWS.
Osservabilità: attiva log query (se consentito), raccogli statistiche di hit/miss cache e misure di latenza.
Documentazione e runbook: inserisci tabella di mapping dei suffissi, IP dei DNS, livelli di replica e policy di TTL/refresh.

Ottimizzazione delle prestazioni

Cache: i DNS locali memorizzano le risposte per il TTL, riducendo latenza e carico sui link. Verifica che i TTL dei record AWS siano coerenti con le esigenze (più bassi per endpoint dinamici).
Timeout forwarder: su Windows Set-DnsServerForwarder -Timeout 3 (secondi) previene attese eccessive in caso di DNS remoto lento.
Rotazione server: i forwarder provano in ordine; diversifica IP su più AZ/host.
Prossimità: se i client on‑prem accedono spesso a nomi AWS e la latenza è alta, valuta una secondary zone locale.

Hardening e governance

Principio del minimo privilegio: limita chi può creare/alterare forwarder e zone.
Audit: traccia modifiche ai DNS (preferibilmente con change management e approvazioni).
AD‑integrated: per forwarder salvati in AD, usa la replica a livello giusto (Forest se serve cross‑domain).
Backup: esporta la configurazione (PowerShell) a prescindere dall’AD‑integration.

Snippet pronti all’uso

Esporta/backup della configurazione DNS

# Esporta tutti i conditional forwarder
Get-DnsServerConditionalForwarderZone |
  Select-Object Name, MasterServers, ReplicationScope |
  Export-Csv C:\Temp\forwarder.csv -NoTypeInformation

Esporta la lista zone e tipo

Get-DnsServerZone |
Select-Object ZoneName, ZoneType, IsReverseLookupZone |
Export-Csv C:\Temp\zone.csv -NoTypeInformation

Pulizia cache e test ripetuti

# Server DNS
Clear-DnsServerCache

Client

Clear-DnsClientCache
Resolve-DnsName nomehost.aws.example.com -Server

Confezionamento finale

Con i forwarder condizionali (e, dove necessario, stub o secondary zone) abiliti una risoluzione DNS cross‑forest pulita e governabile. È una soluzione modulare: inizi con i forwarder (rapida e poco invasiva), poi, se la latenza o la disponibilità lo richiedono, evolvi a secondary per le zone più strategiche. In ogni caso, ridondanza, monitoraggio e controlli di sicurezza (ACL su UDP/TCP 53, limitazione dei transfer, audit) restano pilastri imprescindibili. Così i client di entrambe le foreste risolveranno correttamente i record DNS dell’altro ambiente, senza dover toccare le configurazioni sui singoli host.

Riepilogo operativo rapido

Apri VPN/Direct Connect con UDP/TCP 53 tra i DNS.
Crea il conditional forwarder su on‑prem verso aws.example.com (salvalo in AD per la replica).
Crea il forwarder inverso su AWS verso corp.example.com.
Testa con nslookup/Resolve-DnsName; verifica il DNS che risponde.
Aggiungi monitoring (dnscmd /statistics), ridondanza e hardening.

Tabella di riferimento rapido

Attività	Strumento	Comando/Path	Note
Check porte	PowerShell	`Test-NetConnection <IP> -Port 53`	Ripeti da entrambi i lati.
Creare forwarder	PowerShell	`Add-DnsServerConditionalForwarderZone`	Usa `-ReplicationScope Forest` se necessario.
Verificare	CLI	`nslookup`, `Resolve-DnsName`	Controlla l’IP del server autorevole.
Monitorare	CLI/PowerShell	`dnscmd /statistics`, `Get-DnsServerStatistics`	Valuta errori/timeouts.
Alternative	PowerShell	`Add-DnsServerStubZone`, `Add-DnsServerSecondaryZone`	Richiedono lista master e (per secondary) AXFR/IXFR.

Conclusione: i conditional forwarder sono il “coltello svizzero” della risoluzione DNS tra foreste: rapidi da mettere in opera, sicuri perché non replicano dati e facili da governare. Integrali, quando serve, con stub o secondary zone e completa l’architettura con monitoring e regole firewall ben definite. Otterrai una risoluzione affidabile tra on‑prem e AWS, senza interventi sui singoli client.

Una volta creati i forwarder o le zone stub/secondarie, i client di entrambe le foreste risolveranno correttamente i record DNS dell’altro ambiente, senza dover modificare le impostazioni sui singoli host.