Creare una zona in BIND (Primary and Secondary Master)

Prima di leggere questo post assicuratevi di aver configurato correttamente BIND come spiegato nel tutorial Configurare il DNSServer BIND per supportare DNSSec.

Questo tutorial è una estensione del tutorial Creare una zona in BIND (Primary Master Only) con l’aggiunta del supporto a Primary (Master) a Secondary Master (Slave), e scambio delle zone tramite firma con record di firma TSIG.
Riferimenti:
http://wiki.ubuntu-it.org/Server/Dns
https://help.ubuntu.com/community/BIND9ServerHowto
http://www.cyberciti.biz/faq/unix-linux-bind-named-configuring-tsig/

Cerchiamo di capire prima cosa è TSIG.
TSIG (Transaction SIGnatures) è un meccanismo usato per garantire i messaggi DNS e fornire una comunciazione server-to-server sicura (normalmente tra server master e slave).
TSIG può proteggere i seguenti tipi di transazione tra due DNS server:

  • Zone transfer
  • Notify
  • Dynamic updates
  • Recursive query messages etc

TSIG è disponibile per BIND v8.2 e superiori. TSIG utilizza una chiave condivisa ed una one-way hash function per autenticare i messaggi DNS. TSIG è semplice e leggero.

Come funziona:

  • Ogni nameserver aggiunge un record TSIG alla sezione data dei messaggi e query DNS server-to-server.
  • Il record TSIG firma il messaggio DNS attraverso la chiave condivisa tra mittente e ricevente, provando che il messaggio non è stato alterato.
  • TSIG usa una funzione hash one-way per fornire autenticazione e integrità dei dati.

Per utilizzare la firma attraverso il record TSIG occorre innanzi tutto creare la chiave (che verrà condivisa tra master e slave). A tal fine usiamo il comando dnssec-keygen.
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST tsig
Se è la prima volta che lanciate il comando dnssec-keygen è possibile che impieghi un po’ di tempo.

Dove:

  • -a Specifica l’algoritmo di crittografia.
  • -b Specifica la dimensione della chiave.
  • -n Specifica il nametype. Il nametype può essere ZONE, HOST, ENTITY, o USER.

Quando avrà terminato il comando avrà creato due files:

~$ ls -l
-rw------- 1 lucafrosini lucafrosini     48 feb 13 11:48 Ktsig.+157+60625.key
-rw------- 1 lucafrosini lucafrosini    165 feb 13 11:48 Ktsig.+157+60625.private

Sebbene la chiave pubblica e quella privata siano equivalenti (sono generati per un algoritmo di crittografia a chiave simmetrica HMAC-MD5), il comando precedente genera comunque due file .key e .private.

~$ cat Ktsig.+157+60625.key
tsig. IN KEY 512 3 157 OTiIh3V8iuFMR+0VbZh+IQ==
~$ cat Ktsig.+157+60625.private
Private-key-format: v1.3
Algorithm: 157 (HMAC_MD5)
Key: OTiIh3V8iuFMR+0VbZh+IQ==
Bits: AAA=
Created: 20140213164808
Publish: 20140213164808
Activate: 20140213164808

Come potete vedere guardando il contenuto dei files la chiave è la stessa:
OTiIh3V8iuFMR+0VbZh+IQ==

Dobbiamo quindi informare bind di usare questa chiave per il trasferimento della zona da Master a Slave.
Sia sul Master che sullo Slave dobbiamo creare quindi un file che io ho scelto di chiamare /etc/bind/tsig.key (Ovviamente per il tutorial ne ho usata una generata appositamente quindi potete risparmiare il vostro tempo a provare attacchi al mio slave).

Il file sul Master sarà una cosa del tipo:

~$ sudo nano /etc/bind/tsig.key 
key "TRANSFER" {
          algorithm hmac-md5;
          secret "OTiIh3V8iuFMR+0VbZh+IQ==";
};
# Slave Server IP 146.48.85.93
server 146.48.85.93 {
        keys {
                TRANSFER;
    };
};
################################
# If you have 2nd slave server with IP 146.48.85.137
#server 146.48.85.137 {
#        keys {
#                TRANSFER;
#    };
#};
################################

Il file sullo Slave sarà una cosa del tipo:

