DNS pubblici nel DHCP per PC in dominio: rischi, best practice e configurazione corretta

Un consulente propone di aggiungere DNS pubblici come “terziario/quaternario” nel DHCP per PC in dominio, più i forwarder sui DNS interni. Sembra una rete più resiliente, in realtà introduce instabilità e rischi. Qui trovi perché non è best practice e come configurare correttamente AD DNS e DHCP.

Indice

Scenario e problema da risolvere

In molte reti Active Directory (AD) i Domain Controller (DC) svolgono anche il ruolo di server DNS autorevoli per il dominio interno (record SRV, LDAP, Kerberos, GC, ecc.). Alcuni consulenti suggeriscono di:

configurare i DNS pubblici/ISP come terziario e quaternario nello scope DHCP;
impostare gli stessi DNS pubblici come forwarder sui DNS interni.

Obiettivo dichiarato: “Se i due DC/DNS sono down, i client risolvono comunque i nomi Internet”. La domanda giusta è: è davvero una best practice? Cosa si rischia?

Perché non è una best practice aggiungere DNS pubblici ai client di dominio

Comportamento moderno dei resolver

L’idea “primario → secondario → terziario” non descrive più il comportamento reale dei resolver moderni. Windows 10/11, macOS, iOS e Android:

possono inviare richieste in parallelo a più server DNS;
selezionano il server “più veloce” o “disponibile”, non necessariamente in ordine;
con più interfacce (LAN, Wi‑Fi, VPN, hotspot) possono interrogare DNS diversi per ogni interfaccia.

Risultato: anche con DC perfettamente online, alcune query andranno a DNS pubblici. Per i nomi interni (es. ldap.tcp.dc._msdcs.contoso.local) i DNS pubblici non sanno rispondere: si generano timeout, ritardi e fallback inaspettati.

Impatto operativo su Active Directory

Logon lenti o falliti: il client non trova SRV AD in tempo utile; GPO e script di accesso possono non applicarsi.
Problemi di accesso alle risorse: file server, stampanti e servizi raggiunti per FQDN interni non risolvono.
Messaggi intermittenti: l’utente “a volte funziona, a volte no”, difficilissimi da diagnosticare.
Registrazioni dinamiche incoerenti: con Option 81 (Client FQDN) e aggiornamenti A/PTR, i client potrebbero non aggiornare il DNS interno.

Rischi di sicurezza

Esposizione di metadati interni: query per nomi come server1.ad.contoso.local finiscono su Internet (in chiaro su UDP/53), aumentando la superficie d’attacco e la visibilità dell’asset interno.
Manipolazione del traffico: se un client usa DNS non sotto il tuo controllo, eventuali policy di filtro/risoluzione sicura non si applicano.
Bypass delle ispezioni: con DoH (DNS‑over‑HTTPS) abilitato lato endpoint o browser, si può aggirare l’intero controllo DNS aziendale.

La best practice: solo DNS interni per i client

La linea guida chiave è semplice e solida:

Client e server di dominio puntano solo ai DNS interni (in genere i DC), impostati via DHCP (Option 006) o staticamente dove necessario.
Risoluzione Internet demandata ai forwarder configurati sui DNS interni (ISP, Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9, ecc.).
Blocca a livello di rete qualunque richiesta DNS diretta verso l’esterno che non provenga dai DNS interni.

In questo modo:

tutte le query per nomi AD restano on‑prem e funzionano in modo coerente;
la navigazione Internet funziona tramite i DC/DNS che inoltrano solo le query non autorevoli verso i forwarder;
si mantiene il controllo (log, policy, filtering, sicurezza) sul traffico DNS.

Perché i forwarder (sui DNS interni) sono la strada giusta

Separazione dei ruoli: i client chiedono sempre ai DNS interni; i DNS interni risolvono localmente ciò che è autorevole e inoltrano il resto.
Cache centralizzata: migliori tempi di risposta grazie alla cache condivisa sul DNS interno.
Controllo e auditing: puoi registrare, filtrare o bloccare domini indesiderati direttamente sul perimetro DNS.

Gestione del fail‑over: resilienza vera, non “terziario/quaternario” pubblico

Se l’obiettivo è la continuità del servizio, la soluzione è ridondare correttamente i DNS interni (non “sperare” nei DNS pubblici ai client):

