MENU
  1. ホーム
  2. Windows Server
  3. Aggiornamento dinamico DNS con DHCP tra domini padre e figlio in Active Directory: cause, soluzioni e best practice

Aggiornamento dinamico DNS con DHCP tra domini padre e figlio in Active Directory: cause, soluzioni e best practice

Windows Server

In ambienti Active Directory con domini padre/figlio è comune che il DHCP del dominio figlio aggiorni la propria zona ma fallisca nel parent. In questa guida spiego perché accade, come impostare deleghe e credenziali, quali opzioni abilitare e come diagnosticare in modo ripetibile.

Indice

Scenario e sintomi

Nel dominio figlio xx.yyy.com il server DHCP registra e aggiorna correttamente i record nella zona DNS locale, ma fallisce quando tenta di creare o modificare record nella zona del dominio padre yyy.com. Nei log DHCP compaiono messaggi “DNS update failed”; alcuni servizi (ad esempio Join al dominio, Enrollment di certificati, reverse lookup, registrazioni SRV per applicazioni) possono mostrare lentezza o errori di risoluzione nomi.

  • Contesto tipico: entrambi i domini appartengono alla stessa foresta AD; le zone DNS sono AD‑integrated; la zona del parent accetta aggiornamenti Secure only.
  • Impatto: record A/PTR non aggiornati, record obsoleti, conflitti di nome, fallimenti di reverse lookup, client che si associano a record non più validi.

Perché accade

Con gli aggiornamenti dinamici sicuri, il server DNS accetta modifiche solo se l’operazione è autenticata via Kerberos e autorizzata dalle ACL della zona. Quando il DHCP aggiorna record per conto dei client, usa un principal di sicurezza per firmare la richiesta:

  • se non sono configurate credenziali, il DHCP usa il computer account del server (es. XX-DHCP$);
  • se sono configurate le DNS Dynamic Update Credentials, usa quell’account (es. YYY\svc_DHCPUpdate), che deve avere permessi espliciti sulla zona di destinazione.

Nel passaggio da zona figlio a zona padre cambia l’autorità (ACL) che governa la scrittura: avere diritti su xx.yyy.com non implica automaticamente diritti su yyy.com. Da qui gli errori “DNS update failed”.

Cause tecniche più comuni

FattoreDescrizione sintetica
Permessi insufficientiL’account usato dal DHCP (computer account o credenziali dedicate) non ha diritti di scrittura nella zona yyy.com.
Credenziali non configurateL’opzione “DNS Dynamic Update Credentials” è vuota; il computer account del dominio figlio non è autorizzato a scrivere nella zona del parent.
Trust o delega carenteI domini, pur nella stessa foresta, non delegano esplicitamente al server DHCP la modifica dei record nella zona padre; ACL mancanti o errate.
Impostazioni di zonaLa zona yyy.com accetta solo aggiornamenti sicuri: senza ACL corrette, gli update vengono rifiutati. Impostare “Non‑secure and secure” solo per test brevi (rischio sovrascritture).
Replica e scope DNSLa zona non è AD‑integrated o replica su uno scope che esclude i DNS del figlio; i cambi non propagano, generando apparenti fallimenti.
Client “anonimi” via DnsUpdateProxySe il DHCP è nel gruppo DnsUpdateProxy senza Name Protection, un altro membro può sovrascrivere record altrui.

Soluzioni operative passo‑passo

Configurare credenziali dedicate per gli aggiornamenti DNS del DHCP

È l’approccio più semplice e prevedibile quando DHCP e DNS appartengono a domini diversi o quando si scrive nella zona del parent.

  1. Creare un account di servizio nel dominio padre (es. YYY\svc_DHCPUpdate), oppure pianificare l’uso di un account gestito.
    • Valutazione sicurezza: credenziali dedicate limitano il perimetro del principal e non espandono i privilegi del computer account.
  2. Concedere diritti sulla zona yyy.com:
    • In DNS Manager → zona yyy.com → Properties → Security → Edit → Add l’account YYY\svc_DHCPUpdate.
    • Concedere almeno:
      • Create All Child Objects
      • Delete All Child Objects (per sostituzioni e cleanup)
      • Write All Properties
      Applicare a “This object and all descendant objects”.
  3. Impostare le credenziali nel DHCP:
    • Aprire DHCP Manager → clic destro su IPv4 → Properties → scheda Advanced → Credentials → inserire YYY\svc_DHCPUpdate e password.
    • Se esistono più server DHCP, ripetere su ciascun nodo (o usare un runbook automatizzato).
  4. Verificare registrando un nuovo lease o rinnovandone uno esistente; monitorare i log DNS/DHCP.

