In , il server dei nomi BIND (Berkeley Internet Name Domain) è già preconfigurato in modo da poter essere avviato subito dopo l'installazione. Se siete giàcollegati ad Internet ed immettete in /etc/resolv.conf l'indirizzo 127.0.0.1 come server dei nomi per localhost avrete solitamente già una risoluzione dei nomi correttamente funzionante, senza dover conoscere il DNS del provider. BIND eseguirà la risoluzione dei nomi tramite i server dei nomi root – cosa che però richiede un pò di tempo. Per ottenere una risoluzione del nome sicura ed effettiva, immettete nel file di configurazione /etc/named.conf, sotto forwarders, il DNS del provider con indirizzo IP. Se tutto è andato per il verso giusto, il server dei nomi girerà nella modalità “caching-only”. Solo dopo l'impostazione delle zone diventa un DNS a tutti gli effetti. Un esempio a riguardo è reperibile nella directory di documentazione /usr/share/doc/packages/bind/sample-config.

	Adattamenti automatici dell'allocazione dei nomi
A secondo del tipo di accesso ad Internet o ambiente di rete dato, l'allocazione dei nomi può essere adatta alla situazione attuale. A tal fine impostate la variabile MODIFY_NAMED_CONF_DYNAMICALLY nel file /etc/sysconfig/network/config su yes.

Non si dovrebbe impostare un dominio ufficiale, finché l'autorità competente – per .it si tratta dell' ITNIC non ve ne assengni uno. Anche se avete un dominio personale, amministrato da un provider, non conviene utilizzarlo, dato che BIND non inoltrerebbe richieste indirizzate a questo dominio, e il server web del provider risulterebbe irraggiungibile per il proprio dominio.

Per avviare il server dei nomi, si immette come root sulla riga di comando:

rcnamed start

Se sulla destra appare in verde “done”, named, così si chiama il processo del server dei nomi, è stato inizializzato correttamente. Sul sistema locale si potrà subito verificare se il server dei nomi funziona nel modo dovuto tramite i programmi host oppure dig. Come server di default deve venire indicato localhost con l'indirizzo 127.0.0.1. Altrimenti in /etc/resolv.conf si trova probabilmente un server dei nomi sbagliato, o questo file non esiste. Per un primo test, inserite host 127.0.0.1; questo dovrebbe funzionare in ogni caso. Se invece ricevete una comunicazione di errore, controllate, con il seguente comando, se il named è in esecuzione:

rcnamed status

Se il server dei nomi non parte o mostra qualche disfunzione, il motivo viene protocollato nella maggioranza dei casi sotto /var/log/messages.

Per usare come “forwarder” il server dei nomi del provider oppure un server dei nomi che gira all'interno della propria rete, bisogna registrarlo o registrarli nella sezione options sotto forwarders. Gli indirizzi IP utilizzati nel file Example 22.10, “Opzioni di forwarding in named.conf” sono stati scelti a caso, dovrete adattarli in base ai vostri dati effettivi.

options {
        directory "/var/lib/named";
        forwarders { 10.11.12.13; 10.11.12.14; };
        listen-on { 127.0.0.1; 192.168.0.99; };
        allow-query { 127/8; 192.168.0/24; };
        notify no;
        };

Dopo options, seguono le registrazioni per le zone, localhost, 0.0.127.in-addr.arpa e il . di type hint che dovrebbero essere comunque presenti. I file corrispondenti non dovranno essere modificati, dal momento che funzionano benissimo così come sono. Non dimenticate di porre un ; alla fine di ogni riga e di digitare correttamente le parentesi graffe. Dopo aver apportato delle modifiche al file di configurazione /etc/named.conf o ai file zona, BIND dovrà rileggerle, immettete dunque il comando rcnamed  reload. Alternativamente, riavviate il server dei nomi con il comando rcnamed  restart. E per terminare il server dei nomi, usate rcnamed stop.

Tutte le impostazioni riguardanti il server dei nomi BIND devono venire eseguite nel file /etc/named.conf. Anche i dati delle zone, cioè i nomi degli host, gli indirizzi IP, etc. per i domini da amministrare, devono venire archiviati in file separati nella directory /var/lib/named. Trattateremo questo tema più avanti.

