Repository 32bit  Forum
Repository 64bit  Wiki

Djbdns on Slackware: l'alternativa al BIND

Da Slacky.eu.
Versione delle 21:34, 9 nov 2006, autore: Chrix (Discussione | contributi)

(diff) ← Versione meno recente | Versione attuale (diff) | Versione più recente → (diff)

Indice

Introduzione

Mi è capitato di dover utilizzare su di sistema con distribuzione 9.0 Djbdns, programma alter alternativo al BIND scritto dal noto Daniel J. Bernstein. Mi sono un pò documentato e ho inizialmente pensato che gestire questo programma come dns server fosse complesso ( i DNS in genere lo sono, almeno per me!). In realtà la complessità di questo programma è dovuta alla poca documentazione e alla sua scarsa diffusione, ma in realtà il suo funzionamento è abbastanza semplice specie per chi ha dimestichezza con i programmi del noto Daniel J. Bernstein, come Qmail e daemontools ad esempio. E' vero, rispetto al Bind manca di molte features, e la sua licenza non è GPL (un limite non da poco), ma chi volesse utilizzarlo potrebbe puntare su di un aspetto non secondario, la sicurezza. Sul sito ufficiale trovate una pagina "The djbdns security guarantee" dove DJB offre in maniera esplicita 500$ a chi gli segnala dei bugs di sicurezza del programma, citto testualmente: http://cr.yp.to/djbdns/guarantee.html

"I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns."

Questo sembra essere un buon motivo, anche se in realtà credo che molto dipenda dalle abitudini e dalle necessità di chi attiva il servizio, il quale sceglie il programma che meglio conosce o che meglio si adatta alla situazione che deve affrontare. In realtà alla fine della configurazione, mi sono accorto che questo programma è abbastanza semplice (almeno per un uso standard) e molto leggero per il sistema, inoltre abbinandolo a daemontools abbiamo la sicurezza che in caso di caduta, il servizio venga rilanciato.

Un pò al pari di Qmail, altro prodotto famoso di DJB, djbdns si caratterizza per un'archetettura strutturale completamente diversa al BIND, che con un solo demone e alcuni file di configurazione fa tutto. Qui invece, come per lo stesso Qmail, abbiamo diversi programmi, ognuno per una funzione specifica. Prima di iniziare mi sono letto l'HOWTO pubblicato da Luca Morettoni

http://morettoni.net/docs/djbdns.html

indispensabile per capèirne il funzionamento, da cui ho tratto alcuni spunti per scrivere questo breve documento.

Il mio interesse era semplificare al minimo i passaggi e quindi la documentazione necessaria per arrivare a raggiungere il mio obbiettivo, ovvero quello di impostare un resolver per una rete locale che fosse anche autoritativo su di un dominio interno (zona). Autoritativo per una zona, come sappiamo, significa essere il responsabile della risoluzione finale degli host per quel dominio. Quindi il compito è duplice il primo forse più semplice del secondo, prevede un pò più di conoscenze teoriche sull'utilizzo dei DNS. Per far funzionare il tutto nella maniera più coretta, le risorse necessarie sono rappresentate da due pacchetti: djbdns e daemontools reperibili su http://cr.yp.to/djbdns.html http://cr.yp.to/daemontools.html

Daemontoools è necessario per l'avvio e la gestione del demone, consente di monitorarlo e di averlo sempre attivo. L'uso di daemontools è già descritto in questo breve documento che trovate su http://www.sistemistiindipendenti.org/modules/news/article.php?storyid=47

Installare daemontools

L'istallazione di daemontools è semplice dopo aver scompattato il pacchetto basta eseguire

root@box:/usr/src/admin/daemontools-0.76# ./package/install

In pratica daemontools fa partire in modalità "respawn" dall'inttab il programma svscanboot (per tutti i run level), il quale a sua volta esegue e controlla il programma svscan. Quest'ultimo analizza il contenuto della directory /service, che viene creata anch'essa sul sistema all'atto dell'installazione di daemontools, e grazie al programma supervise potrà controllare i processi che abbiamo deciso di monitorare e li rieseguirà nel caso in cui questi non dovessero più essere in esecuzione. Ovviamente il fatto di utilizzare l'inittab è legato al fatto che init il padre di tutti i processi, riavvia in automatico tutti i processi che sono sotto il suo diretto controllo

