Capire i concetti di DNS autoritativo e configurare un servizio locale di tipo cache con Bind

Lo scopo di questo articolo è quello di fornire una panoramica generale sui DNS e sul loro funzionamento. Cercheremo di capire l’importanza dei DNS, descrivendo gli strumenti che vengono messi a disposizione e come utilizzarli.

L’utilizzo dei DNS risulta essenziale per la navigazione, perché permette di risolvere gli indirizzi testuali senza doversi ricordare gli indirizzi IP (vedi Wikipedia). In particolare, alla base del funzionamento dei DNS c’è il concetto di DNS Autoritativi o NameServer.

Per DNS Autoritativi intendiamo i DNS gestiti da chi ospita il nome del dominio come ad esempio un provider di hosting. Questi DNS vengono chiamati DNS Autoritativi o Name Server dell’azienda perché contengono i riferimenti per quel dominio e sono loro che rispondono ad ogni singola richiesta relativa alla risoluzione dei nomi associati ai vari servizi (web, mail, ftp, etc.).

Se dobbiamo analizzare delle configurazioni DNS, un noto strumento per effettuare delle query è rappresentato da Dig. Quanto spiegato viene messo in pratica utilizzando proprio questo comando:

michele@michele-mmul / $ dig +authority miamammausalinux.org
 
; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> +authority miamammausalinux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58635
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;miamammausalinux.org.		IN	A
 
;; ANSWER SECTION:
miamammausalinux.org.	21327	IN	A	46.4.70.156
 
;; Query time: 0 msec
;; SERVER: 192.168.100.2#53(192.168.100.2)
;; WHEN: Wed Feb 11 09:58:58 CET 2015
;; MSG SIZE  rcvd: 65

La risposta mostrata proviene da un DNS non autoritativo, lo si vede dalla riga flags dell’output, in cui la voce AUTHORITY è a 0. Questa risposta è detta “Non-authoritative answer”.

Possiamo fidarci ?

Ovviamente si, ma è interessante il motivo di questa indicazione: I DNS che utilizziamo non sono autoritativi per il dominio che andiamo ad interrogare, cioè non usiamo i Name Server dell’azienda (DNS Autoritativi) quindi la risposta che viene fornita dai nostri DNS è una sorta di:

“Qualcuno mi ha detto che è cosi ma non sono sicuro al 100%”

Per modificare il messaggio basterà effettuare la query impostando i DNS Autoritativi. Ecco come identificarli:

michele@michele-mmul / $ dig +nssearch miamammausalinux.org
SOA ns2.dominiofaidate.com. hostmaster.miamammausalinux.org. 2008102315 86400 7200 604800 86400 from server 5.144.169.178 in 3 ms.
SOA ns2.dominiofaidate.com. hostmaster.miamammausalinux.org. 2008102315 86400 7200 604800 86400 from server 85.94.212.168 in 15 ms.

Provando quindi ad eseguire la richiesta verso uno dei 2 DNS Autoritativi, in questo modo:

dig miamammausalinux.org @ns2.dominiofaidate.com

l’output del comando dig cambia sensibilmente:

; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> miamammausalinux.org @ns2.dominiofaidate.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27769
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;miamammausalinux.org.		IN	A
 
;; ANSWER SECTION:
miamammausalinux.org.	86400	IN	A	46.4.70.156
 
;; AUTHORITY SECTION:
miamammausalinux.org.	86400	IN	NS	ns1.dominiofaidate.com.
miamammausalinux.org.	86400	IN	NS	ns2.dominiofaidate.com.
 
;; ADDITIONAL SECTION:
ns2.dominiofaidate.com.	86400	IN	A	85.94.212.168
ns1.dominiofaidate.com.	86400	IN	A	5.144.169.178
 
;; Query time: 14 msec
;; SERVER: 85.94.212.168#53(85.94.212.168)
;; WHEN: Wed Feb 11 10:10:12 CET 2015
;; MSG SIZE  rcvd: 151

Il campo AUTHORITY della riga flags è ora 2. La risposta è quindi di tipo autoritativo.

Chiariti i concetti di DNS autoritativi, vediamo quindi come realizzare un server DNS che funzioni da cache, questo perché utilizzando dei DNS pubblici, a fronte di ogni richiesta di risoluzione, il nostro sistema dovrà effettuare una connessione ad internet.

La realizzazione di un server DNS permette di generare meno traffico per la risoluzione dei nomi visto che per le richieste più frequenti la risposta viene fornita nell’immediato dal nostro server. Per fare questo ci serviamo di Bind: procediamo alla sua installazione.

Per Ubuntu e derivate il comando è il seguente:

sudo apt-get install bind9 dnsutils 

Per RHEL 6 e derivate il comando è il seguente:

yum install bind bind-utils

Prima di andare a configurare il servizio dobbiamo essere sicuri di eliminare eventuali DNS configurati nel file resolv.conf configurando il dominio di ricerca che in questo caso è mmul.it

vi /etc/resolv.conf
nameserver 127.0.1.1
search mmul.it

Una volta fatto questo andiamo a editare il file relativo a Bind, esattamente named.conf:

Per ubuntu e Derivate il file è il seguente:

sudo vi /etc/bind/named.conf.option

Per RHEL 6 e derivate il file è il seguente:

vi /etc/named.conf

In questo file andremo ad impostare quali saranno i DNS per la risoluzione dei nomi e l’ip della nostra macchina:

  • IP: 192.168.0.34
  • DNS: 8.8.8.8
  • DNS2: 8.8.4.4

Inoltre diamo la possibilità a tutta la nostra rete di usufruire del server DNS:

  • RETE: 192.168.0.0/24

Editiamo il file aggiungendo le seguenti stringhe:

listen-on port 53 { 127.0.0.1; 192.168.0.34; };
allow-query	{localhost; 192.168.0.0/24; };

forward only;
forwarders { 8.8.8.8; 8.8.4.4; };

Riavviamo il demone per applicare le modifiche:

Per Ubuntu e Derivate il comando è il seguente:

sudo /etc/init.d/bind9 restart

Per RHEL 6 e Derivate il comando è il seguente:

service named restart

Non resta che eseguire un test:

michele@michele-mmul ~ $ dig www.miamammausalinux.org

; <> DiG 9.9.5-3ubuntu0.1-Ubuntu <> www.miamammausalinux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17680
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.miamammausalinux.org.	IN	A

;; ANSWER SECTION:
www.miamammausalinux.org. 12473	IN	A	46.4.70.156

;; Query time: 37 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)

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

Proviamo a rieseguire la richiesta:

michele@michele-mmul ~ $ dig www.miamammausalinux.org

; <> DiG 9.9.5-3ubuntu0.1-Ubuntu <> www.miamammausalinux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39475
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;www.miamammausalinux.org.	IN	A

;; ANSWER SECTION:
www.miamammausalinux.org. 3584	IN	A	46.4.70.156

;; Query time: 1 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)

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 funziona da cache.

Possiamo affinare il comportamento del server dns andando a impostare altri valori tra i quali il TTL (Time To Live) ossia per quanto tempo il server deve mantenere in cache la risoluzione delle richieste piuttosto che definire la dimensione della cache e altri parametri che però non sono oggetto di questo articolo. Quanto illustrato basta a rendere il nostro servizio un cache only DNS.

Tags: , ,