Djbdns on Slackware: l'alternativa al BIND: differenze tra le versioni
(→Introduzione) |
(→Note finali) |
| (3 versioni intermedie di uno stesso utente non sono mostrate) | |
(Nessuna differenza)
| |
Versione attuale delle 22:34, 9 nov 2006
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