SV:123456:respawn:/command/svscanboot

Questo programma controlla ogni 5 secondi le directory (link simbolici alle directory radice dei programmi da monitorare) contenute in /service che contengono, a loro volta, i file di configurazione per eseguire i vari servizi. Appena svscan trova una nuova directory e quindi un nuovo servizio da gestire, svscan lancia un nuovo processo, supervice. Ogni demone supervice esegue il servizio cui è associato e lo fa ripartire nel caos in cui questo terminasse in modo imprevisto.

Installare Djbdns

L'installazione di djbdns non è complessa, ma al pari della sua configurazione, molto diversa dal bind.

cd /usr/src
tar zxvf djbdns-1.05.tar.gz
make - compila
make setup check - installa

Gli eseguibili vengono installati in /usr/local/bin

root@box:/service# which tinydns
/usrlocal/bin/tinydns
tinydns tinydns-conf tinydns-data tinydns-edit tinydns-get

L'uso del servizio si basa sostanzialmente su due di questi eseguibili:

  • dnscache: è un DNS cache server che consente la risoluzione di domini esterni effettuandone la cache sul sistema
  • tinydns: è il DNS vero e proprio con cui poter gestire le zone di un dominio.

Il nostro obbiettivo preveda come prima cosa l'installazione di un resolver (dns cache server) in grado di fornire il servizio per i client della rete locale. Per prima cosa abbiamo installato e configurato dnscache, il programma che nel pacchetto consente di abilitare questo servizio

Installazione di Dnscache

Per prima cosa creiamo sul sistema l'utente ed il gruppo con cui girerà il DNS cache server. Questa operazione è importante e viene descritta in maiera dettagliata sull'HOWTO ufficiale

root@box:/service# groupadd dns
root@box:/service# useradd -g dns -s /bin/false -d /dev/null dnscache
root@box:/service# useradd -g dns -s /bin/false -d /dev/null dnslog

Adesso si può lanciare il dns cache server:

dnscache-conf dnscache dnslog /usr/local/etc/dnscache

Questo crea la dir /usr/local/etc/dnscache in cui vengono depositati tutti i file necessari al funzionamento del cache server.

 root@box:/usr/local/etc/dnscache# ls
env/ log/ run* seed

Per poter far partire dns cache basta sfruttare daemontolls creando il link simbolico nella directory /service

ln -s /usr/local/etc/dnscache /service

A questo punto possiamo provare una risoluzione dal nostro sistema

root@box:/usr/local/etc/dnscache/log/main# dig www.linux.it localhost
; <<>> DiG 9.2.1 <<>> www.linux.it localhost
;; QUESTION SECTION:
;www.linux.it.		IN	A
;; ANSWER SECTION:
www.linux.it	85381   	IN	CANME picard.linux.it
picard.linux.it     85381	IN	A	62.177.1.107

oppure

root@box:/usr/local/etc/dnscache/log/main# nslookup www.linux.it localhost
Server:		localhost
Address: 	127.0.0.1#53
Non-authoritative answer:
Name: www.linux.com
Address 66.35.250.170

Il nostro dns cache server funziona regolarmente per la risoluzione dei nomi esterni e può essere impostato nel file resolv.conf del nostro host locale. In questo modo comincerà a funzionare come dns cache server vero e proprio. I log delle richieste dns possono essere analizzati nella directory /usr/local/etc/dnscache/log/main Il dns in questo modo è utilizzabile solo dal localhost, ma se volessimo aprire il servizio a host esterni, ad esempio ai client della rete locale, occore effettuare l'operazione di <<external cache for your network>>, come viene definita nella documentazione ufficiale consultabile su: http://cr.yp.to/djbdns/run-cache-x.html

L'operazione è simile alla precedente, occore solo avere l'indirizzo del network verso cui effettuare l'apertura e l'indirizzo IP del server, per cui avremo:

dnscache-conf dnscache dnslog /usr/local/etc/dnscache_external 192.168.17.224

In questo caso viene anche specificato l'indirizzo IP del dns cache server per la rete locale. Ovviamente per attivare il servizio occore creare il solito link simbolico:

ln -s /usr/local/etc/dnscache_external /service

Per ultimo occore abilitare le richieste dei client della rete per cui occore creare un file

touch /usr/local/etc/dnscache_external/root/ip/192.168.17

