Zone e risoluzione dei nomi

Il ruolo DNS Server su Windows Server risolve i nomi mappandoli a record (A, AAAA, CNAME, PTR, SRV, MX). Distingui subito i tipi di zona. Una primary zone è la copia scrivibile; una secondary zone è di sola lettura, aggiornata via zone transfer, utile per ridondanza e per l’offload delle query. Una stub zone contiene solo i record NS, SOA e A dei name server autoritativi di un’altra zona: mantiene i referral aggiornati senza replicare l’intera zona.

La scelta chiave sui domain controller è la Active Directory-integrated zone: la zona vive nella directory, si replica con la replica AD (niente zone transfer separato), supporta secure dynamic update e consente di scegliere il replication scope (tutti i DNS server della foresta, del dominio, tutti i DC del dominio, o una application partition custom). Preferiscila sui DC per sicurezza e resilienza multi-master; usa primary/secondary standalone solo dove AD non è presente. Non trascurare le reverse lookup zone per i record PTR, richiesti da molti servizi (mail, logging, alcuni scenari Kerberos).

Forwarder, conditional forwarder e DNSSEC

Un forwarder inoltra tutte le query che il server non risolve autoritativamente a uno o più server upstream; se falliscono, intervengono le root hints. Un conditional forwarder inoltra invece le sole query per un namespace specifico (es. corp.contoso.com) a server designati: è lo strumento cardine per l’integrazione ibrida e per la risoluzione cross-forest, più preciso e sicuro dell’inoltro generico.

DNSSEC protegge l’integrità delle risposte firmando la zona: introduce i record RRSIG, DNSKEY, DS e NSEC/NSEC3, con separazione tra Key Signing Key (KSK) e Zone Signing Key (ZSK). I resolver validano tramite i trust anchor; sui client Windows la validazione obbligatoria si impone con la NRPT (Name Resolution Policy Table) via Group Policy. DNSSEC garantisce autenticità e integrità, non confidenzialità. Completa la postura di dns-security con il socket pool (randomizza le porte sorgente contro il cache poisoning), il cache locking (impedisce la sovrascrittura delle cache entry prima della scadenza del TTL) e il Response Rate Limiting (mitiga gli attacchi di amplificazione DNS).

DNS policies e split-brain DNS

Le DNS policies applicano logica alle query tramite zone scope e criteri: puoi restituire risposte diverse in base a subnet client, interfaccia, ora del giorno o protocollo. I casi tipici sono traffic management (geo-affinità), filtering/block list e, soprattutto, lo split-brain DNS.

Nello split-brain DNS lo stesso nome (es. www.contoso.com) risolve a un IP interno per i client aziendali e a un IP pubblico per quelli esterni. Storicamente richiedeva due server separati; con zone scope multipli più una query resolution policy puoi ottenerlo su un singolo server DNS, riducendo la superficie gestionale. Mantieni la separazione fisica solo quando i requisiti di isolamento tra vista interna ed esterna sono stringenti.

Risoluzione ibrida verso Azure

In hybrid DNS l’obiettivo è che on-premises e Azure si risolvano a vicenda. Da on-prem, i nomi delle Azure Private DNS zone e dei private endpoint (privatelink.*) si risolvono puntando un conditional forwarder verso l’inbound endpoint dell’Azure DNS Private Resolver. Nella direzione opposta, l’outbound endpoint con un DNS forwarding ruleset inoltra le query per il namespace on-prem ai DNS aziendali. Il Private Resolver è un servizio gestito che sostituisce le vecchie DNS forwarder VM, eliminando manutenzione e single point of failure. Evita di puntare i server DNS della VNet direttamente sui DC on-prem senza un percorso di forwarding controllato: rischi loop e risoluzioni parziali dei nomi Azure interni.

Trappole tipiche d’esame

  • Risolvere i private endpoint Azure da on-prem → conditional forwarder all’inbound endpoint del Private Resolver: un forwarder generico e le root hints non conoscono le Azure Private DNS zone; serve un conditional forwarder per privatelink.* verso l’IP dell’inbound endpoint.
  • Split-brain su un solo server → DNS policies con zone scope: se la domanda vieta host aggiuntivi, la risposta è query resolution policy più zone scope, non una seconda zona su un secondo server.
  • “Rendere sicure le risposte DNS” → distingui DNSSEC dalla confidenzialità: DNSSEC dà autenticità e integrità (firme RRSIG/DS), non cifra il traffico; per la validazione forzata sui client la leva è la NRPT via GPO.
  • Copia di sola lettura per un sito remoto → secondary zone, non stub zone: la stub tiene solo NS/SOA/A dei name server (referral); per servire risposte complete in sola lettura serve una secondary zone via zone transfer.
  • Inoltrare un solo dominio → conditional forwarder, non forwarder globale: il forwarder globale dirotterebbe tutte le query non autoritative; per un singolo namespace usa il conditional forwarder.
  • Zona DNS resiliente e sicura sui DC → AD-integrated con secure dynamic update: replica con AD e blocca gli update non autenticati; la primary standalone non offre né secure update né replica multi-master.