Nota gMSA: in molte realtà si preferisce eliminare la gestione manuale della password sfruttando un Group Managed Service Account per i servizi che interagiscono con DNS. In alternativa, mantenere un normale account “utente di servizio” con rotazione periodica e vaulting centralizzato. Verificare in laboratorio il supporto della propria versione di sistema e la modalità d’uso più idonea (come credenziale di update o come identità del servizio DHCP).

Delegare i permessi al computer account del server DHCP

Se non si desidera gestire password/credenziali:

  1. Aggiungere l’oggetto computer del server (es. XX-DHCP$) alle ACL della zona yyy.com con gli stessi diritti indicati sopra.
  2. Opzione alternativa ma meno sicura: inserire il server nel gruppo DnsUpdateProxy. Comodo nei lab o per collisioni di record, ma qualsiasi membro può sovrascrivere record di altri; usare insieme a Name Protection del DHCP e solo se strettamente necessario.

Controllare e correggere le impostazioni delle zone DNS

  • Assicurarsi che xx.yyy.com e yyy.com siano AD‑integrated e replicati sullo scope corretto (ForestDnsZones o DomainDnsZones in base al design).
  • Impostare Dynamic updates su Secure only in produzione. Usare Non‑secure and secure solo per test puntuali e monitorati.
  • Abilitare Aging/Scavenging per ripulire record stantii (valori tipici: No‑Refresh 7 giorni, Refresh 7 giorni; adattare al tempo dei lease).
  • Verificare eventuali delegation e conditional forwarder tra domini per assicurare risoluzione coerente.

Verificare il trust e la connettività

  • In Active Directory Domains and Trusts controllare che il trust intra‑foresta sia bidirezionale e funzionante.
  • Verificare il secure channel tra server DHCP e DC del parent; la connettività Kerberos/LDAP deve essere libera (porte note) tra i domini.

Impostare correttamente le opzioni del DHCP

  • In IPv4 → Properties → DNS selezionare Always dynamically update A and PTR records.
  • Spuntare Discard A and PTR records when lease is deleted per mantenere la zona pulita.
  • Abilitare Name Protection se si usa DnsUpdateProxy o si teme spoofing di nomi.
  • Assicurarsi che l’opzione 015 (DNS Domain Name) e 006 (DNS Servers) puntino alla risoluzione corretta per il parent.

Procedura di diagnostica affidabile

  1. Log DHCP: analizzare i file DhcpSrvLog-*.log e gli eventi nel registro “DHCP Server/Operational”. I codici 30‑38 coprono richiesta/riuscita/fallimento degli update.
  2. Log DNS: cercare eventi 4010/4015 e errori di autorizzazione; controllare anche conflitti DHCID e permission denied.
  3. Test di update manuale con le stesse credenziali:
    • Aprire una sessione con l’account usato dal DHCP (runas o accesso diretto) e tentare un aggiornamento verso yyy.com.
    • Se l’update manuale fallisce, il problema è di permessi/ACL o di autenticazione Kerberos.
  4. Confermare ACL effettive sulla zona: il principal usato per l’update deve comparire nelle ACL della zona (o ereditare diritti via gruppo).
  5. Repliche: forzare la replica AD e verificare che tutti i DNS autorevoli per yyy.com ricevano le modifiche.

Best practice raccomandate

  • Credenziali dedicate per gli update DNS da DHCP verso zone di altri domini; isolano il rischio e semplificano l’audit.
  • Account gestiti (ad es. gMSA) per ridurre la superficie dell’errore umano nella rotazione password, previa verifica del supporto nel proprio stack.
  • Centralizzare gestione DHCP/DNS nello stesso dominio o orchestrare con IPAM per controlli e report unificati.
  • Runbook di delega e rinnovo credenziali, testati periodicamente (incluso scenario di rollover e di disaster recovery).
  • Hardening delle ACL: concedere il minimo necessario (Create/Delete child + Write properties) alla zona target, evitando permessi globali su tutte le zone.
  • Monitoraggio: alert su eventi di fallimento update e su eccesso di non-authoritative answer nei resolver interni.