Nella directory ip era ovviamente presente solo il file 127.0.0.1 ora invece tutti gli host del network 192.168.17 possono effettuare richieste al server dns e sfruttarne appieno le potenzialità di risolutore.


root@box:/usr/local/etc/dnscache/log/main# nslookup www.ibm.com 192.168.17.224
Server:		192.168.17.224
Address: 	192.168.17.224#53
Non-authoritative answer:
Name: www.ibm.com
Address 129.42.19.99
Name: www.ibm.com
Address 129.42.16.99
Name: www.ibm.com
Address 129.42.17.99
Name: www.ibm.com
Address 129.42.18.99

Installazione di Tinydns

La seconda necessità consiteva nel rendere il dns in grado di gestire un dominio, in pratica essere autoritario per la zona. In questo caso sitratta quindi di risolvere i nomi di host interni ad una specifica zona, operazione per cui viene utilizzato tinydns, il cui compito specifico è proprio questo. Questo programma è forse il più importante, ed è quello del pacchetto djbdns, che ci consente di svolgere pienamente le funzioni di un dns server. ovviamente di far girare tinydns e dnscache sullo stesso sistema può creare un problema dovuto al fatto che entrambi sono in ascolto sulla stessa porta, per cui è bene creare un ip alias su cui far girare tinydns. Quindi avremo:

ifconfig eth1:0 192.168.17.227 netmask 255.255.255.0

come per dnscache si crea un account specifico

useradd -g dns -s /bin/false -d /dev/null tinydns 

Il servizio tinydns viene creato con tinydns-conf in modo simile a quanto visto prima per dnscache:

tinydns-conf tinydns dnslog /usr/local/etc/tinydns 192.168.17.227

il servizio si avvia con il solito link simbolico:

ln -s /usr/local/etc/tinydns /service

I servizi attivi che dovremmo avere sono questi:

root@box:/# ps -ax | grep dns
4616 ?		S	0:00 supervise dnscache
4618 ?		S	0:00 /usr/local/bin/dnscache
6172 ?		S 	0:00 supervise dnscache_external
6174 ?		S	0:00 /usr/local/bin/dnscache
6191 ?		S	0:00 supervise tinydns

A questo punto dobbiamo costruire i nostri file di zona, un pò come avremmo fatto con il BIND. In realtà la sintassi è un pò diversa, anche se tutto sommato la logica resta quella. In più djbdns ci mette a disposizione una serie di comandi che semplificano la creazione delle nostre zone. Sotto /usr/local/etc/tinydns/root troveremo una serie di script specifici:

  • add-ns: aggiunge il record per il Name Server
  • add-host: aggiunge un host
  • add-mx: aggiunge un record MX (Mail eXchanger)
  • add-alias: aggiunge un alias per un host
  • add-childdns

proviamo ad inserire qualche host della rete

cd /usr/local/etc/tinydns/root
#Aggiungo il record per il Name Server
./add-ns .192.168.17.227 # è il Name Server
#Aggiungo un host della mia rete
./add-host server2.dominio.it 192.168.17.9
#Aggiungo un IP di un host della rete (Reversal)
./add-host .0.17.168.192.in-add.arpa 192.168.17.227
#Aggiungo un alias per un IP della mia rete
./add-alias www.dominio.it 192.168.17.9
#Compilo il file di zona
make

Il comando make da lanciare alla fine, compila il file di zona con un formato .cdb specifico di tinydns, che rende la lettura dei file di zona molto più veloce rispetto ai normali file di testo del BIND

A questo punto per poter utilizzare entrambi i servizi sul sistema ed avviare sia la risoluzione per i domini esterni che per gli host della zona interna occore far dialogare dnscache e tinydns, in modo che uno passi le query all'altro. Per fare questo occore creare i seguenti file nelle root directory di dnscache e dnscache_external, in modo che questo consulti anche il dns server che risponde sull'IP alias, nel nostro caso 192.168.17.227:

 echo 192.168.17.227 > /usr/local/etc/dnscache/root/servers/dominio.it
 echo 192.168.17.227 > /usr/local/etc/dnscache/root/servers/17.168.192.in-addr.arpa
 echo 192.168.17.227 > /usr/local/etc/dnscache_external/root/servers/dominio.it
 echo 192.168.17.227 > /usr/local/etc/dnscache_external/root/servers/17.168.192.in-addr.arpa

A questo punto occore riavviare i servizi