L' /etc/named.conf si suddivide grosso modo in due settori: una sezione options per le impostazioni generali ed una per le registrazioni zone per i singoli domini. Inoltre è anche possibile definire un'area logging, come pure registrazioni del tipo acl (ingl.Access Control List). Le righe di commento iniziano con il carattere #, alternativamente è permesso anche //.

Il file Example 22.11, “File minimale /etc/named.conf” vi mostra un esempio di un /etc/named.conf minimalista.

options {
        directory "/var/lib/named";
        forwarders { 10.0.0.1; };
        notify no;
};

zone "localhost" in {
       type master;
       file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.0.0.zone";
};

zone "." in {
        type hint;
        file "root.hint";
};

	Ulteriori informazioni sulla configurazione BIND
Ulteriori informazioni aggiornate sulla configurazione di BIND su sono reperibili sotto /usr/share/doc/packages/bind/README.SuSE.

BIND permette di configurare in modo flessibile l'attività di logging. Normalmente, le preimpostazioni dovrebbero rilevarsi sufficienti. Il file Example 22.12, “Il logging viene soppresso” vi mostra la variante più semplice di una tale registrazione, e sopprime completamente il “logging”:

logging {
        category default { null; };
};

Dopo zone si indica il nome del dominio da amministrare, nel nostro esempio abbiamo scelto un nome a caso mio-dominio.it seguito da un in ed un blocco compreso tra parentesi graffe con le relative opzioni; cfr.Example 22.13, “L'indicazione zone per mio-dominio.it”.

zone "mio-dominio.it" in {
       type master;
       file "mio-dominio.zone";
       notify no;
};

Se si desidera definire una “zona slave”, cambia solo il type che diventa slave, e si deve indicare il server dei nomi che amministra questa zona come master (può, però, anche essere uno “slave”); cfr. file Example 22.14, “L'indicazione zone per altro-dominio.it”.

zone "altro-dominio.it" in {
        type slave;
        file "slave/altro-dominio.zone";
        masters { 10.0.0.1; };
};

Le opzioni di zone:

Servono due tipi di file zona: uno per attribuire un indirizzo IP al nome di un host e l'altro per fare l'esatto contrario, cioè allocare un nome host ad un determinato indirizzo IP.

Il punto (.) nei file zona

D'importanza fondamentale è il . nei file zona. A nomi di host senza il punto finale viene sempre aggiunta automaticamente la zona. E' quindi necessario porre un . alla fine di nomi completi, già provvisti di dominio completo, per evitare che il dominio venga aggiunto due volte. La mancanza di questo punto alla fine o la sua posizione errata sono sicuramente gli errori più comuni nella configurazione di server dei nomi.

Osserviamo ora il file zona mondo.zone responsabile per il dominio Domain mondo.all; cfr. il file Example 22.15, “File /var/lib/named/mondo.zone”.

$TTL 2D
mondo.all IN SOA      gateway  root.mondo.all.(
              2003072441  ; serial
              1D          ; refresh
              2H          ; retry
              1W          ; expiry
              2D )        ; minimum

             IN NS       gateway
             IN MX       10 sole

 gateway     IN A        192.168.0.1
             IN A        192.168.1.1
 sole        IN A        192.168.0.2
 luna        IN A        192.168.0.3
 terra       IN A        192.168.1.2
 marte       IN A        192.168.1.3
 www         IN CNAME    luna

Per la risoluzione inversa (ingl. reverse lookup) degli indirizzi IP in nomi di host si ricorre allo pseudo-dominio in-addr.arpa che viene aggiunto all'indirizzo scritto alla rovescia. Quindi, 192.168.1 diventa 1.168.192.in-addr.arpa.

 $TTL 2D
 1.168.192.in-addr.arpa. IN SOA gateway.mondo.all. root.mondo.all. (
                         2003072441     ; serial
                         1D              ; refresh
                         2H              ; retry
                         1W              ; expiry
                         2D )            ; minimum

                         IN NS           gateway.mondo.all.

1                     IN PTR          gateway.mondo.all.
2                     IN PTR          terra.mondo.all.
3                     IN PTR          marte.mondo.all.

Il trasferimento di zone tra le diverse versioni di BIND di solito non dovrebbe creare dei problemi.