Checklist veloce

ControlloObiettivoEsito atteso
Account per gli update configuratoFar firmare al DHCP gli update verso yyy.comCredenziali impostate in Advanced → Credentials
ACL della zona yyy.comAutorizzare l’account o il computer accountDiritti Create/Delete child + Write all properties
Impostazioni update zonaAbilitare aggiornamenti sicuriSecure only in produzione
Opzioni DHCPAllineare policy di registrazione/cleanupAlways update + Discard on lease delete
Replica DNSPropagazione coerente tra DNS autorevoliRecord visibili su tutti i server di yyy.com
Trust e KerberosAutenticare update cross‑domainSecure channel sano, ticket validi

Esempio guidato di configurazione

Preparazione dell’account di servizio nel parent

  1. Creare l’utente YYY\svc_DHCPUpdate con password complessa e scadenza gestita via vaulting.
  2. In DNS Manager, aprire la zona yyy.com → Properties → Security → Edit → Add → selezionare l’account creato e assegnare:
    • Create All Child Objects
    • Delete All Child Objects
    • Write All Properties
    Applicazione: “This object and all descendant objects”.
  3. Eventuale hardening: limitare l’account a log on as a service disabilitato e nessun altro diritto in AD oltre alla scrittura sulla zona.

Configurazione del DHCP nel dominio figlio

  1. Aprire DHCP Manager → IPv4 → Properties → scheda DNS:
    • Selezionare Always dynamically update A and PTR records.
    • Abilitare Discard A and PTR records when lease is deleted.
  2. Aprire Advanced → Credentials e inserire YYY\svc_DHCPUpdate.
  3. Rinnovare un lease di test e osservare la creazione dei record in yyy.com (A e PTR).

Alternativa senza credenziali: concedere alla macchina XX-DHCP$ i diritti di update sulla zona del parent. È più semplice da mantenere ma lega la funzionalità al computer account specifico; in scenari con più server e failover potrebbe richiedere più voci di ACL.

Diagnostica approfondita

Interpretare i log del DHCP

  • I file DhcpSrvLog-*.log contengono voci con codici dedicati agli update DNS (serie 30‑38). Filtrare su indirizzo IP, hostname e outcome.
  • Nel registro eventi “DHCP Server/Operational” cercare eventi di esito negativo con dettaglio sul motivo (permesso negato, timeout, record in uso, ecc.).

Eventi del DNS server

  • 4010: impossibile creare un RR a causa di errori di autorizzazione o dati inconsistenti (spesso ACL errate o conflitti DHCID).
  • 4015: problemi nel dialogo con Active Directory (replica, permessi, connettività); indizio che il problema non è solo “applicativo”.

Test di aggiornamento end‑to‑end

  1. Aprire una sessione con l’identità che il DHCP usa per l’update (account di servizio o computer account).
  2. Eseguire un aggiornamento verso yyy.com creando un record temporaneo (ad es. dhcptest.yyy.com) e poi rimuoverlo. Il mancato aggiornamento in questa fase conferma un problema di permessi/ACL, non del “motore DHCP”.
  3. Controllare la replica della modifica su tutti i DNS autorevoli di yyy.com.

Domande frequenti

Posso lasciare la zona del parent su “Non‑secure and secure” per evitare problemi di permessi?

Sconsigliato. Rende possibile a qualsiasi host inserire record arbitrari con rischi di spoofing. Usare l’impostazione mista solo in test mirati e brevissimi, poi tornare a Secure only. Basta autorizzare il DHCP in AD per risolvere?

No. L’autorizzazione del server DHCP nel directory (operazione “Authorize”) è necessaria per erogare lease in dominio, ma non conferisce diritti di scrittura nelle zone DNS. Servono comunque ACL o credenziali per la zona target. Meglio credenziali dedicate o delega al computer account?

