Windows Server 2003 & 2008 – Scavenging dei Record DNS

Ciao a tutti!

Oggi parleremo di record DNS, ed in particolare del meccanismo denominato “Scavenging”.

Tale procedimento è stato implementato per evitare che nel tempo si vadano ad accumulare record DNS obsoleti. Pensate ad esempio ad un server DHCP che assegna ad un client un indirizzo IP diverso ogni volta che tale computer si connette: ciò risulta in una pluralità di record DNS diversi registrati, di cui solo l’ultimo sarà effettivamente valido e utilizzabile.

Lo Scavenging si occupa quindi della cancellazione dei record obsoleti, ma essendo la cancellazione una operazione delicata, va abilitata esplicitamente a livello di record (1), di zona (2), e di server DNS (3).

1) Sulle proprietà del record deve essere abilitata la voce "delete this record when it becomes stale" (se non fosse possibile visualizzare questo checkbox, è necessario selezionare View/Advanced dal menu della consolle DNS). Questo flag è sempre attivo di default se sono utilizzati i dynamic updates. Ogni record dinamico ha un TIMESTAMP - orario di creazione/ultima modifica, mentre se viene creato un record a mano il timestamp è 0 e lo Scavenging non è abilitato. Ad esempio, in figura abbiamo un record creato il 6 Dicembre 2010:

2) Sulla zona lo scavenging si abilita nelle proprietà di “Aging” e si possono settare due intervalli: REFRESH e NO_REFRESH. Questi timer si riferiscono ai record e servono per determinare dopo quanto tempo un record diventa "eleggibile" per la cancellazione. Nel dettaglio NO_REFRESH è l’intervallo compreso tra l’istante in cui il record è stato aggiornato l’ultima volta e l’istante in cui sarà disponibile per la prossima modifica; questo è implementato per impedire che vengano fatte troppe scritture in modifica al database. REFRESH è invece l’intervallo tra l’istante in cui il record diventa disponibile alle modifiche e il momento in cui diventa candidato allo scavenging e all’eliminazione. Nel nostro esempio, configuriamo i due intervalli con il valore di default 7+7 giorni:

Nota Bene: I timestamps dei record DNS verranno aggiornati - e replicati fra i diversi server DNS in caso di zona integrata in Active Directory - solo se l’aging sulla zona è abilitato.

3) Sul server deve essere abilitata la voce "Enable automatic scavenging of stale records" nelle proprietà avanzate. Questo contatore (SCAV_PERIOD) simboleggia la frequenza con cui il Server lancerà il processo di Scavenging. Anche qui, in figura, configuriamo il valore default di 7 giorni.

Alla luce di questo, un record diventa elegibile per lo Scavenging solamente quando è passato il tempo dato da: TIMESTAMP + NO_REFRESH + REFRESH. Spesso capita di ricevere segnalazioni di utenti che comunicano la non avvenuta cancellazione di record nonostante siano trascorsi i 14 giorni dalla creazione del record (i 7+7 giorni di REFRESH+NO_REFRESH sulla zona). Ma per avere la certezza che il record venga eliminato, bisogna aspettare l’esecuzione del processo di Scavenging che avverrà al massimo SCAV_PERIOD giorni dopo. In pratica, se tutti i settings sono configurati correttamente, con i parametri di default i records verranno cancellati tra il 14esimo e il 21esimo giorno.

Nel nostro esempio, il record che era stato creato il 6 Dicembre diventerà candidato allo scavenging a partire dal 20 Dicembre (14 giorni dopo) ma non verrà cancellato fino al prossimo ciclo di scavenging, nel nostro caso programmato per il giorno 22 Dicembre.

E’ bene inoltre sottolineare che:

• i valori per REFRESH, NO_REFRESH e SCAV_PERIOD vanno dimensionati in relazione alla durata dei lease del DHCP
• modificare la durata di tali intervalli NON comporterà il cambiamento della prossima data per cui è previsto il ciclo di scavenging. Per farlo, è necessario disabilitare i flags "Enable automatic scavenging of stale records" e “Scavenge scavenge stale resource records” su server e zona, e poi ri-selezionarli successivamente, apportando le desiderate modifiche agli intervalli.
• Non è possibile eseguire ripetute operazioni di scavenging con intervalli inferiori ad 1 ora

Per ulteriori informazioni, si fa riferimento ai seguenti documenti:

• Understanding Aging and Scavenging
• Enable Automatic Scavenging of Stale Resource Records
• Reset Aging and Scavenging Properties for a Specified Resource Record

Ciao a tutti e alla prossima!

Stefano Gagliardi
Support Engineer
Microsoft Enterprise Platform Support

Comments

• Anonymous
  December 06, 2013
  Ciao Stefano, ottima esposizione dell'argomento al quale si lega poi una corretta configurazione del DHCP (come hai già menzionato). Volevo chiederti però come tu riesci a gestire la situazione seguente: firewall o qualsiasi altro dispositivo esterno che gestisce la navigazione internet o altri servizi con privilegi in base anche ai nomi dei computer (oltre che al nome utente). Gli utenti con PC portatili spesso passano dalla rete cablata alla rete wifi e viceversa e quindi ottengono 2 indirizzi IP diversi con relativi record DNS distinti. A questo punto se il dispositivo interroga il DNS ottiene giustamente solo l'ultimo risultato e di conseguenza, per la maggior parte delle volte, non riesce ad autorizzare il client. Si tratterebbe di aggiornare il DNS con tempi strettissimi di fatto. Come si potrebbe risolvere la questione. Grazie

• Anonymous
  December 06, 2013
  Ciao Luke, Grazie dei complimenti! Lo scenario dei client mobili è molto complesso. Se il client si sposta prima che il lease sia esaurito, il DHCP server non ha modo di capire che il vecchio IP non è più “valido”. Inoltre, il client non può nemmeno più comunicarlo al server in quanto ora è in una rete diversa... In un mondo ideale, prima di cambiare rete l’utente dovrebbe fare ipconfig /release ma questo non potrà sempre succedere. Comunque quando sarà il momento di aggiornare il DHCP lease (tipicamente al 50% della sua durata) Windows si accorgerà che non è più in quella rete e quindi provvederà a terminare il lease e a deregistrarsi dal DNS. La best practice è quindi quella, in scenari di questo tipo ad alta mobilità, di minimizzare i tempi di durata del lease (portandolo anche a poche ore) e di conseguenza i parametri di aging e scavenging. In ogni caso, il DNS server restituisce sempre nelle query tutti i record presenti e non soltanto l’ultimo registrato (con il meccanismo del round robin quindi per query consecutive ti restituisce gli stessi record ordinati in modo diverso). Una soluzione molto semplice è quindi quella di configurare l’applicazione a gestire query response contenenti più di un IP (andando a leggere il secondo se il primo non funziona) o comunque a rifare la query, così il secondo IP verrà restituito per primo. Stefano Support Engineer