DNS: zone, forwarding, policy e DNSSEC

Sul DNS l’AZ-802 non chiede più «che cos’è una stub zone». Chiede che cosa succede davvero quando il primo forwarder non risponde, perché un record rinominato risolve ancora, e quale condizione blocca la firma di una zona. Questa unità sta su quel piano: il comportamento osservabile, non la definizione.

DNS e AD DS: la mappatura dei nomi, non solo le zone

Una zona Active Directory-integrated vive nella directory, si replica con la replica AD e accetta il secure dynamic update (solo client autenticati aggiornano i propri record). Il replication scope si sceglie fra foresta, dominio, tutti i DC del dominio o una application partition dedicata: è la leva con cui decidi dove quella zona esiste.

La parte che l’esame sfrutta è però il DC locator. I domain controller registrano record SRV (_ldap._tcp.dc._msdcs.dominio, più le varianti site-specific); il client chiama DsGetDcName, legge gli SRV, fa un LDAP ping UDP e mette in cache il DC che risponde per primo. Se il DC risponde da un sito non ottimale, il client scarta la cache dopo 15 minuti e ritenta nel proprio sito.

Il caso interessante è quello di un’applicazione che passa a DsGetDcName un nome corto in stile NetBIOS. Il locator prova sempre a mappare quel nome corto su un nome DNS, attingendo in quest’ordine: cache di una ricerca precedente, tutti i domini della foresta corrente, i top-level name dei forest trust e degli external trust in ingresso, poi — da Windows Server 2025 — le mappature configurate dall’amministratore e le mappature per tutti i domini e i domini figlio delle foreste con cui c’è trust, e infine le sessioni di sign-in sulla macchina.

Se nessuna fonte produce un nome DNS, in passato si ripiegava sulla discovery NetBIOS (WINS o mailslot). Da Windows Server 2025 il DC locator non la consente più: la policy BlockNetBIOSDiscovery (Computer Configuration → Administrative Templates → System → Net Logon → DC Locator DNS Records) è a TRUE per impostazione predefinita. WINS è deprecato da Windows Server 2022, i mailslot da Windows Server 2025. Per riabilitare i mailslot servirebbero due interventi: BlockNetBIOSDiscovery a FALSE e EnableMailslots lato SMB (Set-SmbClientConfiguration).

Quando il dominio di destinazione sta in un’altra foresta senza trust, nessuna delle fonti automatiche può mappare il nome corto. La strada supportata è la mappatura esplicita a livello di foresta: proprietà del dominio in Active Directory Domains and Trusts, scheda DC locator mappings. Finisce in un serviceConnectionPoint (CN=DCLocatorDomainNameMappings,CN=Windows NT,CN=Services,CN=Configuration,…), attributo msDS-Settings, con valori nella forma dominio.com:NETBIOSNAME. Netlogon sui client scarica e mette in cache queste mappature ogni 12 ore.

Record: quello che il cmdlet non fa

Set-DnsServerResourceRecord lavora per sostituzione di oggetto: si legge il record con Get-DnsServerResourceRecord, si clona ([ciminstance]::new($OldObj)), si modifica la copia e si passano entrambi con -OldInputObject e -NewInputObject.

$OldObj = Get-DnsServerResourceRecord -Name "host01" -ZoneName "contoso.com" -RRType "A"
$NewObj = [ciminstance]::new($OldObj)
$NewObj.TimeToLive = [System.TimeSpan]::FromHours(2)
Set-DnsServerResourceRecord -NewInputObject $NewObj -OldInputObject $OldObj -ZoneName "contoso.com" -PassThru

Il limite è dichiarato nella documentazione: Set-DnsServerResourceRecord non può cambiare Name né Type. Rinominare host01 in app01 non è una modifica, è Remove-DnsServerResourceRecord del vecchio più Add-DnsServerResourceRecordA del nuovo. Se rimuovi solo con Remove-DnsServerResourceRecord -Name "host01" -ZoneName "contoso.com" -RRType A e ti fermi lì, app01 non esiste; se aggiungi soltanto, host01.contoso.com continua a risolvere fino a scadenza della cache.