Dipende dal design. Le credenziali dedicate offrono separazione dei privilegi e audit più pulito, utili quando il DHCP scrive in zone di altri domini. La delega al computer account riduce la gestione delle password ma richiede ACL per ciascun server. Il gruppo DnsUpdateProxy risolve magicamente i problemi?

No. È un workaround con implicazioni di sicurezza: i membri possono sovrascrivere record altrui. Usarlo solo se strettamente necessario e sempre insieme a Name Protection. Quando ha senso usare account gestiti (gMSA)?

Quando si vuole eliminare la rotazione manuale delle password e la propria versione di Windows Server e il modello operativo lo supportano. Verificare attentamente in lab la modalità d’uso nell’integrazione DHCP/DNS del proprio ambiente.

Runbook operativo sintetico

  1. Creare account di servizio nel parent (YYY\svc_DHCPUpdate).
  2. Delegare sulla zona yyy.com i diritti Create/Delete child + Write all properties.
  3. Impostare le credenziali in DHCP → IPv4 → Properties → Advanced → Credentials.
  4. Configurare Always update e Discard on lease delete; valutare Name Protection.
  5. Verificare trust intra‑foresta e connettività Kerberos/LDAP.
  6. Eseguire test di update; analizzare log DHCP e DNS.
  7. Abilitare Aging/Scavenging e verificare la replica della zona.

Studio di caso ed evidenza pratica

In un ambiente con dominio figlio xx.yyy.com e parent yyy.com, il DHCP del figlio generava “DNS update failed” esclusivamente verso la zona del parent. Dopo numerosi tentativi di tuning, il team HQ ha inserito nell’istanza DHCP credenziali con permessi espliciti su entrambe le zone. Gli errori sono scomparsi immediatamente e in modo persistente. Ciò ha confermato che la causa principale era la mancanza di autorizzazioni e che, nonostante affermazioni contrarie, le credenziali rimangono indispensabili quando DHCP e DNS appartengono a domini diversi e la zona target è configurata per aggiornamenti sicuri.

Errori ricorrenti da evitare

  • Concedere Full Control alla zona a un account generico “per farlo funzionare”: risolve nel breve, ma espone a rischi e audit negativi.
  • Lasciare l’opzione “Non‑secure and secure” attiva in produzione per “comodità”.
  • Dimenticare di impostare le credenziali su tutti i server DHCP (specialmente in failover).
  • Non allineare Aging/Scavenging al ciclo di vita dei lease, accumulando record obsoleti.
  • Ignorare la replica della zona: un update che “funziona qui ma non lì” spesso è un problema di scope di replica, non del DHCP.

Appendice di comandi utili

I comandi di seguito sono esempi pratici per verifiche e amministrazione; adattare a policy e versioni in uso.

Verifica trust e connettività

nltest /domain_trusts
nltest /sc_verify:YYY
klist

Controllo rapido della replica DNS

repadmin /replsummary
repadmin /showrepl

Pulizia cache resolver e verifica SOA

ipconfig /flushdns
nslookup -type=soa yyy.com

Esempio di prova di aggiornamento (concettuale)

Eseguire l’operazione sotto l’identità usata dal DHCP per l’update e creare temporaneamente dhcptest.yyy.com per validare le ACL; al termine rimuoverlo.

Conclusioni

Il meccanismo degli aggiornamenti dinamici sicuri in ambienti a domini padre/figlio richiede un principal con diritti espliciti sulla zona target. La soluzione più robusta è definire credenziali dedicate (o un account gestito dove applicabile), delegare i permessi minimi necessari sulla zona del parent e impostare correttamente il DHCP per aggiornare e ripulire i record. Con un runbook di diagnosi e manutenzione (ACL, trust, replica, aging/scavenging) si prevengono i “DNS update failed” e si mantiene affidabile la risoluzione nomi.

Riepilogo operativo

  • Usare credenziali dedicate o delega mirata al computer account del DHCP per scrivere su yyy.com.
  • Impostare Always update e Discard on lease delete nel DHCP; valutare Name Protection.
  • Mantenere la zona del parent su Secure only in produzione; abilitare Aging/Scavenging.
  • Verificare periodicamente trust, replica e log per individuare anomalie prima che impattino i servizi.
Windows Server
Active Directory DHCP DNS Troubleshooting Windows Server
Indice