Ciao a tutti, oggi parliamo di DNS. Sicuramente conoscete tutti il protocollo e sapete già che per il suo funzionamento è necessaria una infrastruttura di rete, semplice o complessa che sia, che prevede la presenza di server DNS ai quali I clients inoltrano query ogni volta che hanno bisogno di risolvere un nome in un indirizzo IP.

Quello che non tutti sanno è che una importante parte del lavoro viene fatta dal DNS resolver, cioè il servizio DNS client che gira sulle macchine che vanno a generare la richiesta e la inviano al server. Una opportuna configurazione del DNS client permetterà di ottimizzare le performance riducendo al minimo la necessità di interrogare ogni volta il DNS server per risolvere le query. il servizio DNS client (shortname dnscache) è attivo su tutti I sistemi operativi Windows, comprese le versioni server.

Innanzitutto il meccanismo di risoluzione è il seguente:

  1. DNS client controlla la cache locale (anche detta DNS resolver cache)
  2. Se non trova nulla, DNS client interroga il DNS server


Di conseguenza, maggiore è il numero di record in cache, minore è la necessità di interrogare il server potenzialmente sprecando risorse di rete e sovraccaricandolo di richieste.

è bene notare che ogni volta che si avvia il servizio DNS client, automaticamente viene popolata la cache con I records presenti staticamente nel file HOSTS. Questo meccanismo permette quindi di non risolvere mai tali nomi tramite una query DNS, ma di gestirli sempre localmente.

Per tutti gli altri record, ogni volta che viene fatta una query verso un server DNS, il servizio client provvederà ad aggiungere tale informazione alla cache locale. Tale informazione rimane memorizzata in cache per un periodo predefinito, per la precisione il minore dei seguenti valori:

• il numero di secondi specificati nel campo TimeToLive nel pacchetto di risposta alla query DNS

• il valore della chiave di registro HKLM\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters\MaxCacheTtl

 

Per dare alcune indicazioni aggiuntive, sappiamo che il campo TimeToLive viene popolato dal DNS server prendendo l’informazione dalla relativa proprietà (customizzabile) del record DNS.

 

image

 

image

Di default, se il record DNS di cui stiamo parlando appartiene ad un client Windows, il valore è 1200 secondi = 20 minuti.

Per modificarlo, basta cambiare il relativo valore della seguente chiave di registro sulla macchina client proprietaria del record DNS (non sul DNS server nè su un ipotetico DNS resolver!)

DefaultRegistrationTTL

Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value type: REG_DWORD
Default: 0x4B0 (1200 decimal, or 20 minutes)
Valid range: 00xffffffff
Present by default: No

Detto ciò, poichèMaxCacheTtlha un valore di base di 86400 secondi (1 giorno) possiamo riassumere dicendo che in un ambiente con tutti I settings mantenuti di default, tipicamente un record rimane memorizzato nella cache del resolver DNS per 20 minuti. Se il record è invece un record statico sul DNS server, tipicamente il TTL vale 60 minuti.

Il comando ipconfig /displaydns ci permette di visualizzare il contenuto della cache del DNS client comprensiva di contatore del TTL in tempo reale.

image

 

Quando il DNS resolver, dopo non aver trovato il record, in cache, deve interrogare il server, lo fa seguendo un algoritmo preciso.

1) se il nome da risolvere è un FQDN, viene effettuata una query per l’FQDN stesso

2) se il nome da risolvere è di tipo “unqualified” (in parole povere se non è un FQDN) il DNS resolver effettua una serie di query consecutive appendendo suffissi DNS di vario tipo finchè non viene risolto uno dei nomi. In particolare:

2a) viene aggiunto il suffisso DNS primario. Il suffisso primario è il nome del dominio nel caso di workstation membri di un dominio Active Directory, altrimenti è quello presente nel pannello sysdm.cpl

2b) se la query con suffisso primario fallisce, vengono effettuate ulteriori query appendendo I suffissi aggiuntivi specificati nelle proprietà avanzate / DNS della scheda di rete

image

 

Ad esempio, se il mio dominio è blue.int per risolvere qualsiasi nome di host al’interno del mio dominio, sarà sufficiente effettuare una query per hostname e automaticamente il DNS client appenderà il suffisso ed effettuerà una query per hostname.blue.int.

Allo stesso modo, se voglio risolvere server.green.int ci basterà effettuare una query per server e il comportamento atteso sarà

  1. query per server.blue.int –> server DNS risponde Name Error
  2. query per server.white.int –> server DNS risponde Name Error
  3. query per server.green.int –> server DNS risolve correttamente e ci restituisce il record desiderato

è importante sottolineare che:

  • è necessaria una esplicita risposta del server per I vari Name Error, senza la quale il processo non proseguirà. Non dobbiamo quindi allarmarci se vediamo tali “errori” durante una cattura del traffico di rete.
  • qualora esista un qualsiasi record server.white.int ma noi cerchiamo di risolvere server.green.int il processo si interromperà al secondo step perchè è stata ottenuta una risposta positiva e l’algoritmo non proseguirà mai per green.int In caso di ambiguità quindi è bene specificare l’FQDN completo in fase di query

 

A questo punto, una domanda che i clienti ci chiedono spesso: È possibile effettuare una query per una sola “porzione” dell’FQDN?

Questa impostazione può essere utile in uno scenario con domini child.
Ad esempio se volessimo cercare il record client.child.blue.int è possibile effettuare una query per client.child e lasciare appendere il suffisso al servizio DNS client?

La risposta è SI su Windows XP / 2003, mentre NO di default da Vista / 2008 in poi.
Se vogliamo che il client Vista / 2008 si comporti come XP / 2003 e riesca a gestire questo tipo di query è necessaria una piccola modifica il registro, creando la seguente chiave:

 

AppendToMultiLabelName

Key:

HKLM\SYSTEM\CurrentControlSet\Services\DNScache\Parameters
Value type: REG_DWORD
Value: 1

 

Infine, un problema che affligge moltissimi utenti. Se tento di risolvere tramite nslookup.exe direttamente server.green.int , che comportamento mi aspetto da parte del DNS client? La maggior parte degli utenti risponderebbe: una query diretta per server.green.int - RISPOSTA ERRATA!

Il comportamento atteso by design è il seguente

  1. query per server.green.int.blue.int –> server DNS risponde Name Error
  2. query per server.green.int.white.int –> server DNS risponde Name Error
  3. query per server.green.int.green.int –> server DNS risponde Name Error
  4. query per server.green.int.–> server DNS risolve correttamente e ci restituisce il record desiderato

Ebbene si: nslookup.exe tenta di aggiungere I suffissi in modo “doppio”. Perchè? Stiamo forse infrangendo l’algoritmo che abbiamo appena definito? No, perchè server.green.int non è tecnicamente un FQDN e viene quindi trattato come un nome unqualified. L’FQDN vero, da definizione standard internazionale è server.green.int. comprensivo di “trailing dot” cioè il punto “.” finale che rappresenta la zona di root. una query quindi per server.green.int. verrà immediatamente gestita senza appendere altri suffissi. Provare per credere Smile

Ciao a tutti e alla prossima

Stefano Gagliardi
Support Engineer
Microsoft Enterprise Platform Support