~$ sudo nano /etc/bind/tsig.key 
key "TRANSFER" {
          algorithm hmac-md5;
          secret "OTiIh3V8iuFMR+0VbZh+IQ==";
};
# Master Server IP 162.252.240.26
server 162.252.240.26 {
        keys {
                TRANSFER;
    };
};

Nota: Dopo che avete copiato la chiave potete anche cancellare i due file perché non servono più a niente.

Su entrambi i server (Master e Slave) dovrete aggiungere la riga include "/etc/bind/tsig.key"; al file /etc/bind/named.conf , affinchè bind possa conoscere questa chiave.

Nota: ho usato TRANSFER come nome della chiave e tsig.key come nome del file ma potete usare quelle che più vi aggradano. Se i vostri DNS server gestiscono più domini potete usare la stessa chiave o differenziarla per dominio o addirittura differenziarla tra server diversi (se ad esempio avete un secondo Slave). È chiaro che più differenziate le chiavi e meno materiale fornite ad un potenziale attaccante.

È venuto adesso il momento di creare la zona per il nostro dominio.
Per effettuare ciò è necessario aggiungerla al file named.conf.local.
Sul Master dovremmo aggiungere una cosa del tipo:

~$ sudo nano /etc/bind/named.conf.local
zone "lucafrosini.eu" {
	type master;
	file "/var/lib/bind/lucafrosini.eu";
	allow-transfer { key TRANSFER; };
	allow-update {key TRANSFER;};
};

Sullo Slave dovremmo aggiungere una cosa del tipo:

~$ sudo nano /etc/bind/named.conf.local
zone "lucafrosini.eu" {
	type slave;
	file "/var/lib/bind/lucafrosini.eu";
	masters { 162.252.240.26; };
};

