Rapida introduzione al DNS

Quello che segue e' una rapida presentazione del DNS con alcuni suggerimenti per la sicurezza del sistema. Non lo considero ESAUSTIVO o COMPLETO. Purtroppo, il DNS e' un argomento talmente vasto che una trattazione completa e' al di fuori degli scopi di questo sito.

Per una trattazione completa, consiglio vivamente di leggere la documentazione ufficiale del DNS (le RFC) e magari l'ottimo libro di Paul Albitz & Cricket Liu "DNS and BIND", edito da O'Reilly.

Soprattutto se dovete gestirvi DNS per lavoro e non per solo divertimento.

Nei lontani (oramai) anni '70, DARPANet (precursore dell'attuale internet) era un'accozzaglia di un paio di centinaia di servers, occupati a scambiarsi dati, files e messaggi di posta. Piu' o meno come l'attuale internet, ma con molti meno utenti e meno servers.

Anche all'ora il problema era: come individuare un server nella rete in modo rapido. Ovviamente, allora come oggi, ogni server era identificato dal suo indirizzo ip, ma ricordarsi gli indirizzi non e' una cosa a cui gli esseri umani siano mai stati molto bravi. Quello che ci voleva era un sistema per agganciare un nome ad un indirizzo IP. Questo lavoro era svolto all'inizio da un semplicissimo file di testo denominato HOSTS.TXT. Il file era mantenuto dallo Stanford Research Institute Network Information Center (SRI-NIC).

I vari amministratori spedivano le loro modifiche al SRI-NIC via e-mail ed ogni tanto scaricavano una versione aggiornata del loro file. Non tutto il file era necessario ai vari sistemi per funzionare, in genere il file sorgente veniva riprocessato per generare il "vero" file operativo (denominato semplicemente hosts). Solo che questo sistema funziona quasi bene quando ci sono un paio di centinaia di servers che non cambiano tanto, ma quando la vecchia DARPANet si trasformo' nell'attuale Internet, SRI-NIC si trovo' a gestire un grosso problema.

