+ <div class="section" id="dns-slave">
+ <h2><a class="toc-backref" href=
+ "#id70">6.3 DNS slave</a></h2>
+
+ <p>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 <em>master</em> (nel
+ caso fosse il solo a tenere i dati questo comporterebbe la
+ <em>scomparsa</em> di tutti i servizi / host da esso
+ seviti!) il client potrebbe contattare uno degli
+ <em>slave</em>.</p>
+
+ <p>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.</p>
+
+ <p>Per attivare uno <em>slave</em> per la nostra zona di
+ esempio <tt class="docutils literal"><span class=
+ "pre">piffa.net</span></tt> si inserisca nel file
+ <tt class="docutils literal"><span class=
+ "pre">named.conf.local</span></tt> dello slave server:</p>
+ <pre class="literal-block">
+zone "piffa.net" {
+ type slave;
+ file "/etc/bind/pz/piffa.net";
+ masters { 192.168.0.1; };
+ };
+</pre>
+
+ <p>Facendo ripartire Bind il file <tt class=
+ "docutils literal"><span class=
+ "pre">/etc/bind/pz/piffa.net</span></tt> viene creato
+ automaticamente.</p>
+
+ <p>Segue un estratto di <tt class=
+ "docutils literal"><span class=
+ "pre">/var/log/syslog</span></tt> al <tt class=
+ "docutils literal"><span class="pre">restart</span></tt> di
+ <tt class="docutils literal"><span class=
+ "pre">bind9</span></tt> sullo slave:</p>
+ <pre class="literal-block">
+... 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
+</pre>
+
+ <div class="warning">
+ <p class="first admonition-title">Avvertenza</p>
+
+ <p class="last">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 <tt class=
+ "docutils literal"><span class=
+ "pre">/etc/bind/named.conf.options</span></tt> dello
+ slave: <tt class="docutils literal"><span class=
+ "pre">allow-notify</span> <span class="pre">{</span>
+ <span class="pre">192.168.0.1;</span> <span class=
+ "pre">};</span></tt> all'interno della stanza <tt class=
+ "docutils literal"><span class="pre">options</span></tt>,
+ in cui l'inidirizzo IP inserito e' quello dello stesso
+ slave server.</p>
+ </div>
+ </div>
+
+ <div class="section" id="aggiornamento-dinamico-nsupdate">
+ <h2><a class="toc-backref" href=
+ "#id71">6.4 Aggiornamento dinamico:
+ nsupdate</a></h2>
+
+ <p>Dalla versione 8 di Bind e' dsponibile l'utility
+ <tt class="docutils literal"><span class=
+ "pre">nsupdate</span></tt> (disponibile nel pacchetto
+ <tt class="docutils literal"><span class=
+ "pre">dnsutils</span></tt>) 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 <em>casa.miodominio.net</em>) sara'
+ possibile aggiornare automaticamente i record che tirano a
+ degli indirizzi IP <em>pubblici ma dnamici</em>, 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.</p>
+
+ <p>L'auenticazione del client nsupdate che avra' la
+ possibilita' di aggiornare il server DNS master avviene
+ tramite <em>Transaction signatures</em> (TSIG, RFC2845)
+ usando un algoritmo di criptazione dati asimmetrico
+ <em>HMAC-MD5</em> : generata una coppia di chiavi sul
+ client / nsupdate con l'utility si dovra' trasferire la
+ chiave pubblica sul server <em>master</em>, che verra'
+ configurato per onorare gli aggiornamenti (eliminazione e
+ inserimento di record RR) autenticati dalla chiave
+ privata.</p>
+
+ <div class="section" id="configurazione-client-nsupdate">
+ <h3><a class="toc-backref" href=
+ "#id72">6.4.1 Configurazione client
+ (nsupdate)</a></h3>
+
+ <p>Sul client, sul quale non deve essere necessariamente
+ installato un server DNS Bind ma la sola utility
+ <tt class="docutils literal"><span class=
+ "pre">nsupdate</span></tt>, generiamo la coppia di chiavi
+ con l'utility <tt class="docutils literal"><span class=
+ "pre">dnssec-keygen</span></tt> installabile tramite il
+ pacchetto <tt class="docutils literal"><span class=
+ "pre">bind9utils</span></tt>:</p>
+ <pre class="literal-block">
+dnssec-keygen -a HMAC-MD5 -b 512 -n USER home.piffa.net.
+</pre>
+
+ <p>Otterremo le due chiavi <tt class=
+ "docutils literal"><span class=
+ "pre">Khome.piffa.net.+157+04331.key</span>
+ <span class=
+ "pre">Khome.piffa.net.+157+04331.private</span></tt>, la
+ chiave pubblica dovra' essere resa noto al server master
+ che ricevera' l'update dei records.</p>
+ </div>
+
+ <div class="section" id=
+ "configurazione-server-riconoscimento-chiave">
+ <h3><a class="toc-backref" href=
+ "#id73">6.4.2 Configurazione server:
+ riconoscimento chiave</a></h3>
+
+ <dl class="docutils">
+ <dt>Per rendere nota al server la chiave pubblica
+ generata sul client si aggiunga quindi al file
+ <tt class="docutils literal"><span class=
+ "pre">/etc/bind/named.conf</span></tt> sul
+ server::</dt>
+
+ <dd>
+ <dl class="first last docutils">
+ <dt>key home.piffa.net. {</dt>
+
+ <dd>algorithm HMAC-MD5; secret
+ "txfAkNTScANEu2V73mCeiDpXNc3pmf+7ONOoKnTKQKIZMzierSmeHjK5
+ Z8ntnByt/PJwv26jCIsVh8n+xzVsRw=="; };</dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <div class="note">
+ <p class="first admonition-title">Nota</p>
+
+ <p class="last">La parte <tt class=
+ "docutils literal"><span class=
+ "pre">secret</span></tt>, che potete leggere
+ direttamente nel file *.key della chiave genearta, e'
+ scritto <em>tutto sulla stessa riga</em> senza ritorni
+ a capo.</p>
+ </div>
+ </div>
+
+ <div class="section" id="server-gestione-dell-intera-zona">
+ <h3><a class="toc-backref" href=
+ "#id74">6.4.3 Server: gestione
+ dell'intera zona</a></h3>
+
+ <p>Sul server modifichiamo il file di configurazione
+ <tt class="docutils literal"><span class=
+ "pre">named.conf.local</span></tt> della zona della quale
+ vogliamo concedere l'aggiornamento al client:</p>
+ <pre class="literal-block">
+zone "piffa.net" {
+ type master;
+ file "/etc/bind/pz/piffa.net" ;
+ allow-update {
+ key home.piffa.net;
+ };
+};
+</pre>
+
+ <dl class="docutils">
+ <dt>Sara' necessario assicurarsi che il demone di Bind
+ sia in grado di modificare il file <tt class=
+ "docutils literal"><span class=
+ "pre">/etc/bind/pz/piffa.net</span></tt>: dato che
+ questo file ora sara' gestito da lui si proceda a
+ cedergli la propieta' del file::</dt>
+
+ <dd>chown bind /etc/bind/pz/piffa.net</dd>
+ </dl>
+
+ <p>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 <tt class=
+ "docutils literal"><span class="pre">ntpdate</span></tt>
+ e di eseguirla facendo riferimento ai time server di
+ Debian:</p>
+ <pre class="literal-block">
+apt-get install ntpdate
+ntpdate-debian
+</pre>
+
+ <p>Ora possiamo provare dal client a effettuare
+ l'iserimento di un record per testarne il
+ funzionamento:</p>
+ <pre class="literal-block">
+# 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
+</pre>
+
+ <p>Per comprendere meglio l'uso dell'utility <tt class=
+ "docutils literal"><span class="pre">nsupdate</span></tt>
+ si consiglia la lettura della relativa pagina man. Nella
+ prima riga viene invocato il comando <tt class=
+ "docutils literal"><span class="pre">nsupdate</span></tt>
+ impostando col <em>flag</em> <tt class=
+ "docutils literal"><span class="pre">-k</span></tt> la
+ chiave <em>privata</em> generata precedentemente, con
+ <tt class="docutils literal"><span class=
+ "pre">server</span></tt> si imposta quale server NS
+ autoritario della zona (che abbiamo precedentemente
+ configurato per ricevere gli aggiornamenti) vogliamo
+ contattare. Alla riga sucessiva <tt class=
+ "docutils literal"><span class="pre">update</span></tt>
+ viene aggiunto un record <tt class=
+ "docutils literal"><span class="pre">A</span></tt> per la
+ il dominio <tt class="docutils literal"><span class=
+ "pre">home.piffa.net</span></tt> indirizzato all'IP
+ <tt class="docutils literal"><span class=
+ "pre">192.168.0.2</span></tt>, poi <tt class=
+ "docutils literal"><span class="pre">show</span></tt>
+ mostra quanto ci si prepara a comunicare al server con il
+ finale <tt class="docutils literal"><span class=
+ "pre">send</span></tt> .</p>
+
+ <p>Si noti che in questo modo <em>l'intera</em> 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.</p>
+ </div>
+ </div>
+
projects / doc / .git / blobdiff