Almeno due DC/DNS in siti fisicamente distinti (o su host/cluster separati) con zone AD‑integrated replicate.
DHCP ridondante (failover 50/50 o hot‑standby), così da continuare a distribuire Option 006/015 anche in caso di guasto di un server DHCP.
Monitoraggio proattivo (servizi DNS, AD, replica, spazio disco, CPU/memoria) e alerting con procedure di autoripristino.
Runbook chiaro per il ripristino di DC/DNS: backup di System State, snapshot coerenti, procedure autorevoli/non autorevoli.

Nota importante: se tutti i DC/DNS sono indisponibili, la priorità non è “far navigare Internet”, ma ripristinare AD/DNS. Senza AD funzionante, l’azienda è di fatto degradata (logon, applicazioni, file server, stampa).

Configurazione consigliata — passo per passo

DHCP: distribuire solo DNS interni

Nello scope DHCP, imposta:

Option 006 (DNS Server): IP dei DC/DNS (es. 10.0.0.10 e 10.0.0.11);
Option 015 (DNS Domain Name): FQDN del dominio AD (es. ad.contoso.local);
Option 081 (Client FQDN): per gestire gli aggiornamenti dinamici A/PTR dal client verso il DNS interno;
Option 119 (Domain Search List): opzionale, utile in contesti multi‑namespace interni.

Esempio PowerShell (Windows Server DHCP):

# Imposta DNS dello scope 10.0.0.0/24
Set-DhcpServerv4OptionValue -ScopeId 10.0.0.0 -DnsServer 10.0.0.10,10.0.0.11 -DnsDomain "ad.contoso.local"
Abilita aggiornamenti dinamici (se richiesti)
Set-DhcpServerv4DnsSetting -ScopeId 10.0.0.0 -DynamicUpdates "Always" -UpdateDnsRRForOlderClients $true

DNS interni: forwarder verso DNS pubblici affidabili

Configura i forwarder sui DNS interni (DC/DNS):

# Aggiunge forwarder su DC/DNS
Add-DnsServerForwarder -IPAddress 8.8.8.8,1.1.1.1,9.9.9.9 -PassThru
Verifica la configurazione
Get-DnsServerForwarder

Se non utilizzi i root hints (o non sono aggiornati), puoi rimuoverli o tenerli come fallback consapevole:

# (Opzionale) Rimuove i root hints per forzare l'uso dei forwarder
Get-DnsServerRootHint | Remove-DnsServerRootHint -Force

Per domini partner specifici (es. partner.lan), usa conditional forwarder invece di forwarder generici.

Client statici e server applicativi

Per server con IP statico (file server, applicativi, hypervisor) vale la stessa regola: solo DNS interni come primario/secondario. Evita di inserire DNS pubblici “di backup”.

Validazione: come verificare che tutto lavori correttamente

Controlla i client: ipconfig /all deve mostrare solo gli IP dei DC/DNS come server DNS.
Test risoluzione interna: Resolve-DnsName ldap.tcp.dc._msdcs.ad.contoso.local Resolve-DnsName fileserver01.ad.contoso.local
Test risoluzione Internet (passa attraverso i forwarder): Resolve-DnsName www.microsoft.com nslookup www.wikipedia.org
Verifica log del DNS per errori su zone AD‑integrated e latenza nei forwarder.

Sicurezza: impedire il bypass dei DNS interni

Blocca il traffico DNS diretto verso Internet

Nel firewall perimetrale e negli apparati di accesso:

Consenti UDP/TCP 53 in uscita solo dai server DNS interni verso i forwarder;
Nega UDP/TCP 53 da tutte le altre subnet client verso Internet.

Gestione del DNS‑over‑HTTPS (DoH)

Per mantenere il pieno controllo della risoluzione, valuta la disabilitazione del DoH lato endpoint tramite criteri:

GPO Windows: Configurazione computer → Modelli amministrativi → Rete → Client DNS → Configurare DNS over HTTPS (imposta su “Disabilitato” o applica il comportamento predefinito desiderato). Le denominazioni esatte possono variare in base alla versione di Windows.
Browser: applica policy centralizzate per disattivare DoH o forzare DoH solo verso resolver aziendali autorizzati (Edge/Chrome/Firefox hanno criteri dedicati).