Per prima cosa il numero di modifiche ed aggiornamenti aumenta esponenzialmente all'aumentare dei servers, per seconda cosa e' difficile gestire l'univocita' dei nomi (lo stesso nome host non puo' apparire due volte, altrimenti diventa un casino) per non parlare poi della consistenza dei dati. Ci voleva un sistema migliore.

Il nuovo sistema doveva essere innanzitutto decentralizzato, invece di avere un unico ente incaricato di aggiornare tutti i dati, l'idea era di delegare la gestione di parti del sistema ad altri enti e persone. Per seconda cosa doveva essere distribuito, in maniera che diversi servers potessero agire come intermediari e fornire risposte senza dover necessariamente coinvolgere tutta la struttura.

Paul Mockapetris propose con le RFC 882 ed 883 il sistema che divento' poi il DNS che tutti usiamo.

Allora, mettiamo il caso che voi (o uno dei vostri utenti) digitiate nel vostro browser 'www.ilmiobelsito.it'. Come accidenti fa' il computer a sapere quale dei millemila servers di internet e' quello giusto?

In ogni computer collegato ad una rete TCP/IP (quindi anche ad internet) c'e' un pezzo di software chiamato resolver. Questo pezzo di software e' il client di un sistema client/server che forma la spina dorsale del DNS. Il resolver non funziona da solo, deve essere configurato, la configurazione del resolver e' in genere fatta dal SysAdmin che configura la macchina o indirettamente dal server DHCP che il SysAdmin ha configurato.

Il Resolver ha una serie di risorse da usare per cercare di "risolvere" (appunto) un nome in un indirizzo IP. In genere i resolver hanno a disposizione uno o piu' servers DNS ed eventualmente uno o piu' file hosts. Il (o i) file Hosts sono semplicemente dei files nella macchina client (non sul server) che vengono usati direttamente. Un file hosts potrebbe essere una roba del tipo:

127.0.0.1	localhost

Il nome (o i nomi) a destra viene "risolto" nell'indirizzo IP scritto a sinistra. Il file hosts e' in genere il primo che il resolver usa, se non trova niente, il resolver passa ad interrogare il primo dei server DNS della sua lista. Il resolver invia quindi una richiesta al primo DNS domandandogli in sostanza "quale e' il server 'www.ilmiobelsito.it'?" (sorvoliamo per il momento su cose come ricorsione, iterazione e redirezione che vedremo dopo), il server DNS se conosce la risposta la fornisce immediatamente al client, se non conosce la risposta prende il dominio che e' stato cercato e lo "spezza" nei suoi componenti: www - ilmiobelsito - it e comincia dalla parte piu' a destra. Va' quindi a domandare ad uno dei Root Servers "quale server gestisce il dominio 'it'?", si piglia la risposta e va' a domandare a quel server "chi e' che gestisce il dominio 'ilmiobelsito.it'?", prende quella risposta e va' a domandare a quel server "chi e' il server che gestisce 'www.ilmiobelsito.it'?". Ed a quel punto ha finito, ha la risposta cercata e puo' comunicarla al client.

Per evitare di ripetere ogni volta tutta la trafila, il nostro DNS probabilmente mettera' l'informazioni in memoria e la terra' li' per un po', cosi' se riceve un'altra richiesta analoga ha gia' la risposta. Questo meccanismo e' denominato caching. Ovviamente, ogni tanto e' necessario che la cache venga ripulita, onde evitare di fornire una informazione oramai vecchia e priva di validita'.

Questa semplice ('nzomma) storiella ha probabilmente fatto venire in mente all'attento lettore diverse domande. Per prima cosa, come fa' il nostro server DNS a sapere chi sono i "Root Servers" e che roba sono? Allora, i Root Servers sono i servers (plurale) che hanno informazioni riguardo tutti i server che gestiscono i domini di primo livello, cioe' quelli a livello di nazione e cose come come .edu, .org, .net eccetera. Sono una dozzina, cambiano raramente ed i loro dati sono parte della configurazione di un server DNS ben configurato e devono essere impostati dal SysAdmin di quel server.
In effetti la manutenzione dei server DNS e' anche in parte lo stare dietro ai cambiamenti dei Root Servers. Per seconda cosa, come fa' il Root Server a sapere chi e' che gestisce il dominio .it ? Questo fa' parte della rete di accordi (anche politici) che sono mantenuti dai vari enti governativi per consentire ad internet di funzionare.
In sostanza ogni nazione ha uno o piu' enti (piu' o meno pubblici) a cui e' delegata la gestione di tutti i domini nazionali. Loro sono quelli che devono fornire ai SysAdmin dei Root Servers le informazioni e mantenerle corrette. Allo stesso modo, il gestore (proprietario) del dominio 'ilmiobelsito.it' dovra' informare questi enti di quale server e' il DNS primario (e secondario) del suo dominio. Tutto questo non e' propriamente tecnico, ma fa' parte della rete di accordi che consentono all'intero sistema di funzionare.

Come si puo' ben capire, quello che pare un sistema tutto sommato semplice, si rivela essere assai piu' complesso uno volta analizzato in dettaglio. Ed ancora non abbiamo parlato dei dettagli tecnici, ma abbiamo appena toccato un elemento fondamentale nell'intera struttura: la delegazione.

I Root Servers non gestiscono i domini nazionali, quello che fanno e' delegare la gestione dei vari domini nazionali ad altri enti e servers che fanno la stessa cosa a livello di singolo dominio, i quali potrebbero fare la stessa cosa a livello piu' basso e cosi' via.

Questo meccanismo consente ai master servers di conservare solo il minimo di informazioni necessarie al funzionamento di quel livello, ed agli altri sistemi di conservare le informazioni necessarie al loro funzionamento e cosi' via. In questo modo, un cambiamento a livello di singolo host in un dominio non deve interessare tutto il sistema ma solo un limitato numero di sistemi.

Quando si registra (si crea insomma) un nuovo dominio di solito occorre specificare quali sono i servers DNS che gestiscono tale dominio. Come minimo occorre un server. Alcuni registrars (gli enti o societa' che hanno l'autorizzazione a creare nuovi domini nei rispettivi domini nazionali) pretendono direttamente due (o piu') DNS per sicurezza.

E qui' introduciamo un altro concetto molto importante: quello di Zona.

Un singolo dominio puo' essere costituito da piu' Zone. Una Zona altro non e' che una parte di un dominio. Come minimo un dominio ha una zona, e puo' anche essere tutto li'. Ma se il dominio diviene complesso puo' essere spezzato in diverse zone e diversi DNS possono essere assegnati a diverse zone facenti parte dello stesso dominio.

Di solito il DNS per un dominio gestisce al minimo DUE zone. Per esempio, il DNS per il nostro dominio 'ilmiobelsito.it' gestisce la zona 'ilmiobelsito.it' (che corrisponde al dominio stesso) e la zona X.Y.Z.in-addr.arpa che e' quella che effettua la mappatura inversa (indirizzo IP - nome host) per il suo dominio.
Se il dominio ha hosts in diverse sottoreti, altre zone X.y.z.in-addr.arpa possono essere aggiunte per avere la mappatura completa nome-indirizzo per le varie sottoreti.
A che serve l'avere una mappa "inversa" indirizzo - nome host? Alcuni servizi cercano di aumentare la sicurezza del sistema pretendendo che questa mappatura sia corretta. In effetti, il vantaggio in termini di sicurezza e' quasi nullo, ma e' meglio che niente.

Nella nostra breve storiella di sopra, il nostro server DNS (quello contattato dal nostro client) ha fatto tutto il lavoro di gambe correndo da un server all'altro per darci la risposta. Questo e' un esempio di richiesta ricorsiva.

Ma non e' il solo modo di funzionamento per un server. Un server potrebbe per esempio accettare solo richieste iterative.

Quando un server riceve una richiesta iterativa l'unica cosa che deve fare e' fornire la migliore risposta che gia' conosce.

Se ritorniamo al nostro esempio di prima, quello che il nostro server DNS ha ricevuto e' una richiesta recursiva, quello che lui ha fatto e' tradurre tale richiesta in una serie di richieste iterative ad altri servers, non ha chiesto a nessuno "fai il mio lavoro per me", invece ha domandato solo cose che gli altri servers avrebbero dovuto sapere immediatamente ed ha usato le risposte per fare altre domande fino ad avere la risposta finale.

Una richiesta iterativa richiede meno risorse da parte del server DNS per essere eseguita, se il DNS non conosce la risposta si limita a non fornirla.

Una alternativa all'intero sistema e' la redirezione (forwarding). Nel caso della redirezione il server fornisce la risposta se la conosce gia' (e' nella cache o fa' parte delle Zone che sono gestite da quel server), se non la conosce riportera' la domanda ad uno o piu' server "superiori".

La redirezione e' solitamente usata per suddividere il carico tra diversi servers in una azienda o ISP per evitare di avere diversi servers tutti svolgere tutto il lavoro ogni volta, ricordiamoci che ogni volta che un server risponde ad una domanda la risposta viene tenuta in cache per un certo tempo, se un server risponde quasi sempre allo stesso genere di richieste, dopo un po' la possibilita' che la risposta sia in cache e' abbastanza elevata ed il server non deve domandare a nessuno.

Ritorniamo a parlare della Cache. La Cache e' usata da tutti i DNS per velocizzare le operazioni di ricerca ed evitare di rifare delle domande di cui si conoscono gia' le risposte.

Ma e' ovvio che non e' possibile sempre e solo ritornare le risposte che sono nella cache: potrebbero essere vecchie e non piu' valide. Come decidere?

Il DNS vede e provvede. Ad ogni informazione che un server fornisce e' attaccata una scadenza, denominata TTL = Time To Live. Questo TTL e' il tempo (in secondi) dopo il quale la risposta e' da considerare scaduta e non piu' valida.

Il Server tiene in cache le sue informazioni in funzione del TTL che riceve dal server che ha fornito l'informazione. Quando il TTL "scade", l'informazione viene cancellata dalla cache ed al prossimo "giro" verra' ri-domandata.

Quando dovrebbe essere il TTL? Dipende! In molti casi il ttl di "default" e' di 86400 secondi, cioe' 1 giorno. Se la vostra zona e' piuttosto "statica" e non succede molto, potreste ipotizzare un TTL anche piu' lungo. Viceversa, se siete in fase di grandi ristrutturazione ed avete servers che entrano ed escono ad ogni ora, potreste volere un TTL molto piu' breve.

Se un server gestisce una o piu' zone si definisce Autoritativo per quelle zone. In genere e' possibile avere piu' server Autoritativi per le zone, in effetti e' una buona pratica averne almeno due, in modo che se uno dei due ha dei problemi, il secondo sia disponibile a prendersi carico della situazione.

Quello che si fa di solito e' di avere uno dei server configurato come Master (o primario) ed un altro server configurato come Slave (o secondario).

Il server Master e' quello su cui vengono effettuate le modifiche alle zone quando si verificano. Il server provvedera' ad inviare una copia delle modifiche allo Slave in modo che i dati sui due server siano sempre coerenti.

Il software DNS (server quindi) piu' usato e' ISC BIND (https://www.isc.org/software/bind).

Bind e' distribuito con praticamente tutte le versioni di Unix e Linux esistenti. Si basa su un semplice file di configurazione e su diversi files per contenere le Zone e la definizione dei Root Servers.

Bind puo' essere usato in diversi modi, la modalita' piu' semplice e' come caching e forwarding server, quindi senza avere nessuna zona autoritativa, Bind si limitera' a redirigere tutte le richieste verso altri DNS (quelli forniti dal vostro ISP o dalla vostra ditta in genere) ed a mantenere una cache locale di richieste.

Bind puo' essere anche usato come server di caching e basta, quindi senza usare nessun server per la redirezione ma svolgendo tutto il lavoro di suo, per fare cio' ovviamente vi serve un elenco dei Root Servers e dovrete tenerlo aggiornato (non che cambino molto spesso, l'ultimo aggiornamento e' del dicembre 2008...). Tutte le distribuzioni di Bind contengono un file di configurazione con i Root Servers, altrimenti e' possibile ottenerne una copia aggiornata direttamente dal server FTP di Internic: ftp://ftp.internic.net/domain/named.root

Dulcis in fundo, Bind consente di avere delle Zone locali, quindi di funzionare come un vero DNS server autoritativo per una o piu' zone.

NOTA: quella che segue e' una rapidissima spiegazione dei vari tipi di records che si possono incontrare nella configurazione di un DNS. Ancora una volta, non pretendo che sia completa.

Una zona (o un dominio) e' composta in genere da molteplici host che forniscono diversi servizi.

Per definire una zona si crea una file (denominato, con molta fantasia, file della zona) che per ragioni storiche viene riferito come un "database". Questo file comincia con il definire diverse caratteristiche di default in una intestazione (header).
Nell'intestazione si specifica a quale zona si riferiscono i dati, il TTL di default, chi e' il sysadmin responsabile e cosi' via. Poi vengono i vari records che specificano i vari servizi.

Uno dei primi servizi da definire e', ovviamente, chi sono i DNS per la zona. Per fare cio' si usano i record NS.

NS	gort.soft-land.org.

Si possono specificare piu' DNS per una singola zona, quale dei DNS sara' usato dai resolver dipende dall'implementazione del resolver stesso e non e' possibile saperlo a priori.

Uno dei record piu' comuni e' quello che mette in relazione un nome host con il suo indirizzo IP: il record A (address=indirizzo). Un record A per un host e' tipicamente una cosa come la seguente:

gort IN A	82.94.182.66

Ricordiamoci che una zona si riferisce ad un dominio, quindi se il dominio relativo e' (per esempio) "soft-land.org", il nome completo dell'host sara' "gort.soft-land.org", ma nel file non e' necessario specificarlo per intero perche' il dominio e' sottinteso. E' anche possibile assegnare ad un host piu' indirizzi IP. Quando richiesto il DNS fornira' tutti gli indirizzi IP per quell'host, quale degli indirizzi verra' usato dal client dipende da come e' implementato il resolver nel client. Questo meccanismo e' usato a volte per ottenere un certo bilanciamento di risorse tra diversi servers che forniscono lo stesso servizio. Quindi non c'e' niente di strano nel domandare per UN server e vedersi ritornare piu' indirizzi IP.

In alcuni casi, un singolo host esegue piu' compiti. In tal caso non e' anormale che, a seconda del suo compito, si presenti ed appaia con un nome diverso. Lo stesso server potrebbe fare da server web (www) e da server ftp. E' possibile ovviamente indicare due diversi record A con lo stesso indirizzo IP e nomi diversi. Ma se il server e' sempre uno solo e' anche possibile semplificare la cosa utilizzando un alias, cioe' un nome diverso per lo stesso server. Un Alias si specifica con un record di tipo CNAME:

gort 	IN	A	82.94.182.66
www 	IN	CNAME	gort.soft-land.org.

In questo caso abbiamo definito un alias 'www' che "punta" allo stesso server 'gort'. Notare cha abbiamo usato il nome completo del server al posto dell'indirizzo IP con un '.' finale. Il punto finale indica che quello e' il nome completo e che il dominio "sottinteso" non deve essere aggiunto all'host. Senza quel punto finale il DNS ritornerebbe un nome come 'gort.soft-land.org.soft-land.org'.

La posta elettronica si basa su una serie di servers di posta, che vengono usati in sequenza. Quando inviamo una mail ad un dominio il nostro server di posta deve inviare la mail ad uno dei servers che sono preposti per ricevere la posta per quel dominio. Come fa' a sapere quale e' il server giusto? Usando il DNS ovviamente. Un dominio puo' avere piu' servers di posta di cui, di solito, uno e' considerato il primario.

Per specificare il servizio di posta nel DNS si utilizzano i record MX. Un record MX per un dominio appare come:

MX	10	gort.soft-land.org.
MX	20	backup.soft-land.org.

Il numero che appare specifica la "priorita'" del server. Numeri piu' bassi hanno una priorita' maggiore. Quindi questo ci dice che il server prioritario e' gort.soft-land.org e poi viene backup.

Per ultimo, abbiamo i record che identificano la relazione opposta ai record A, cioe' quelli che collegano un indirizzo IP con il suo host. Questi record sono in genere inseriti nella zona in-addr.arpa e non nella zona "normale" dove sono gli altri records. Il record in questione e' il record PTR (pointer).

Supponiamo che voi abbiate installato un DNS e vogliate verificarne il funzionamento, o supponiamo che voi stiate cercando di capire come il DNS funziona. La cosa migliore da fare e' provare a fare qualche domanda e vedere che cosa ricevete come risposta.

Lo strumento principale per domandare ad un DNS e' (nel mondo Unix) DIG.

Capita spessissimo che io legga domande su vari gruppi di discussione in cui la persona che domanda parte in quarta cercando di capire perche' "la rete non funziona" ed ignora la cosa piu' semplice: il DNS. La prima cosa da fare e' un bel 'Dig' per vedere se il DNS che avete configurato funziona e vi ritorna dei risultati corretti. La cosa piu' importante di Dig e' che usa lo stesso resolver che e' usato da tutti gli altri programmi quindi non solo effettua un controllo sul DNS ma anche sulla configurazione del resolver della macchina. Altri strumenti, come ping o nslookup, implementano i loro resolver locali, quindi una ricerca fatta con ping o nslookup potrebbe ritornare risultati diversi da quelli corretti. Per questo motivo nslookup e' considerato deprecato per la verifica dei DNS e ping e' lo strumento sbagliato e basta.

La query piu' semplice fatta tramite Dig e' quella per ricercare un singolo host:

# dig www.soft-land.org +all

; <<>> DiG 9.4.1 <<>> www.soft-land.org +all
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6052
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.soft-land.org.             IN      A

;; ANSWER SECTION:
www.soft-land.org.      41192   IN      CNAME   gort.soft-land.org.
gort.soft-land.org.     41192   IN      A       82.94.182.66

;; Query time: 4 msec
;; SERVER: 172.31.1.1#53(172.31.1.1)

Che vor' di' sta' robba? Semplice: la prima parte dice "ricevuta risposta" e prosegue dicendo lo stato della risposta, che nel nostro caso e' NOERROR, cioe' la nostra domanda e' stata elaborata senza problemi. Notate che "senza problemi" non vuole dire che riceviamo una risposta, solo che il nostro DNS sta' funzionando.

Poi ci dice che abbiamo inviato una query ed abbiamo ricevuto 2 risposte, che il server che ci ha dato la risposta non e' autoritario (aka: non e' lui che gestisce quella zona).

Dopo di che vengono le nostre risposte. Ci dice che 'www.soft-land.org' e' in effetti un CNAME (cioe' un ALIAS) per 'gort.soft-land.org' e che 'gort.soft-land.org' ha indirizzo IP 82.94.182.66. Per ultimo viene quale e' il server DNS che ha risposto alla nostra domanda.

Ogni linea della risposta e' equivalente ad una linea del file della zona corrispondente nel server DNS. In gergo, ogni linea viene detta 'record' per analogia con i database.

Questo mi dice che il mio DNS sta' funzionando. Ma posso fare di piu'. Potrei, per esempio, domandare quale e' il DNS che e' autoritario per quella zona:

# dig -t ns soft-land.org +short
gort.soft-land.org.

L'uso di '+short' mi consente di tagliare via tutto ed avere solo la risposta. Dig mi dice che il server autoritario per quella zona e' 'gort.soft-land.org', il cui indirizzo IP lo abbiamo avuto prima. A questo punto potrei domandare direttamente a lui la stessa domanda di prima:

# dig www.soft-land.org @82.94.182.66 +all

; <<>> DiG 9.4.1 <<>> www.soft-land.org @82.94.182.66 +all
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12735
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.soft-land.org.             IN      A

;; ANSWER SECTION:
www.soft-land.org.      86400   IN      CNAME   gort.soft-land.org.
gort.soft-land.org.     86400   IN      A       82.94.182.66

;; AUTHORITY SECTION:
soft-land.org.          86400   IN      NS      gort.soft-land.org.

;; Query time: 14 msec
;; SERVER: 82.94.182.66#53(82.94.182.66)
;; WHEN: Wed Jul 29 20:53:02 2009
;; MSG SIZE  rcvd: 84

Come vediamo abbiamo ricevuto piu' o meno la stessa risposta ma con 'Authority: 1', il che significa che si', lui e' autoritario per quella zona.

Dig puo' anche domandare per altri tipi di records, per fare cio' basta specificare che tipo di record vogliamo con l'opzione -t del comando. Per esempio per domandare dei server di posta di un dominio:

# dig -t mx soft-land.org
;; ANSWER SECTION:
soft-land.org.          86400   IN      MX      10 gort.soft-land.org.

;; ADDITIONAL SECTION:
gort.soft-land.org.     86400   IN      A       82.94.182.66

Questo ci dice che il dominio ha un solo server di posta e ci dice quale e'. Per saperne di piu' consiglio vivamente di leggere le RFC relative al DNS e di consuntare la documentazione di Dig.

Quando il DNS fu' inventato internet era ancora relativamente giovane e di dimensioni limitate, ma quando le cose superano una certa dimensione, si verificano dei problemi. Problemi per lo piu' legati alla sicurezza del sistema. Purtroppo, come moltissimi dei protocolli e dei meccanismi inventati nell'eta' d'oro di internet, il DNS non e' progettato con la sicurezza in mente, e' progettato per essere rapido, semplice ed efficiente. E questo puo' comportare dei problemi.

Che problemi di sicurezza puo' comportare un DNS? Voglio dire, il DNS serve a tradurre un nome di host in un indirizzo IP o viceversa, che c'entra la sicurezza? La risposta e': SPAM e truffe.

Quando un utente (quindi chiunque) digita un indirizzo nel browser, il DNS ritorna l'indirizzo del server corrispondente ed il browser entra in comunicazione con tale server. Quindi, se il DNS viene "rapito" ed invece dell'indirizzo giusto fornisce un indirizzo sbagliato, il browser entrera' in comunicazione con un server diverso da quello richiesto, ma senza nessuna informazione di malfunzionamento.

Questo meccanismo di "rapimento" consente a chi lo attua di inviare un gran numero di richieste verso un server appositamente preparato a fornire informazioni false ed accuratamente preparate per convincere il "visitatore" che quello e' il sito vero e non una copia illegale. In alternativa il sito e' semplicemente un ennesimo veicolo pubblicitario (spam) o per distribuire virus e worm.

Come si effettua il "rapimento" del DNS? Vi sono fondamentalmente due modi, il primo agisce sul client (quindi sul PC che il DNS lo usa), mediante un virus o comunque l'esecuzione di codice non autorizzato si altera la configurazione del resolver sulla macchina facendola puntare ad un DNS diverso da quello regolare o si inseriscono delle voci nel file 'hosts' locale (che e' sempre usato per ragioni storiche). Il secondo modo consiste nell'usare il meccanismo di aggiornamento remoto che il DNS stesso mette a disposizione per inserire informazioni false nella memoria del DNS, questo secondo modo e' anche noto come DNS poisoning (avvelenamento).

