Premier Training & Business Partner Red Hat

DNS e Bind: Concetti e Configurazione Caching DNS su RHEL o CentOS

Michele Milaneschi
Ti piacerebbe diventare anche tu uno di noi e
pubblicare i tuoi articoli nel blog degli RHCE italiani?

In questo articolo parleremo del protocollo DNS e della sua implementazione tramite Bind.

bind9

Tuti noi utilizziamo i DNS durante la navigazione su internet quasi senza accorgersene e tale protocollo è di fondamentale importanza.

Ogni computer su internet possiede un indirizzo numerico chiamato indirizzo IP, che identifica in modo unico solo quella macchina.

Quando digitiamo nel browser l’URL www.miosito.it, il DNS del nostro ISP, o del server tramite cui accediamo ad internet, traduce il nome del sito nel corrispondente indirizzo IP 64.26.63.33 e viceversa.

Ogni nome di dominio è separato da alcuni punti che vanno dal piu specifico a quello meno specifico:

Il dominio radice, o dominio di root contiene un elenco di tutti i server DNS dei dominio di primo livello ( it, com, net, gov, … ).

Un DNS che copre un dominio di primo livello conosce gli indirizzi di tutti i DNS di secondo livello sottostanti ad esso.
Questo significa che un DNS .it conosce tutti i domini del tipo qualche-cosa.it

Un DNS di secondo livello di una certa organizzazione conosce a sua volta tutte le macchine il cui nome Internet finisce con qualche-cosa.it.

Tra queste, molto spesso troviamo la macchina “www”, che identifica il server Web della società che ha il ruolo di rispondere alle richieste di pagine html.

Ogni dominio viene amministrato da un organizzazione. Ad esempio il dominio .it è amministrato dalla Registration Authority Italiana.

Andiamo a introdurre il concetto di Zona e di Record:

Per Zona intendiamo un sottodominio amministrato dalla stessa autorità:
Praticamente si tratta di una parte di spazio costituita da un dominio con i suoi sottodomini, sotto la stessa gestione amministrativa.

Se prendiamo il dominio example.org:

org. è il Dominio di Primo Livello
example.org. è la zona delegata dalla zona superiore org.

Per motivi di ridondanza che vedremo successivamente ogni zona viene replicata su più server.


Per Record intendiamo tutte le informazioni relative alla zona
coperta da un server DNS che vengono memorizzate in un file sotto forma di Resource Record (RR).

Vediamo di capire quali sono i campi che formano la struttura:

TTL: Time-To-Live, Indica in secondi quanto tempo questo Record rimane in cache

SOA: Start of Authority, un Record dove risiedono i dati autoritativi per questo dominio ed alcuni dati amministrativi.

IN: Indica il sistema Internet.

A: Indica che il Record contiene l’indirizzo IP per il dominio specificato. Comunemente usato nella risoluzione del nome

CNAME: Record Canonical Name, viene usato per indicare un nome di alias per il dominio.

MX: Indica un host che gestisce la posta per il dominio.

NS: Indica i server DNS per il dominio specificato.

PTR: Usato per associare un indirizzo IP al nome del dominio specificato. Usato nella risoluzione inversa ( “in-addr.arpa” )

Tra i Record sopra citati poniamo l’attenzione sul Record NS ( name server ):

Vi pongo un quesito:

Perchè facendo un nslookup sul dominio extraordy.com ricevo come risposta il messaggio “Risposta da un Server non di fiducia”( da un sistema Microsoft ) o “Non Autoritativo” ( da un sistema Linux ) ??

nsloo

Non dobbiamo forse fidarci??? E invece ci possiamo fidare!!!!

Ogni volta che registriamo un dominio i DNS associati sono i DNS che l’azienda fornisce di default per ogni suo dominio.

Questi DNS vengono chiamati DNS Autoritativi o Name Server dell’azienda perchè contengono le informazioni per quel dominio e sono loro i diretti responsabili che rispondono ad ogni singola richiesta ( web, mail, ftp ecc ).

Questa cosa si rispecchia quando si fa un nslookup dove il messaggio che ci da di default è: “Risposta da un server non di fiducia”.
Questo perchè i DNS che noi utilizziamo ( in questo caso quelli di google, ma poterbbero essere benissimo anche quelli forniti dal nostro ISP ) non sono autoritativi per quel dominio che andiamo ad interrogare ossia non usiamo i Name Server dell’azienda ( DNS Autoritativi) quindi la risposta che arriva al nostro server DNS ( o quello del nsotro ISP o altri ) è una sorta di: “mi hanno detto che è cosi ma non sono sicuro al 100%”

