Scritto da:
admin in data: marzo 26, 2009 19.40 - Letto 2895 volte
Il concetto di DNS (Domain Name System - RFC952) di Windows2000, è completamente diverso da quello di WindowsNT.
Una workstation Windows2000 che ha la necessità di contattare una risorsa, cerca il nome di quest'ultima nel DNS, in modo tale da risalire al suo indirizzo IP. Ma non solo, una workstation Windows2000 utilizza il DNS anche per fare il logon su un dominio (e quindi per contattare un Domain Controller).
Il sistema DNS svolge un ruolo fondamentale, ed è indispensabile, per il corretto funzionamento di un dominio Windows2000.

Risoluzione dei nomi
E' la conversione da nome dominio a indirizzo IP (es. www.sysadmin.it -> 62.149.130.108).
In principio, la conversione dei nomi, non veniva gestita dai DNS, ma tramite un file chiamato hosts (presente in %systemroot%/system32/drivers/etc). Con il passare del tempo, e con l'aumentare vertiginoso di server presenti su internet, diventava però impossibile aggiornare questo file. Fortunatamente, grazie al sistema DNS, questa operazione non si rende più necessaria.
Il server DNS è chiamato anche "server dei nomi" e può osservare quattro ruoli diversi:
-
Server di zona primario (DNS Primario)
E' quello che crea la zona e si dice che è quello "autoritativo" per quel dominio (ovvero la zona è su quel server). Il file di zona è un file di testo e contiene la corrispondenza tra IP e nome host, il mail server, etc.
-
Server di zona secondario (DNS secondario)
Il server secondario conserva una copia delle zone esistenti sul server primario, in caso quest'ultimo non sia disponibile. Inoltre fà si che il carico sia bilanciato.
-
Server master
Fornisce un elenco di file di zona ai server secondari, questo processo si chiama trasfer zone.
-
Server di cache
Non conservano file di zona al proprio interno, quando vengono interrogati fanno riferimento al server dei nomi, e mettono in le informazioni nella cache, in modo tale che la successiva risposta sia più veloce poichè non necessita di trasferimento di zone. Di solito vengono installati all'estremità di una WAN lenta.
Quando un server riceve una richiesta per un dominio non "autoritativo", interroga altri "name server" e le richieste che fanno possono essere di tre tipi:
-
Richieste ricorsive
Si ha quando un client interroga il suo "name server" chiedendo una risoluzione assoluta del nome di un indirizzo IP
-
Richieste Iterative
Sono richieste di risoluzione di nomi "parziali". Viene fatta, di solito, tra server di nomi.
-
Richieste inverse
Avviene quando si vuole risolvere l'indirizzo IP in un nome host. In questo caso il DNS ha una zona chiamata "in-addr.arpa" o reverse zone, in cui è riportato un elenco con gli indirizzi IP e i nomi host corrispondenti
Come funziona la distribuzione gerarchica
Per sapere se un dominio è stato registrato, si può effettuare un'interrogazione al database di un'autorità preposta alla registrazione di domini (per esempio Network Solutions). Sul questo DB però, non si troveranno informazioni sul dominio ricercato. Quindi, non si potrà sapere se all'interno del dominio (per esempio sysadmin.it) è presente il computer test.sysadmin.it. Questo perchè, tutto quello che avviene all'interno del dominio sysadmin.it non è di competenza dell'autorità che registra i domini. Tutto quello di cui ha bisogno quest'ultima, è sapere il nome del responsabile del dominio (admin-c) e dei due computer che fungeranno da DNS server (detti anche server autoritativi) per quel dominio.
Ma vediamo bene come funziona la gerarchia DNS. Supponiamo che una macchina del dominio icmp.it, voglia raggiungere via browser il dominio www.sysadmin.it, ecco passo per passo quello che succede:
- Il browser interrogherà il DNS locale (quello di icmp.it) per conoscere l'indirizzo IP di www.sysadmin.it
- Il DNS locale, non conoscendo l'ip, a sua volta girerà la richiesta ai DNS radice (server esterni che conoscono tutti i DNS dei domini Internet)
- La richiesta verrà presa in carico da uno dei server radice, e quest'ultimo risponderà di non conoscere l'IP richiesto, ma di sapere l'IP dei due server DNS autoritativi del dominio sysadmin.it
- A questo punto il DNS locale (quello di icmp.it) contatta i DNS di sysadmin.it e gli richiede l'IP di www.sysadmin.it
- Il DNS di sysadmin.it risponde comunicando l'IP di www.sysadmin.it, completando la risoluzione