Un altro modo di abusare del DNS per scopi illegali e' l'inviare migliaia di richieste nel tentativo di sovraccaricare il server stesso e provocarne il crash. Inviando una serie di richieste ricorsive ad un DNS si obbliga tale DNS a svolgere parecchio lavoro, inviandone tante tutte insieme il carico aumenta notevolmente.

Supponiamo di dover installare e configurare il servizio DNS per una azienda. Tale azienda richiede un DNS per l'uso interno (dai vari client) e per l'uso esterno (per consentire al resto di internet l'accesso ai vari servizi web, posta, ftp e simile). Nello stesso tempo vogliamo minimizzare i possibili problemi che possono capitare. Come procedere?

La prima cosa da fare e' verificare se e' possibile utilizzare due DNS al posto di uno. Se e' possibile e' molto meglio installare due server separati, uno per uso solo interno ed uno per uso esterno. Il DNS interno puo' essere configurato per usare il DNS esterno come forwarder o come cache. Il DNS interno sara' anche configurato in modo da consentire gli aggiornamenti alla mappa da parte del DHCP, mentre quello esterno no. In questo modo riduciamo i rischi che un attacco al DNS esterno (accessibile da internet) comprometta anche i servizi interni.

Se il vostro DNS ha degli slave, autorizzate il trasferimento delle zone solo a quegli indirizzi IP usando l'opzione allow-transfer nella definizione delle zone. Un trasferimento di zona e' una operazione piuttosto pesante ed e' anche un possibile vettore di attacco verso un DNS, rifiutare il trasferimento verso servers che non sono vostri Slave e' il primo passo per evitare un problema.

Sul server "esterno" disabilitare la recursione. In questo modo il server rispondera' alle query relative ai domini per i quali e' autoritativo, ma rispondera' picche ad eventuali richieste ricorsive inviate per sbaglio o con intenti nefasti. Abilitare la ricorsione sul server interno ma restringerla alla rete interna (ed eventualmente alla DMZ) usando le ACL. Nel server interno e' ancora meglio semplicemente accettare richieste solo dalla rete interna usando l'opzione allow-query.

Che succede se non abbiamo la possibilita' di avere due servers separati? E' possibile far funzionare due processi servers su una sola macchina, mettendo "in ascolto" il server su diversi indirizzi IP. In questo modo abbiamo due servers al prezzo di uno. Dovremmo pero' anche ricordare di creare due diverse configurazioni per il server "esterno" e per quello "interno".

Ovviamente e' anche possibile usare tecnice di virtualizzazione per avere un "server" virtuale in tutto e per tutto, ricordiamoci che un server virtuale aumenta il carico sulla macchina fisica perche' oltre al server virtuale occorre far funzionare l'OS host ed il software di virtualizzazione.

Le versioni moderne di Bind consentono il funzionamento chrooted, che vor' di'? Significa che bind funzionera' in una "gabbia" e gli verra' precluso l'accesso al filesystem del server su cui funziona con l'eccezione di una singola directory. Questo modo di funzionamento e' sempre preferibile e dato che l'unica cosa da fare per attivarla e' preprare una directory ed aggiungere una opzione all'avvio del demone, il non usarla e' semplicemente una pessima idea.

Una parola riguardo il logging. Bind tende ad essere un po' logorroico: il log si riempie rapidamente con ogni genere di informazione, soprattutto relativa a cosidetti "bogus servers". Cosa e' un "bogus"? E' un server che fornisce informazioni false (o semplicemente sbagliate). Ci possono essere molti motivi per avere informazioni sbagliate, il piu' semplice e' perche' il server e' mal configurato. In ogni caso, se si identifica un server che fornisce informazioni sbagliate con regolarita' e' molto meglio configure bind per ignorare tale server ed evitare problemi. Dopo un certo tempo, e' anche meglio ridurre il quantitativo di informazioni che vengono inserite nei log. Per fare cio' si usano le opzioni di logging di bind.

E per ultimo, cio' che dovrebbe venire per primo: aggiornamenti. Mantenete sempre il sistema aggiornato, sia dal punto di vista del software sia dal punto di vista dei Root Servers ed eventualmente dei forwarders che usate. Verificate quale e' l'ultima versione stabile di bind (se usate bind) ed installatela. Verificate di tanto in tanto quali sono i vostri forwarders (se usate forwarders) e quale e' la data di aggiornamento dei Root Servers ed applicate tutti gli aggiornamenti richiesti.

Nel 90% dei casi in cui c'e' un problema di sicurezza il baco era noto e le patch erano disponibili.

O piu' spesso "il pc non naviga" (che quando lo sento penso subito e che e'? 'na' barca?).