Ricorda: il server DNS di Windows, allo stato attuale, inoltra via DNS “classico” verso i forwarder; il controllo di DoH riguarda i client.

Split‑brain DNS e loop di risoluzione

Se gestisci lo stesso namespace sia in pubblico sia in interno (es. contoso.com pubblico e contoso.com interno), assicurati che:

i record interni restino sui DC/DNS autoritativi per l’ambiente interno;
i forwarder non rimandino a loro volta a un resolver che dipende dal tuo DNS interno (evita loop);
eventuali record “condivisi” (es. www) seguano un disegno chiaro (reverse proxy, split‑horizon, record diversi per interno/esterno).

VPN, dispositivi mobili e reti multi‑homed

Con device mobili e laptop che passano da VPN a reti pubbliche:

Forza l’uso dei DNS interni quando il tunnel è attivo (push di configurazione del client VPN/MDM, script di connessione, policy del vendor). Alcune soluzioni supportano opzioni DHCP/criteri proprietari (talvolta indicati come “Option 135” o equivalenti) per veicolare parametri di risoluzione: usa le opzioni previste dal tuo stack.
Valuta NRPT (Name Resolution Policy Table) o meccanismi analoghi per indirizzare specifici namespace verso i DNS aziendali.
Riduci le interfacce attive (metrica adattiva, disabilita split tunneling quando non necessario) per evitare query su DNS indesiderati.

Tabella di configurazione rapida (fare / evitare)

Componente	Da impostare	Da evitare	Note operative
Scope DHCP	DNS 1 → DC A DNS 2 → DC B Option 015 dominio AD	Qualsiasi DNS esterno (ISP, Google, Cloudflare, ecc.)	Abilita Option 81 per update dinamici, valuta Option 119 per search list
DNS interni	Forwarder → DNS pubblici affidabili	Root hints obsoleti o non gestiti	Rimuovi o aggiorna i root hints; usa conditional forwarder per domini partner
Client statici	Puntare ai DC (primario/secondario)	DNS pubblici come “backup”	Controlla anche schede di mgmt/iDRAC/iLO: niente DNS esterni
Firewall	Consenti UDP/TCP 53 in uscita solo dai DNS interni	Traffico DNS diretto da VLAN client verso Internet	Logga i drop per intercettare configurazioni errate
Endpoint	DoH disabilitato o gestito via policy	DoH libero verso resolver pubblici	Applica criteri per Windows e browser

Checklist di implementazione

Rilevazione: inventaria gli scope DHCP e gli indirizzi DNS distribuiti ai client; individua eventuali DNS pubblici.
Correzione: aggiorna gli scope impostando solo DC/DNS; rimuovi ogni DNS esterno da DHCP e configurazioni statiche.
DNS interni: configura i forwarder e, se non usati, rimuovi i root hints; aggiungi conditional forwarder per domini noti.
Rete: applica il blocco del traffico DNS in uscita da subnet client verso Internet (eccetto i DNS interni).
Policy: definisci GPO/MDM per DoH e broker VPN; documenta le eccezioni (se davvero necessarie).
Monitoraggio: attiva alert su servizio DNS, code di risoluzione/timeout, stato dei forwarder, salute AD.
Test: campiona client da VLAN diverse; verifica logon, GPO, risoluzione nomi interni ed esterni.
Runbook: scrivi le procedure di emergenza (vedi sezione seguente) e simulane l’esecuzione.

Runbook di emergenza (guasti DNS/AD)

Verifica servizi: controlla stato del servizio DNS Server e Active Directory Domain Services su ciascun DC.
Replica: esamina la replica AD (eventuali errori) e la disponibilità delle zone AD‑integrated.
Forwarder: se le risoluzioni Internet sono lente, verifica raggiungibilità dei forwarder (latenza, packet drop).
Cache: svuota la cache DNS se necessario (Clear-DnsServerCache) per escludere voci corrotte.
Ripristino: se un DC è compromesso, segui la procedura di ripristino da System State; in scenari critici, esegui un re‑promote controllato.
Comunicazione: informa gli stakeholder che finché AD/DNS non è ripristinato, alcune funzioni (logon, GPO, app) resteranno limitate.

Domande frequenti