Forwarding: l’aritmetica dei timeout

Il server usa i forwarder nell’ordine della lista, aspettando il timeout su ciascuno prima di passare al successivo. Sopra tutto sta il RecursionTimeout, a livello di server: quando scade, la risposta al client è Server failure.

Il conto: primo forwarder a 0 s, secondo a 5,5 s (c’è ~0,5 s di overhead), il terzo cadrebbe a 11,5 s ma a 8 s RecursionTimeout è già scaduto. Il Server failure non parte subito allo scadere, ma quando sarebbe il momento di provare il forwarder successivo: da qui gli ~11,5 s. Elencare quattro conditional forwarder non serve a niente con i valori predefiniti: il terzo e il quarto non vengono mai interrogati. Se il quarto è l’unico sano, o riordini la lista o alzi ForwarderTimeout e RecursionTimeout (dnscmd /config /RecursionTimeout valore).

Attenzione al tipo di fallimento. Timeout significa attesa e fallback al server successivo. Una risposta esplicita — REFUSED o NXDOMAIN — è una risposta: il server non prova il secondo forwarder, e un REFUSED viene girato al client come Server failure quasi immediato. Se un conditional forwarder fallisce in un istante, sospetta una query resolution policy con azione DENY sul server di destinazione (Get-DnsServerQueryResolutionPolicy), non la rete.

Infine: con Dynamic Forwarder Reordering attivo (default) la lista viene riordinata in base ai tempi di risposta e riportata all’ordine configurato ogni ~15 minuti; oltre due risposte lente consecutive (più di 1 s) spostano il forwarder in fondo. Da Windows Server 2022, se nessun forwarder risponde il server continua a usare solo il primo della lista dinamica fino al riavvio del servizio DNS: si torna al ciclo su tutti con Set-DnsServerForwarder -EnableReordering $false.

Le root hints restano il fallback quando i forwarder non rispondono e la ricursione è attiva. Non si eliminano: Microsoft non supporta un server DNS senza almeno una root hint, e quelle cancellate dalla console ricompaiono dopo ~15 minuti perché vivono anche in CACHE.DNS e in Active Directory. Per escluderle davvero si spunta Do not use recursion for this domain nella scheda Forwarders.

Risoluzione ibrida e NRPT

Da on-premises verso Azure si punta un conditional forwarder all’inbound endpoint dell’Azure DNS Private Resolver; nella direzione opposta l’outbound endpoint con un DNS forwarding ruleset rimanda il namespace aziendale ai DNS on-prem. Il conditional forwarder, se AD-integrated, si replica come una zona.

Lato client la leva è la NRPT: il DNS Client consulta la tabella prima di emettere la query, e la regola può imporre la validazione DNSSEC o dirottare un namespace. Si configura in Computer Configuration → Policies → Windows Settings → Name Resolution Policy, o con Add-DnsClientNrptRule -GpoName nome -NameSpace namespace -DnsSecEnable -DnsSecValidationRequired; si verifica con Get-DnsClientNrptPolicy -Effective.

Le regole di merge sono precise e l’esame ci pesca dentro. Regole in GPO diversi su namespace diversi si fondono, e la regola più specifica vince: una regola su secure.contoso.com prevale su una per contoso.com, e la validazione non si eredita verso il basso — parent e child vogliono regole esplicite. Ma due regole in due GPO diversi sullo stesso namespace non si sovrascrivono: vanno in conflitto e non viene applicata nessuna delle due. E se un GPO di dominio configura la NRPT, tutte le impostazioni NRPT del GPO locale vengono ignorate.

DNS policies

Una query resolution policy valuta criteri (subnet client, interfaccia, protocollo, ora, nome richiesto) e sceglie un zone scope: è così che si ottiene lo split-brain su un solo server. Le azioni sono ALLOW, DENY (risponde REFUSED) e IGNORE (non risponde affatto). Le policy esistono a livello di server e a livello di zona, e i recursion scope permettono di abilitare la ricursione per alcuni client e negarla ad altri sullo stesso server.