Se il DNS non funziona ci sono ottime probabilita' che tutto quanto cominci a funzionare male ed i sintomi sono sempre gli stessi: nessun server e' raggiungibile se viene cercato per nome ma lo e' se e' cercato per indirizzo. Quindi la prima cosa da fare e' isolare il problema: e' un problema di DNS o di networking?

Ogni macchina collegata ad una rete TCP/IP ha un gateway che e' chiamato in causa quando la macchina cerca di accedere ad un host che non appartiene alla rete locale. Per prima cosa verifichiamo quale sia questo gateway e vediamo se e' possibile contattarlo. Il sistema piu' semplice per vedere quale e' il gateway e' guardare nella configurazione di rete della macchina, un sistema meno semplice e' usare il tool netstat per interrogare il sistema di networking della macchina.

Se il gateway e' raggiungibile (un ping ritorna risposta) ci sono ottime probabilita' che il problema sia il DNS. Verificare pertanto che il resolver sia configurato correttamente. Se lo e', verificare che il DNS risponda usando DIG (non ping o nslookup). Se risponde correttamente, be', il problema e' da qualche altra parte (firewall?) ma non guardate il DNS perche' non e' lui.

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

14 messaggi this document does not accept new posts

Veramente un ottimo articolo Di Anonymous coward postato il 30/07/2009 16:38

Grazie!!! Di Gabriele Corrieri postato il 31/07/2009 22:11

Grazie della spiegazione Di Eugenio Dorigati postato il 31/07/2009 23:55

@ Eugenio Dorigati Di Michele Montanari postato il 02/08/2009 17:04

@ Michele Montanari Di Davide Bianchi postato il 02/08/2009 18:11

@ Davide Bianchi Di Michele Montanari postato il 02/08/2009 23:57

@ Michele Montanari Di maxxfi postato il 04/08/2009 08:16

@ maxxfi Di Michele Montanari postato il 07/08/2009 14:45

@ Michele Montanari Di Davide Bianchi postato il 07/08/2009 17:55

clap clap clap Di Riccardo Cagnasso postato il 10/08/2009 11:57

Di Vacca Anonima postato il 16/10/2012 12:21

Di Tonio postato il 16/10/2012 12:24

Di Antonio Pennino postato il 13/03/2015 11:29

Di Anonymous coward postato il 10/04/2016 10:40

14 messaggi this document does not accept new posts

Precedente Successivo

Davide Bianchi, lavora come Unix/Linux System Administrator presso una societa' di Hosting in Olanda.

Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.