La mia scelta è stata quella di creare il file di zona lucafrosini.eu nella directory /var/lib/bind. Uso questo percorso per avere un configurazione speculare a quella del Master sullo Slave, che non dia problemi di diritti in scrittura ad apparmor.
Infatti se guardate il contenuto di /etc/bind/named.conf.local troverete la riga /var/lib/bind/** rw, questo permette a bind di scrivere in quella directory.
Ecco un estratto del file:

  # /etc/bind should be read-only for bind
  # /var/lib/bind is for dynamically updated zone (and journal) files.
  # /var/cache/bind is for slave/stub data, since we're not the origin of it.
  # See /usr/share/doc/bind9/README.Debian.gz
  /etc/bind/** r,
  /var/lib/bind/** rw,
  /var/lib/bind/ rw,
  /var/cache/bind/** rw,
  /var/cache/bind/ rw,

Quando bind parte sullo Slave sincronizza la zona con il Master. Per decidere se la zona è aggiornata o meno i server si basano su un numero seriale (come vedremo di seguito ed è per questo che è importate incrementarlo ad ogni cambiamento).

Lo Slave una volta ricevuta la zona dal Master salva la configurazione (in modo binario) sul file indicato nella configurazione. Per questo motivo è stato scelto di tenere la configurazione in /var/lib/bind/. La mia scelta è quella di avere gli stessi percorsi dei file nelle macchine che gestisco. Come specificato nel file è bene evitare di dare a bind i diritti di scrittura in /etc/bind/.
Se scegliete un percorso dove bind non può scrivere, o perché non ha i diritti su filesystem o perché non indicato in /etc/bind/named.conf.local alla partenza dello Slave avrete un errore del tipo:

Feb 13 12:10:25 europa named[5750]: dumping master file: /etc/bind/lucafrosini.eu/tmp-lbN0Ky9DWg: open: permission denied
Feb 13 12:10:25 europa kernel: [ 5448.931788] type=1400 audit(1392286225.435:82): apparmor="DENIED" operation="mknod" parent=2398 profile="/usr/sbin/named" name="/etc/bind/lucafrosini.eu/tmp-lbN0Ky9DWg" pid=5751 comm="named" requested_mask="c" denied_mask="c" fsuid=125 ouid=125

Da notare che se lo Slave non salva la zona su filesystem questo non inficia sul funzionamento di bind. Se la macchina dovesse però riavviarsi ed il Master fosse down, allora bind non saprebbe quale configurazione di zona utilizzare e non assolverebbe il suo compito.

Sullo Slave non avete necessità di creare alcun file di zona verrà generato alla sincronizzazione o verrà utilizzato l’ultimo dump effettuato da bind.

Sul Master invece dovete creare il file lucafrosini.eu nella directory /var/lib/bind/ (così come specificato in /etc/bind/named.conf.local).
~$ sudo touch /var/lib/bind/lucafrosini.eu
I permessi e la proprietà del file della zona saranno essere del tipo:
~$ ls -la /var/lib/bind/lucafrosini.eu
-rw-r--r-- 1 root root 0 nov 18 10:17 lucafrosini.eu

In questo caso bind deve solo leggere la configurazione e non deve scriverla (e così facendo anche se ci provasse non potrebbe). Molti preferiscono tenere questo file in /etc/bind sul Master ed in /var/lib/bind/ o /var/cache/bind (se riguardate il file /etc/bind/named.conf.local è anch’essa scrivibile) sullo Slave. Fate come preferite l’importante è che abbiate capito il senso di quello che fate.

A questo punto sul Master occorre editare il file per configurare la zona:
~$ sudo nano /var/lib/bind/lucafrosini.eu

;
; BIND data file for lucafrosini.eu
;
$TTL 	3600
@       IN      SOA     ns1.lucafrosini.eu. ns2.lucafrosini.eu. (
		2014021301	; serial, todays date + todays serial #
		7200		; refresh
		540		; retry
		604800		; expire
		86400 )		; minimum
;
@       IN      NS      ns1.lucafrosini.eu.
@	IN      NS      ns2.lucafrosini.eu.
ns1	IN	A	162.252.240.26
ns2     IN      A       146.48.85.93

Con il comando named-checkzone zonename filename è possibile controllare la validità di una zona.
~$ named-checkzone lucafrosini.eu /var/lib/bind/lucafrosini.eu
zone lucafrosini.eu/IN: loaded serial 2014021301
OK

Aggiungete a vostro piacimento i record relativi alla vostra zona.
Non è scopo di questo articolo spiegare i tipi di record DNS.
Un buona guida introduttiva ai tipi di record DNS (esclusi quelli DNSSEC) è https://support.google.com/a/answer/48090?hl=it
Un elenco esaustivo dei record DNS invece potete trovarlo al seguente link http://it.wikipedia.org/wiki/Tipi_di_record_DNS

A questo punto potete riavviare bind su entrambe le macchine.
~$ sudo service bind9 restart

Se vi mettete in tail su /var/log/syslog
tail -f /var/log/syslog

Sul Master vedrete una cosa del tipo:


Feb 13 12:57:35 italia named[6412]: zone lucafrosini.eu/IN: loaded serial 2014021301
Feb 13 12:57:35 italia named[6412]: zone localhost/IN: loaded serial 2
Feb 13 12:57:35 italia named[6412]: managed-keys-zone ./IN: loaded serial 48
Feb 13 12:57:35 italia named[6412]: running
Feb 13 12:57:35 italia named[6412]: zone lucafrosini.eu/IN: sending notifies (serial 2014021301)
Feb 13 12:58:15 italia named[6412]: client 146.48.85.93#58064: transfer of 'lucafrosini.eu/IN': AXFR started: TSIG transfer
Feb 13 12:58:15 italia named[6412]: client 146.48.85.93#58064: transfer of 'lucafrosini.eu/IN': AXFR ended

Sullo Slave invece vedrete una cosa del tipo:


Feb 13 12:58:15 europa named[9559]: zone lucafrosini.eu/IN: Transfer started.
Feb 13 12:58:15 europa named[9559]: transfer of 'lucafrosini.eu/IN' from 162.252.240.26#53: connected using 146.48.85.93#58064
Feb 13 12:58:15 europa named[9559]: zone lucafrosini.eu/IN: transferred serial 2014021301: TSIG 'transfer'
Feb 13 12:58:15 europa named[9559]: transfer of 'lucafrosini.eu/IN' from 162.252.240.26#53: Transfer completed: 1 messages, 28 records, 5055 bytes, 0.263 secs (19220 bytes/sec)
Feb 13 12:58:15 europa named[9559]: zone lucafrosini.eu/IN: sending notifies (serial 2014021301)

Adesso non ci resta che firmare la nostra zona e quindi aggiungere i record DNSSEC.
Per sapere come continua la lettura con il tutorial Aggiungere i record DNSSEC in una zona in BIND.

One thought on “Creare una zona in BIND (Primary and Secondary Master)

Comments are closed.