svc -t /service/dnscache
svc -t /service/dnscache_external
svc -t /service/tinydns

Adesso possiamo provare a risolvere gli host della nostra rete

root@box:/# nslookup -silent www.dominio.it
Server:	127.0.0.1	
Address: 	127.0.0.1#53
Non-authoritative answer:
Name: www.dominio.it
Address 192.168.17.9
root@box:/# nslookup -silent www.linux.com
Server:	127.0.0.1	
Address: 	127.0.0.1#53
Non-authoritative answer:
Name: www.linux.com
Address 66.35.250.170

Un ultimo strumento che mi sento di consigliarvi e che ho utilizzato è axfr-get, in abbinamento con tcpclient che fa parte del pacchetto ucspi-tcp ed è prelevabile da: http://cr.yp.to/ucspi-tcp.html

Questo programma consente di trasferire una zona da un server DNS (BIND) che consenta lo zone transfer, generando un file contenente le informazioni della zona, in un formato compatibile con tinydns:

root@box:/etc/tinydns/root# 	tcpclient nameserver 53 axfr-get zona_int zona_int.txt zona_int.tmp
* nameserver - sara il nameserver da cui prelevare le informazioni di zona
* zona_int - è il nome della zona di cui voglio prelevare le informazioni (host)
* zona_int.txt - conterrà le informazioni da caricare in tinydns, già nel suo formato originale.

Il file avrà un formato di questo tipo:

#Nome host:IP Host:TTL
Cpop3.dominio.it:server2.dominio.it.:86400
Cproxy.dominio.it:server2.dominio.it.:86400
Cra.dominio.it:server2.dominio.it.:86400
+rh.dominio.it:192.168.17.76:86400
Crh7.dominio.it:rh.dominio.it.:86400
+router.dominio.it:212.110.6.169:86400
+sco.dominio.it:192.168.17.61:86400
  • C -> è un Cname
  • + -> è un host da aggiungere

A questo punto per caricare le informazioni:

root@box:/usr/local/etc/tinydns/root# cat zona.txt >> data
make

Senza dover riavviare tinydns possiamo risolvere i nuovi host della zona

root@box:/etc/tinydns/root# nslookup rh
Server:	127.0.0.1	
Address: 	127.0.0.1#53
Non-authoritative answer:
Name: rh.dominio.it
Address 192.168.17.76

Anche per la diagnosi il pacchetto offre delle utility specifiche da utilizzare al posto dei classici dig e nslookup ad esempio:

  • dnsip - restituisce l'IP da un dato nome di dominio
root@box:/tmp# dnsip www.linux.it
62.177.1.107
  • dnsipq - restituisce l'IP e nome per un nome di dominio
root@box:/tmp# dnsipq www.linux.it
www.linux.it 62.177.1.107
  • dnsname - restituisce il nome per un nome per un dato IP
root@box:/tmp# dnsname 62.177.1.107
picard.linux.it
  • dnsmx - restituisce l'MX (Mail eXchanger) per il dominio richiesto
root@box:/tmp# dnsmx www.netlink.it
10 mail.netlink.it

Note

Questo breve documento può essere di aiuto per una prima installazione e per capire le funzionalità di questo programma, ma per una sua completa configurazione, onde evitare errori che possono compromettere il sistema, ricordiamo la lettura della documentazione ufficiale: http://cr.yp.to/djbdns.html

e dell'HOWTO di Luca Morettoni: http://morettoni.net/docs/djbdns.html

e anche di "Life with djbdns" by Bennett Todd: http://www.lifewithdjbdns.org dove si trovano informazioni sulle altre funzionalità di djbdns non trattata in questo breve documento

Note finali

  • Il presente documento è a semplice scopo divulgativo
  • L'autore non si assume la responsabilità di eventuali danni diretti o indiretti derivanti dall'uso dei programmi, o dall'applicazione delle configurazioni menzionate nel seguente articolo
  • I marchi citati sono di proprietà dei rispettivi proprietari e sono stati utilizzati solo a scopo didattico o divulgativo.
  • L'uso o il riutilizzo del presente articolo è liberamente consentito per scopi didattici o informativi previa citazione della fonte
  • Sono possibili errori o imprecisioni, segnalatemele a pavan@netlink.it
  • Chi volesse integrare il presente documento, può scrivere a pavan@netlink.it
Strumenti personali
Namespace

Varianti