+
+Configurazione
+-----------------
+
+Vediamo alcune direttive di basi del file di configurazione ``/etc/dnsmasq.conf`` utili per la configurazione sia del DNS cache che per il DHCP server:
+
+
+domain-needed
+ Non inoltrare query ai server DNS esterni per nomi semplici (es andrea, portatile, pippo) che verranno risolti solo in locale o causeranno direttamente una risposta *not found* .
+
+
+bogus-priv
+ Simile alla voce precedente ma per i reverse look-up.
+
+
+domain
+ Nome di dominio della rete da passare ai client.
+
+
+expand_hosts
+ Aggiunge il ``nome host`` ( ``/etc/hostname``) dei client al nome di dominio per qualificarli in rete, senza bisogno di dover comporre a un elenco statico di record nel file ``/etc/hosts`` o nello stesso file di configurazione di dnsmasq. Es: se un vostro client si chiama ``chrome`` e il vostro dominio ``piffa.net`` dnsmasq rendera' disponibile il campo *A* per il dominio ``chrome.piffa.net`` diretto all'ip che verra' assegnato al client.
+
+
+DHCP
+-----------
+
+Per attivare il demone DHCP di Dnsmasq basta aggiungere al file di configurazione il *range* degli IP che si vuole assegnare ai client con il *lease time* (tempo di rilascio: quanto a lungo saranno validi gli IP assegnati) espresso in ore.
+
+Si faccia *attenzione*: in una rete puo' essere presente **un solo server DHCP**, o per meglio dire qualunque server DHCP ascolta sul broadcast ``255.255.255.255`` e potrebbe rispondere a un pacchetto di richiesta DHCP. Quindi non fate partire inavvertitamente un server DHCP in una rete gia' servita e **non vi azzardate ad andare in giro con un portatile con un server DHCP attivo** nelle reti altrui. Questo vale anche per i laboratori di informatica dei corsi di reti: non fate partire il vostro server DHCP se siete collegati alla rete interna!
+
+/etc/dnsmasq.conf (riga 118)::
+
+ dhcp-range=192.168.0.20,192.168.0.50,24h
+
+DNS cache
+-----------
+
+Dnsmasq lavora di default come cache dns: inserire al file ``/etc/resolv.conf`` il nameserver localhost in cima alla lista dei *nameserver* disponibili.
+
+ nameserver 127.0.0.1
+
+
+Questo pero' potrebbe essere problematico se un altro servizio, ad esempio il DHCP client, riscrive il contenuto del file ``/etc/resolv.conf``. Per superare il problema si aggiunga (riga 20) al file di configurazione ``/etc/dhcp3/dhclient.conf`` ::
+
+ prepend domain-name-servers 127.0.0.1;
+
+Oppure potrebbe essere il nostro *PPP client* (per la connessione ADSL) a intervenire sul file ``//etc/resolv.conf``, si modifichi quindi ``/etc/ppp/peers/dsl-provider`` commentando ``usepeerdns``. Se la vostra connessione ad internet e' ADSL raramente dovreste aver bisogno di cambiare i DNS una volta impostati (a meno che non usiate un portatile!).
+
+
+Bind : DNS Autoritativo
+===========================
+
+Le soluzioni viste possono bastare per la rete locale o per fare delle prove, ma prima o poi verra' il momento in cui si e' chiamati a gestire dei domini su internet: lo standard e' da sempre *Bind* ( demone *named*), ora alla versione 9.
+
+Installare i pacchetti::
+
+ bind9
+
+DNS cache
+-------------
+
+Bind appena installato funzionera' come DNS cache: si faccia un test con un ``dig @localhost`` . Bind a differenza di Dnsmasq e' autonomo: non ha bisogno di forwardare (inoltrare) le query a un DNS esterno: queste verranno risolte direttamente da Bind partendo dai *DNS root servers*.
+
+E' comunque possibile impostare dei DNS forwarders, tipicamente i DNS server forniti dal proprio provider, per velocizzare le query:
+
+/etc/bind/named.conf.options (riga 13)::
+
+ forwarders {
+ 10.10.208.254;
+ };
+
+Nel caso si voglia usare Bind solo come server DNS cache per la propria LAN senza ospitare delle zone DNS pubbliche sara' il caso di limitare gli accessi al server alla sola LAN:
+
+/etc/bind/named.conf.options (riga 19)::
+
+ // Se il proprio server ha IP 10.10.208.254
+ // sulla rete LAN privata:
+ listen-on { 10.10.208.254; }
+
+E non si lasci il server in ascolto su uno degli eventuali indirizzi IP pubblici.
+
+Se questo non fosse possibile si puo' sempre lavorare su una *acl*:
+
+/etc/bind/named.conf ::
+
+ acl "localnet" {
+ 10.10.208.0/24 ; 127.0.0.0/8 ;
+ } ;
+
+Per poi aggiungere all'interno della stanza options la direttiva che abilita' l'entita' ``localnet``:
+
+/etc/bind/named.conf.options ::
+
+ allow-query {"localnet" ;} ;
+
+
+Ospitare una zona
+---------------------
+
+Se avete acquistato un nome di dominio e vi serve un software DNS per gestirlo Bind e' la scelta piu' diffusa. Ora vedremo come configurare una *zona* (come piffa.net) in modo che Bind sia autoritativoper questa, rispondendo alle query DNS di tutta la rete internet.
+
+
+named.conf.local
+~~~~~~~~~~~~~~~~
+
+Prima di tutti impostiamo il server bind per gestire la zona, per non fare confusione e' opportuno inserire le propie zone DNS nel file ``named.conf.local`` e non in ``named.conf``.
+
+named.conf.local::
+
+ /
+ // Do any local configuration here
+ //
+
+ // Consider adding the 1918 zones here, if they are not used in your
+ // organization
+ //include "/etc/bind/zones.rfc1918";
+
+ zone "piffa.net" {
+ type master;
+ file "/etc/bind/pz/piffa.net";
+ }
+
+type master
+ Il nostro server DNS sara' il principale, al quale poi potremo affiancare dei DNS secondari nel caso questo non sia disponibile.
+
+file "/etc/bind/pz/piffa.net"
+ Dove verranno inserite le informazioni vere e propie di questa zona.
+
+Configurazione della zona
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ora dovremo preparare il file contenente i record DNS della zona *piffa.net*, come abbiamo indicato prima questi saranno contenuti nel file ``/etc/bind/pz/piffa.net`` . Tenere le zone dentro una sottocartella e' buona abitudine, usare ``pz`` per queste e' una vecchia abitudine.
+
+piffa.net::
+
+ ; Zona per il dominio di secondo livello piffa.net
+
+ $TTL 3D ; 3 days
+ @ IN SOA ns1.piffa.net. hostmaster.piffa.net. (
+ 200905245 ; serial
+ 8H ; refresh (8 hours)
+ 2H ; retry (2 hours)
+ 4W ; expire (4 weeks)
+ 1D ; minimum (1 day)
+ )
+ ;
+ NS ns1
+ NS ns2
+ A 94.23.63.105
+ MX 10 smtp
+ TXT "Piffanet main site"
+ ;
+ ns1 A 94.23.63.105
+ ns2 A 65.98.21.97
+ zoo A 94.23.63.105
+ smtp A 94.23.63.105
+ test.piffa.net. A 94.23.63.105
+ *.piffa.net. A 94.23.63.105 ; *catch all domain
+ www CNAME zoo
+ ftp CNAME zoo
+
+
+
+All'interno di questo file si possono inserire dei commenti con il carattere ``;`` (punto-e-virgola), si faccia attenzione alla rigida sintassi: apertura e chiusura delle parentesi tonde nella parte ``IN SOA``, uso del ``punto`` finale per precisare un nome di dominio specifico (*FQDN*: Fully-qualified Domain Name) come ``test.piffa.net.`` a differenza degli altri domini di terzo livello come ``pop,imap,smtp`` .
+
+La zona inizia con una direttiva ``$TTL 3D`` (RFC 2308) che indica la durata (in questo caso tre giorni) che ogni record dovrebbe avrebbe nella cache degli altri serber DNS. Questo valore dovrebbe essere superiore a un giorno, se non modificate spesso i valori dei vostri record DNS e' consigliabile settarlo a 2/3 settimane in modo da limitare la frequenza delle query al propio server. Questo parametro puo' essere modificato per singoli record::
+
+ $TTL 3D ; 3 giorni: default se non specificato altrimenti
+ rapido 5h IN A 94.23.63.105 ; usa un TTL di 5 ore
+ lento 3w IN A 94.23.63.105 ; usa un TTL di 3 settimane
+ normale IN A 94.23.63.105 ; usa il TTL di default: 3 giorni
+
+
+Segue poi il nome della zona, indicato con la ``@`` per richiamare la zona originale precisata nel file ``named.conf.options`` . Segue il campo ``SOA``.
+
+SOA: Start of Authority Record
+`````````````````````````````````
+
+Il record SOA puo' comparire solo una volta in una zona, contiene informazioni relative all'autorita' del server DNS.
+
+ns1.piffa.net. name-server
+ primary master DNS di questo dominio.
+
+hostmaster.piffa.net. email-addr
+ email-addr: indirizzo email della persona responsabile di questa zona, il primo punto viene tradotto in una *chiocciola* ``@`` dato che questo carattere ha un'altro utilizzo all'interno di questo file. Il referente della zona **deve** essere un email valido e controllato, come consuetudine si usa ``hostmaster@dominio.tilde`` .
+
+200905245 serial number
+ Questo valore serve per indicare quando e' stato modificato questo file di configurazione, secondo il formato ``yyyymmddss``: ``yyyy`` = anno, ''mm'' = mese, ''dd'' = giorno, ''ss'' = seriale. Il seriale che deve essere sempre specificato anche per una cifra, va incrementato di una unita' nel caso vengano fatte piu' modifiche *nello stesso giorno*.
+
+8H refresh
+ Indica ai DNS secondari quanto tempo attendere per cercare di aggiornare i loro dati con il DNS master.
+
+2H retry
+ Intervallo di tempo per il DNS slave (secondario) da aspettare prima di cercare di ricontattare il *master* in caso di problemi col *refresh*.
+
+4W expire
+ Indica quando i dati dei dns secondarinon sono piu' autoritativi in caso di impossibilita' degli *slaves* di ri-aggiornarsi con il *master*. Consigliato un valore di 2/4 settimane.
+
+1D minimum
+ Questo valore indicava il TTL fino alla versione 8 di Bind, da Bind 9 e secondo la RFC2308 indica la durata del *negative caching*, quanto i resolvers (ad esempio un server dns cache) puo' mantenere un record *negativo* (che non indica la corrispondenza tra un nome di dominio e un ip, ma la non esistenza del record). Nell'uso per il negative caching viene fissato un valore massimo di 3 ore dalla RFC 2308.
+
+
+Altri campi:
+```````````````
+
+All'interno della zona possono essere utilizati vari tipi di records (RR):
+
+TXT
+ Informazioni testuali associate ad un record
+
+NS
+ Name Server della zona. Non deve essere un cname.
+
+A
+ Indirizzo ipv4 da associare al record
+
+AAA
+ Indirizzo ipv6 da associare al record
+
+CNAME
+ Canonical Name: un alias per un host: ad esempio per il dominio piffa.net possiamo settare degli alias come ``www.piffa.net, http.piffa.net, virtual.piffa.net, ftp.piffa.net, imap.piffa.net``. Comodo quando diversi alias sono sempre riferiti allo stesso ip.
+
+MX
+ Mail Exchanger: server di posta che si occupera' della posta elettronica per questo dominio.E' opportuno avere almeno un server di posta di back-up, per indicare la priorita' di un MX rispettoad un altro si usa un valore di 2 cifre: il valore piu' basso indica priorita' piu' bassa. Es: ``MX 10 smtp.piffa.net.`` per il server SMTP principale e ``MX 40 smtp2.piffa.net`` per il secondario. Non deve essere un cname.
+
+PTR
+ Reverse look-up, usato per la mappatura inversa di un indirizzo ip a una stringa identificativa dell'host. Si noti che per poter modificare questi record si deve avere *in gestione* la *zona IP*, se cosi' non fosse si dovra' chiedere al propio provider la modifica di questo record per il propio ip. Links: http://www.zytrax.com/books/dns/ch3/
+
+DNS slave
+-------------
+
+Data l'importanza del servizio DNS e' necessario avere ridondanza per i server DNS che ospitano i vostri dati: in caso di indisponibilita' del server *master* (nel caso fosse il solo a tenere i dati questo comporterebbe la *scomparsa* di tutti i servizi / host da esso seviti!) il client potrebbe contattare uno degli *slave*.
+
+Gli slave recuperano i dati dei recordos RR direttamente dal master e non sara' quindi necessario dover mantenere manualmente il file di configurazione della zona sugli slaves, ogni volta che aggiorneremo il master questi dati si propaghera' agli slaves automaticamente.
+
+Per attivare uno *slave* per la nostra zona di esempio ``piffa.net`` si inserisca nel file ``named.conf.local`` dello slave server::
+
+ zone "piffa.net" {
+ type slave;
+ file "/etc/bind/pz/piffa.net";
+ masters { 192.168.0.1; };
+ };
+
+Facendo ripartire Bind il file ``/etc/bind/pz/piffa.net`` viene creato automaticamente.
+
+Segue un estratto di ``/var/log/syslog`` al ``restart`` di ``bind9`` sullo slave::
+
+ ... slave named[2256]: zone piffa.net/IN: loaded serial 200905245
+ ... slave named[2256]: running
+ ... slave named[2256]: zone piffa.net/IN: sending notifies (serial 200905245)
+ ... slave named[2256]: client 192.168.0.1#1464: received notify for zone 'piffa.net'
+ ... slave named[2256]: zone piffa.net/IN: notify from 192.168.0.1#1464: zone is up to date
+
+.. warning::
+ Bind9 (versione 9.3 presente in Debian Lenny) richiede una esplicita autorizzazione alla notifica per lo stesso server slave, che in fase di avvio interroghera' (inviando un notify) se' stesso per valutare se i dati relativi alla zona di cui e' slave sono aggiornati. Si aggiunga quindi al file ``/etc/bind/named.conf.options`` dello slave: ``allow-notify { 192.168.0.1; };`` all'interno della stanza ``options``, in cui l'inidirizzo IP inserito e' quello dello stesso slave server.
+
+Aggiornamento dinamico: nsupdate
+----------------------------------
+
+Dalla versione 8 di Bind e' dsponibile l'utility ``nsupdate`` (disponibile nel pacchetto ``dnsutils``) per aggiornare automaticamente i record di una zona secondo il paradigma client / server ( RFC2136 ) . Posto che abbiate a disposizione un server DNS Bind on-line su un indirizzo IP fisso e un zona da gestire (che potrebbe essere anche solo la delega di un dominio di terzo livello come *casa.miodominio.net*) sara' possibile aggiornare automaticamente i record che tirano a degli indirizzi IP *pubblici ma dnamici*, come quelli spesso messi a disposizione dei provider per le connessioni ad internet residenziali, in modo da poter rendere sempre raggiungibile la vostra workstation a casa anche dopo un aggiornamento dell'ip dinamico associato alla connessione.
+
+L'auenticazione del client nsupdate che avra' la possibilita' di aggiornare il server DNS master avviene tramite *Transaction signatures* (TSIG, RFC2845) usando un algoritmo di criptazione dati asimmetrico *HMAC-MD5* : generata una coppia di chiavi sul client / nsupdate con l'utility si dovra' trasferire la chiave pubblica sul server *master*, che verra' configurato per onorare gli aggiornamenti (eliminazione e inserimento di record RR) autenticati dalla chiave privata.
+
+Configurazione client (nsupdate)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sul client, sul quale non deve essere necessariamente installato un server DNS Bind ma la sola utility ``nsupdate``, generiamo la coppia di chiavi con l'utility ``dnssec-keygen`` installabile tramite il pacchetto ``bind9utils``::
+
+ dnssec-keygen -a HMAC-MD5 -b 512 -n USER home.piffa.net.
+
+Otterremo le due chiavi ``Khome.piffa.net.+157+04331.key Khome.piffa.net.+157+04331.private``, la chiave pubblica dovra' essere resa noto al server master che ricevera' l'update dei records.
+
+Configurazione server: riconoscimento chiave
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Per rendere nota al server la chiave pubblica generata sul client si aggiunga quindi al file ``/etc/bind/named.conf`` sul server::
+ key home.piffa.net. {
+ algorithm HMAC-MD5;
+ secret "txfAkNTScANEu2V73mCeiDpXNc3pmf+7ONOoKnTKQKIZMzierSmeHjK5 Z8ntnByt/PJwv26jCIsVh8n+xzVsRw==";
+ };
+
+.. note::
+ La parte ``secret``, che potete leggere direttamente nel file \*.key della chiave genearta, e' scritto *tutto sulla stessa riga* senza ritorni a capo.
+
+
+Server: gestione dell'intera zona
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sul server modifichiamo il file di configurazione ``named.conf.local`` della zona della quale vogliamo concedere l'aggiornamento al client::
+
+ zone "piffa.net" {
+ type master;
+ file "/etc/bind/pz/piffa.net" ;
+ allow-update {
+ key home.piffa.net;
+ };
+ };
+
+Sara' necessario assicurarsi che il demone di Bind sia in grado di modificare il file ``/etc/bind/pz/piffa.net``: dato che questo file ora sara' gestito da lui si proceda a cedergli la propieta' del file::
+ chown bind /etc/bind/pz/piffa.net
+
+Altro problema che si potrebbe porre: gli orologi di sistema dei due host devono essere sincronizzati per poter valutare l'opportunita' di un aggiornamento: si consigla di installare su entrambi l'utility ``ntpdate`` e di eseguirla facendo riferimento ai time server di Debian::
+
+ apt-get install ntpdate
+ ntpdate-debian
+
+
+Ora possiamo provare dal client a effettuare l'iserimento di un record per testarne il funzionamento::
+
+ # nsupdate -k Khome.piffa.net.+157+04331.private -v
+ > server ns1.piffa.net
+ > update add home.piffa.net. 86400 A 192.168.0.2
+ > show
+ Outgoing update query:
+ ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
+ ;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
+ ;; UPDATE SECTION:
+ home.piffa.net. 86400 IN A 192.168.0.1
+
+
+ > send
+
+Per comprendere meglio l'uso dell'utility ``nsupdate`` si consiglia la lettura della relativa pagina man. Nella prima riga viene invocato il comando ``nsupdate`` impostando col flag ``-k`` la chiave privata generata precedentemente, con ``server`` si imposta quale server NS autoritario della zona (che abbiamo precedentemente configurato per ricevere gli aggiornamenti) vogliamo contattare. Alla riga sucessiva ``update`` viene aggiunto un record ``A`` per la il dominio ``home.piffa.net`` indirizzato all'IP ``192.168.0.2``, poi ``show`` mostra quanto ci si prepara a comunicare al server con il finale ``send`` .
+
+Si noti che in questo modo *l'intera zona* piffa.net e suscettibile di essere modificata dal client, che potra' eliminare e inserire qualunque record. E' possibile gestire in modo piu' granulare la zona, ad esempio concedendo al client i privilegi per gestire solo una parte della zona o i tipo di record da gestire.
+
+Automatizzare l'aggiornamento dinamico
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Nsupdate risulta comodo per tenere aggiornati i record DNS degli host connessi ad internet con indirizzi IP dinamici (pubblici) assegnati dal provider. Il client deve essere in grado di contattare autonomamente il server DNS per comunicare un cambiamento del suo ip. Vediamo innanzi tutto un primo script per nsupdate::
+
+ #!/bin/bash
+ # Diamo al demone ppp un po' di tempo per negoziare la connessione
+ # prima di leggere l'IP ottenuto
+ sleep 15
+ IPADDR=$(/sbin/ifconfig ppp0 | awk '/inet/ { print $2 } ' | sed -e s/addr://)
+
+ nsupdate -k /root/dns/Khome.piffa.net.+157+04331.private <<-EOF
+ server 192.168.0.254
+ zone home.piffa.net.
+ update delete home.piffa.net. A
+ update delete home.piffa.net. MX
+ update add home.piffa.net. 432000 A $IPADDR
+ update add home.piffa.net. 432000 MX 10 home.piffa.net.
+ show
+ send
+ EOF
+
+
+Questo script legge il valore del device di rete ``ppp0`` creato dal `pppoe` di una connessione ADSL per ottenere l'indirizzo IP ottenuto dal provider (prima di farlo aspetta 15 secondi per dare il tempo al ``pppoe`` di negoziare la connessione).Vengono poi eliminati gli esistenti valori ``A`` e ``MX`` per ``home.piffa.net`` (si noti il punto finale dopo *net*) e inseriti quelli attuali.
+
+Resta da decidere quando richiamare questo script: l'evento che causa l'assegnazione del nuovo IP in questo caso e una nuova connessione ``pppoe``, quindi sarebbe consigliabile inserire lo script nelle routine comprese in ``/etc/ppp/ip-up.d`` (si veda la documentazione di ppp), nel caso questo non desse i risultati sperati (per problemi di connessione) come via estrema si consideri di mettere lo script nella routine del demone ``cron`` in modo che venga eseguito periodicamente (ad esempio ogni giorno).
+
+
+Link suggeriti:
+----------------
+
+* DNS for Rocket Scientists http://www.zytrax.com/books/dns/
+* DNS HOWTO http://www.langfeldt.net/DNS-HOWTO/BIND-9/
+