Come aggiungere un nuovo host al fine di zona
Per aggiungere un nuovo host (record) al fine di zona di un server DNS, è molto semplice grazie all'interfaccia grafica di Windows. In ambienti non Microsoft, Bind è quella più famosa, si deve editare un file ASCII.
Il DNS di Windows2000, supporta lo standard DDNS (Dynamic Domain Name System - RFC2136), che consente agli host Windows2000 di essere aggiunti automaticamente al file di zona del DNS locale. Aggiunta di livelli al nome di dominio
Come detto prima, la struttura dei nomi è completamente gerarchica. Vediamo un altro caso:
Supponiamo di avere due sedi, una a Roma e l'altra a Milano, e ogni sede debba utilizzare un proprio DNS locale. In questo caso risulterebbe comodo aggiungere un ulteriore livello ai nomi delle macchine del dominio sysadmin.it: roma.sysadmin.it e milano.sysadmin.it. A questo, il server principale sysadmin.it terrà conto del fatto che ora ci sono altre due zone con i rispettivi server autoritativi.
Quindi la macchina della Redazione di Roma si chiamerà redazione.roma.sysadmin.it e quella di Milano si chiamerà redazione.milano.sysadmin.it.
Allo stato attuale, una query fatta da icmp.it, per richiedere l'IP di redazione.roma.sysadmin.it, seguirebbe questo percorso:
-
Il DNS di icmp.it interroga un database di un'autorità preposta alla registrazione di domini, per sapere l'IP dei server DNS di sysadmin.it
-
Il DNS di sysadmin.it, che non conosce l'IP di redazione.roma.sysadmin.it, reindirizzerà la richiesta al DNS di Roma
-
Il DNS di Roma, risponderà con l'IP di redazione.roma.sysadmin.it
Gli esempi riportati finora fanno riferimento ad una reta collegata ad Internet, ma il l'essenza discorso non cambia se tale distribuzione gerarchica viene applicata ad una rete LAN/WAN.
Il DNS e la posta elettronica
Il sistema DNS viene anche utilizzato anche per individuare i sistemi di posta elettronica installati su un dominio. Questa ricerca è resa possibile dall'inserimento di un record, chiamato record MX (Mail eXchanger), nel file di zona, che fornisce il nome della su cui è installato un server di posta.
Ridondanza dei server DNS
Al fine di garantire un'adeguata affidabilità e fault-tolerance del servizio DNS, è opportuno installare un DNS primario e un DNS secondario, e settarli entrambi sugli host.
La replica delle variazioni fatte sul file di zona avviene in modo automatico dal DNS primario al secondario. Se un host effettua una query sul DNS secondario, quest'ultimo risponderà usando la copia del proprio file di zona. il file di zona del DNS secondario è caratterizzato da un TTL (Time To Live): se non viene aggiornato (dal DNS primario) entro questo periodo di tempo (si solito 24 ore), il DNS secondario considera le proprie informazioni scritte sul file di zona obsolete e le ignora.
E' il Record SOA (State of Authority) a stabilire qual'è il DNS Primario e il Secondario. Su questo record, inoltre, viene riportato il TTL del DNS secondario e gli indirizzi di posta elettronica dei contatti tecnici del dominio.
In un dominio si può avere un solo DNS Primario e infiniti DNS Secondari.
DNS e Active Directory
Per operare con Windows2000, e per sfruttare appieno le potenzialità di Active Directory (clicca qui per leggere la guida), i server DNS devono rispettare i seguenti requisiti:
-
Devono supportare le specifiche contenute nell' RFC2052 (descrive la possibilità di interrogare altri tipi di server attraverso un nuovo tipo di record DNS: un record SRV)
-
Devono supportare le specifiche contenute nell' RFC2136 (DDNS)
Queste due specifiche non vengono supportate solo dal DNS di Microsoft, ma anche da altri server DNS come BIND (ultima versione).
Il server DNS, deve anche poter supportare i nomi di host che usano il carattere underscore, poichè quest'ultimo è utilizzato da molti record creati da Active Directory.
(a cura di SB)