+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/