Grazie alle “Transaction SIGnatures” (TSIG) si realizza una transazione sicura. Vengono utilizzate delle chiavi di transazione (ingl. transaction keys) e firme di transazione (ingl. transaction signatures). Nella seguente sezione spiegheremo come generarle ed utilizzarle.

Una transazione sicura è richiesta per la comunicazione tra server e l'aggiornamento dinamico dei dati di zona. Il controllo degli accessi basato su chiave offre maggior sicurezza rispetto ad un controllo basato sugli indirizzi IP.

Con il seguente comando potete generare una chiave di transazione (per avere ulteriori informazioni si veda la pagina di manuale di dnssec-keygen:

dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2

Il risultato sono due file che per esempio portano il seguente nome:

Khost1-host2.+157+34265.private
Khost1-host2.+157+34265.key

La chiave è contenuta in entrambi i file (p.es. ejIkuCyyGJwwuN3xAteKgg==). In seguito Khost1-host2.+157+34265.key dovrebbe venir copiato in modo sicuro (p.es. con scp) su host remoti e lì essere inserito in /etc/named.conf per realizzare una comunicazione sicura tra host1 e host2:

key host1-host2. {
  algorithm hmac-md5;
  secret "ejIkuCyyGJwwuN3xAteKgg=="
};

	Permessi di accesso di /etc/named.conf
Assicuratevi che i permessi di accesso per /etc/named.conf rimangono limitati; il valore di default è 0640 per root ed il gruppo named; alternativamente potete archiviare la chiave in un file protetto ed includerlo di seguito.

Affinché sul server host1 venga utilizzata la chiave per host2 con l'indirizzo esempio 192.168.2.3 il file /etc/named.conf sul server deve contenere:

server 192.168.2.3 {
   keys { host1-host2. ;};
};

Il file di configurazione di host2 deve essere adattato di conseguenza.

Oltre alle ACL che si basano sugli indirizzi IP e area degli indirizzi si dovrebbero aggiungere delle chiavi TSIG per avere delle transazioni sicure; ecco un esempio:

allow-update { key host1-host2. ;};

Per ulteriori informazioni consultate nel manuale di amministrazione di BIND (BIND Administrator Reference Manual) la parte intitolata update-policy.

Con aggiornamento dinamico (ingl. dynamic update) si intende l'aggiunta, la modifica e l'eliminazione di registrazioni nei dati zona di un master. Questo meccanismo viene descritto nell'RFC 2136.

L'aggiornamento dinamico delle zone si configura tramite le opzioni allow-update o update-policy nelle registrazioni delle zone. Le zone che vengono aggiornate dinamicamente non dovrebbero venir impostate manualmente.

Con nsupdate le registrazioni da aggiornare vengono trasmesse al server; per la corretta sintassi si veda la pagina di manuale di nsupdate. L'aggiornamento deve avvenire assolutamente, per motivi di sicurezza, tramite transazioni sicure (TSIG); cfr. la sezione Section 22.7.7, “Transazioni sicure”.

DNSSEC (DNS Security) viene illustrato nell'RFC 2535; gli strumenti disponibili per l'utilizzo di DNSSEC sono descritti nella manuale di BIND.

Una zona per dirsi sicura deve avere una o più chiavi zona; questo tipo di chiave viene generato - come nel caso di chiavi per host - con dnssec-keygen. Ai fini della cifratura al momento si usa DSA.

Le chiavi pubbliche public keys dovrebbero essere integrate nei file zona con $INCLUDE.

Tutte le chiavi possono essere riunite in un set di chiavi tramite dnssec-makekeyset da trasmettere in modo sicuro alla zona superiore (parent zone), per essere firmati con dnssec-signkey. I file creati durante questo processo, vanno utilizzati ai fini della firma delle zone assieme a dnssec-signzone e i file generati da questo processo vanno quindi integrati in /etc/named.conf nella zona corrispondente.

Il modulo DNS di vi consente di configurare un server DNS proprio nella rete locale. Questo modulo funziona in due modi.

Rimandiamo al BIND Administrator Reference Manual che trovate sotto /usr/share/doc/packages/bind9/, nonché agli RFC ivi menzionati e alle pagine di manuale di BIND 9.