Posso tenere DNS pubblici come “ultima spiaggia” sui client?

No. Anche come “ultima voce”, i resolver potrebbero usarli in condizioni normali, creando instabilità e leak di informazioni. La resilienza si ottiene con ridondanza dei DNS interni, non con scorciatoie.

E per i PC fuori dominio o BYOD?

Non ricevendo Option 006/015 dello scope aziendale, useranno DNS pubblici o quelli della rete ospite: va bene. L’importante è che i PC joinati e i server in dominio ricevano solo DNS interni quando sono in rete aziendale o in VPN.

Che differenza c’è tra forwarder e root hints?

I forwarder definiscono esplicitamente a quali resolver inoltrare le richieste non autorevoli; i root hints guidano la risoluzione iterativa partendo dai server root. I forwarder sono di solito preferibili per performance, cache condivisa e controllo.

Come gestire ambienti multi‑site?

Distribuisci DC/DNS per ogni sito, configura la priorità dei DNS vicini nei DHCP locali, usa site‑aware GPO e subnet AD Sites and Services aggiornate. I forwarder possono essere comuni o differenziati per sito, in base alla rete.

Indicatori di successo (SLA/metriche)

Tasso di query interne risolte ≥ 99,9% con latenza < 20 ms.
Zero query DNS verso Internet dalla rete client (escluse eccezioni autorizzate).
Nessun evento di logon ritardato per problemi DNS su workstation/server di produzione.
Allarmi attivi sui servizi DNS/AD con MTTR definito.

Conclusione

Aggiungere DNS ISP come terziario/quaternario nello scope DHCP non è una best practice: genera comportamenti imprevedibili, degrada l’esperienza utente, aumenta i rischi di sicurezza e non offre vera continuità. La strategia corretta è:

Solo DNS interni per i client in dominio (via DHCP o statici);
Forwarder sui DNS interni verso resolver pubblici affidabili per l’accesso a Internet;
Ridondanza reale di DC/DNS, monitoraggio e runbook di ripristino;
Controlli di sicurezza: blocco del DNS egress non autorizzato e gestione del DoH.

Così ottieni stabilità, prestazioni e governance su un servizio critico come il DNS, preservando funzionalità di AD e sicurezza dell’ambiente.

Appendice: esempi pratici

Verifica rapida sui client

# Elenca i DNS configurati su tutte le interfacce
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, ServerAddresses

Testa risoluzione di un record SRV AD

Resolve-DnsName -Type SRV kerberos.tcp.dc._msdcs.ad.contoso.local

Verifica dei forwarder dal server DNS

# Rileva latenza percepita verso ciascun forwarder
$fw = (Get-DnsServerForwarder).IPAddress.IPAddressToString
foreach ($ip in $fw) {
  $r = Test-NetConnection -ComputerName $ip -Port 53
  "{0} - Ping:{1}ms - TCP53:{2}" -f $ip, $r.PingReplyDetails.RoundtripTime, $r.TcpTestSucceeded
}

Hardening minimo del ruolo DNS

Usa zone AD‑integrated con aggiornamenti dinamici sicuri.
Limita ricorsione e trasferimenti di zona solo ai peer autorizzati.
Isola la gestione su rete dedicata o con ACL severe.

Politiche browser per DoH (indicazioni generali)

Edge/Chrome: imposta le policy aziendali per disabilitare DoH o vincolarlo a resolver approvati.
Firefox: applica criteri MDM/policy per il Trusted Recursive Resolver (TRR) o disattivalo.

Note su ambienti ibridi

In scenari hybrid (on‑prem + cloud) continua a valere lo stesso principio: i nodi joinati devono interrogare DNS sotto il tuo controllo (controller di dominio on‑prem o DNS gestiti in cloud ma autoritativi per il namespace interno). Usa conditional forwarder verso DNS dei servizi cloud quando serve (es. risoluzione privata di endpoint PaaS).

Riepilogo operativo

Non mettere DNS pubblici nello scope DHCP dei client in dominio.
Configura solo DC/DNS interni come resolver per i client.
Usa forwarder sui DNS interni per l’accesso a Internet.
Rendi ridondanti DC/DNS e monitora costantemente.
Blocca il DNS egress non autorizzato e gestisci il DoH.