Impostando i DNS Autoritativi o Name Server per la risoluzione di quel dominio non ci darà più il messaggio di prima.

nsloo2

Ricordiamo che in genere è obbligatorio avere almeno 2 server DNS: Uno Master e uno Slave.

IL DNS Master possiede le informazioni relative al dominio e ogni qualvolta che si vuole fare una modifica come per esempio l’introduzione di un terzo livello aggiorna le sue informazioni agli Slave.

Possiamo avere più DNS Master e ogni modifica effettuata su un DNS Master come un cambio di IP deve essere fatta manualmente anche sugli altri Master, mentre per gli Slave si aggiornano automaticamente.

Oppure Potremmo avere un server DNS che ci fa da Caching DNS:
Si tratta di un Server che non gestisce direttamente la conversione di nomi di host in indirizzi IP, ma fa sempre riferimento a altri server.

Il ruolo di questo Server è di memorizzare le risposte che gli giungono per poter effettuare le interrogazioni successive più velocemente.

Questo fa si che per le volte successive che viene fatta una interrogazione se il Server sa gia la risposta non deve fare tutta la trafila delle interrogazioni ai Root DNS, ma viene fornita subito la risposta limitando cosi anche il traffico generato.

Detto questo andiamo a implementare il nostro Server DNS tramite Bind per la configurazione come Caching DNS.

Procediamo con l’installazione:

 yum install -y bind bind-utils

bind1

Avviamo il Servizio:

 service named start

Andiamo a modificare il file /etc/resolv.conf inserendo come localhost il dominio di cui la macchina fa parte ed eliminando dei possibili DNS precedentemente configurati.

Il dominio lo ricaviamo tramite il comando:

 hostname -d

domin

Andiamo cosi a modificare il file /etc/resolv.conf:

domin2

A questo punto procediamo alla configurazione di Bind editando il file /etc/named.conf:

 nano /etc/named.conf
  • Vogliamo che tutti i client della nostra rete possano usufruire del Server DNS
  • Inoltre vogliamo che le richieste dns vengano risolte tramite i server DNS di Google per esempio.

Per fare questo aggiungiamo in listen-on il nostro indirizzo IP, su allow-query inseriamo l’indirizzo di identificazione della nostra rete, inoltre inseriramo il parametro forward only e infine aggiungiamo la voce forwarders con accanto i DNS di Google.

Il parametro forward only fa si che le query vengano risolte solamente dai DNS specificati sul parametro forwarders.

bind2

Riavviamo il Servizio che ci darà l’OK se la configurazione è corretta:

 service named restart

Per vedere il suo effettivo utilizzo andiamo ad usare il comando dig:

 dig www.msn.it

bind3

Ci vengono fornite una serie di informazioni tra cui in fondo vediamo che il server di riferimento è 127.0.0.1 sulla porta 53.
Questo significa che stiamo utilizzando il nostro Server DNS per la risoluzione degli host

Proviamo a ridare il comando:

 dig www.msn.it

bind4 E come vediamo la Query viene risolta in maniera molto più veloce, ciò significa che il Server DNS ha memorizzato la risoluzione dell’host nel corrispondente IP e quindi la risposta ci viene fornita in tempi nettamente inferiori. Il nostro Server DNS fa da Caching.

Per concludere vediamo alcuni parametri/comandi inerenti al Caching:

max-cache-ttl: Definisce il TTL per mantenere le richieste in cache. Il parametro viene espresso in secondi.

Questo significa che se noi impostiamo un max-cache-ttl di 10 secondi le risposte del Server DNS vengono mantenute in cache solamente per 10 secondi.

bind10s

Abbiamo in cache la risposta verso google.it e come vediamo il tempo di risposta è veloce:

bind11s

Dopo 10 secondi riproviamo a rieffettuare la query:
Dopo i 10 secondi la risposta per quella query non sarà piu presente in cache e i tempi di risposta sono molto più alti.

bind12s

Per rendersi conto delle dimensioni della cache possiamo effettuare un dump di tutte le query che si trovano sulla cache del server dns tramite il seguente comando:

 rndc dumpdb

Verrà salvato un file in /var/named/data con il nome cache_dump.db

Inoltre ricordiamo che possiamo svuotare la cache tramite un riavvio del servizio o tramite il seguente comando:

 rndc flush

Infine se vogliamo far utilizzare il nostro DNS Caching dai vari client della rete con sistemi Microsoft dobbiamo andare nelle Proprietà del Protocollo TCP/IP della nostra Connessione di Rete e inserire come DNS l’indirizzo IP del Server che in questo caso è 192.168.0.34

Info about author

Michele Milaneschi

RHCE Consultant