DNSSEC

Firmare una zona aggiunge DNSKEY, RRSIG, DS e NSEC/NSEC3, con KSK e ZSK distinti (minimo uno per tipo, massimo tre per algoritmo). La zona può essere forward o reverse, statica o dinamica, AD-integrated o file-backed; per le zone AD-integrated la copia firmata resta in memoria, su disco finisce solo per quelle file-backed.

I prerequisiti sono quelli che l’esame chiede: ruolo DNS Server installato, strumenti di amministrazione remota DNS, il server deve essere primary e autoritativo per la zona (una secondary riceve i record DNSSEC ma non si firma né si modifica), la zona deve essere non firmata, e credenziali amministrative — Domain Admin se AD-integrated.

Algoritmo e metodo NSEC devono essere compatibili: RSA/SHA-1 vuole NSEC, RSA/SHA-1 (NSEC3) vuole NSEC3, e le due varianti non convivono nella stessa zona. ECDSAP256/SHA-256, ECDSAP384/SHA-384, RSA/SHA-256 e RSA/SHA-512 accettano entrambi.

Dopo la firma, alcuni parametri si cambiano a caldo. Salt e iterazioni NSEC3 sono fra questi:

Set-DnsServerDnsSecZoneSetting -ZoneName "contoso.com" -NSec3RandomSaltLength 8 -NSec3Iterations 50 -Verbose

Niente unsign, niente re-sign. Altri parametri invece impongono Invoke-DnsServerZoneUnSign seguito da Invoke-DnsServerZoneSign — e in quel caso i trust anchor già distribuiti ai resolver vanno aggiornati a mano. Le impostazioni di KSK e ZSK modificate a zona firmata non agiscono subito: entrano in vigore al rollover successivo (double signature per il KSK, prepublish per lo ZSK).

Trappole tipiche d’esame

• «Rinomina il record mantenendo tipo e indirizzo» → non esiste un rename. Set-DnsServerResourceRecord non tocca Name né Type: servono Remove-DnsServerResourceRecord e poi Add-DnsServerResourceRecord…. Una risposta che usa solo Set- o solo Add- è sbagliata due volte, perché il vecchio nome continua a risolvere.
• Quattro conditional forwarder, i primi due morti → nessuno risponde comunque. Con i default (ForwarderTimeout 5 s, RecursionTimeout 8 s) il server ne interroga due: il terzo e il quarto, per quanto sani, non vengono mai contattati. Il client riceve Server failure dopo ~11,5 s.
• Server failure immediato → risposta esplicita, non timeout. Un fallimento istantaneo con la query che parte davvero verso il primo forwarder significa REFUSED (tipicamente una query resolution policy DENY) o NXDOMAIN. Il secondo forwarder non viene provato: aumentare i timeout o aggiungere server non cambia nulla.
• Due GPO con una regola NRPT sullo stesso suffisso → non ne vale nessuna. Le regole NRPT non si sovrascrivono. Si fondono solo su namespace diversi, dove vince la più specifica. E un GPO di dominio che configuri la NRPT annulla per intero la NRPT locale.
• Firma DNSSEC che non parte → guarda il ruolo del server e lo stato della zona. Le due condizioni sono: server primary e autoritativo per quella zona (mai una secondary) e zona non già firmata. Il tipo AD-integrated o file-backed, forward o reverse, non è un ostacolo.
• Cambiare salt e iterazioni NSEC3 → si fa a zona firmata. Set-DnsServerDnsSecZoneSetting -NSec3RandomSaltLength -NSec3Iterations basta e avanza; la risposta che impone unsign e re-sign è la trappola. Il re-sign serve per altri parametri, e lì il costo vero è la ridistribuzione manuale dei trust anchor.
• Nome corto NetBIOS verso una foresta senza trust, su Windows Server 2025 → mappatura esplicita. La discovery NetBIOS è bloccata per default (BlockNetBIOSDiscovery = TRUE): la strada è la scheda DC locator mappings in Active Directory Domains and Trusts, non WINS e non un file lmhosts.