Bind

Versioni Compatibili Tutte le versioni supportate di Debian

Gateway-Router

Sommario

Gateway (full-bridge) Firewall e NAT iptables nftables Routing Ethernet Bridging Wireless Access Point Bind DNS server ISC DHCP server DNS dinamici OpenSSH OpenVPN

Info Questa guida è essenzialmente la parte dedicata a Bind della vecchia guida "Un server DNS e DHCP su Debian", ma privata delle istruzioni relative a Lenny e dei riferimenti a Squeeze

Introduzione

Due definizioni tratte da Wikipedia dovrebbero fornire un'idea precisa e sintetica di cosa sia un server DNS e Bind, l'implementazione più diffusa del primo:

DNS

Il sistema dei nomi di dominio (in inglese: Domain Name System, DNS), è un sistema utilizzato per la risoluzione di nomi dei nodi della rete (in inglese: host) in indirizzi IP.

Bind

BIND (Berkeley Internet Name Domain, in precedenza Berkeley Internet Name Daemon) è il server DNS più usato su Internet, specialmente sui sistemi Unix e derivati, sui quali è lo standard di fatto

In poche parole un server dns è ciò che permette di contattare un qualsiasi server web digitando un indirizzo invece che il suo corrispondente indirizzo IP.
Lo scopo di questa guida è spiegare come configurare un proprio server DNS attraverso bind al fine di risolvere automaticamente gli indirizzi IP della propria LAN, non di tutto il web.

Importante

L'ordine di risoluzione dei nomi è sempre:

1. Lettura del file /etc/hosts (o C:\Windows\System32\Drivers\etc\hosts in windows).
2. Se al precedente punto non si è ottenuto quanto desiderato segue un interrogazione del server DNS primario, che ai fini di questa guida non potrà che essere il server privato dell'utente. Si noti che qualora il server primario fosse non raggiungibile verrà contattato quello secondario ove specificato; a tal proposito val la pena specificare che se il secondario è un altro server privato dell'utente, ovvero uno slave, allora sarà possibile risolvere qualsiasi nome, viceversa se pubblico evidentemente non sarà possibile risolvere nomi associati alla propria LAN (o comunque non correttamente in caso di omonimia).
3. Se anche al punto due non è stato possibile risolvere il nome, per esempio perché non associato ad un IP della propria LAN (ipotizzato naturalmente di aver configurato correttamente il tutto), allora il proprio server DNS privato inoltrerà la richiesta ad altri server DNS pubblici (opportunamente specificati nel file di configurazione).

Dalla sequenza appena descritta risulta evidente che se un utente vuole impedire la risoluzione corretta di un certo specifico nome su una certa macchina, allora è sufficiente specificare nel file hosts di quel PC una corrispondenza errata IP/NOME.
Un ultima nota: mentre in debian qualsiasi cambiamento del file hosts è istantaneo, in windows potrebbe non esserlo, come nel sottostante esempio. Si supponga che sul server DNS sia fatta l'associazione (corretta) 'IP/NOME1' e che un utente tramite il proprio file hosts la modifichi in 'IP/NOME2' (fittizia); se dopo tale modifica quest'utente esegue il comando ping NOME2 egli raggiungerà correttamente e immediatamente IP. Ipotizzando ora che tale utente elimini dal proprio file hosts l'associazione fittizia 'IP/NOME2' e che successivamente esegua il comando ping NOME1, potrebbe accadere che IP risulti irraggiungibile per diverso tempo, anche mezz'ora.

Installazione

Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux e le relative utilità, col comando:

# apt-get install bind9 dnsutils

Configurazione

A questo punto va configurato Bind in modo che possa risolvere i nomi host per il dominio che andremo a creare. Il primo passo, consiste nel dire al server Linux che la risoluzione dei nomi dev'essere delegata a se stesso, editando opportunamente il file /etc/resolv.conf.
Successivamente bisogna modificare il file principale di configurazione di Bind, ovvero nel caso di Lenny e precedenti /etc/bind/named.conf, mentre nel caso di Squeeze /etc/bind/named.conf.local. È tramite questi file che si definisce dove sono posizionati i file in cui sono definite le zone corrispondenti ai vari domini che si vogliono configurare nonché i diversi parametri in generale.
Sebbene in Lenny e precedenti sia possibile definire tutto nel file /etc/bind/named.conf in questa guida si opterà per inserire le nostre zone "locali" in un file apposito, chiamato /etc/bind/named.conf.local (metodologia divenuta standard in Squeeze, come già detto).

Si ipotizzi quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato /etc/bind/db.test ed uno chiamato /etc/bind/db.192.168.1, che rappresenta il file in cui inserire i record PTR ("Domain Name Pointer", quelli di ricerca inversa). Di seguito vediamo come impostare il file /etc/resolv.conf, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 /etc/bind/named.conf, ed infine esamineremo i file di zona /etc/bind/db.test e /etc/bind/db.192.168.1, che rappresentano la zona che descrive la nostra rete LAN:

/etc/resolv.conf

Per quanto riguarda il server:

search test.lan
nameserver 127.0.0.1 

Nel caso delle macchine client dipende, infatti per PC linux con connessioni di rete gestite attraverso 'network-manager' non è necessario effettuare alcuna modifica in quanto è lo stesso applicativo ad alterarlo in base alla configurazione della connessione in uso (si veda una guida di 'network-manager' per sapere come configurarlo). Men che meno evidentemente nel caso di client windows, dove è sufficiente editare le impostazioni della scheda di rete indicando come DNS primario il proprio server privato.
Nel caso di macchine linux prive di 'network-manager' (o altro applicativo equivalente) allora sarà necessario modificare /etc/resolv.conf manualmente come indicato sopra, ma indicando al posto di 127.0.0.1 l'indirizzo LAN del server (192.168.1.1 nel caso di questa guida).

/etc/bind/named.conf.local

zone "test.lan" {
        type master;
        file "/etc/bind/db.test";
};
zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
}; 

/etc/bind/db.test

Descrive la zona della nostra rete LAN. Non è presente nella directory /etc/bind, ma va creato con un editor di testo.

$ORIGIN .
; ---Area 1---
$TTL 86400      ; 1 day

; ---Area 2---
test.lan       IN      SOA     ns1.test.lan. hostmaster.test.lan. (
                                  2007081501 ; serial
                                  86400      ; refresh (1 giorno)
                                  28800      ; retry (8 ore)
                                  604800     ; expire (1 settimana)
                                  86400      ; minimum (1 giorno)
                                );
; ---Area 3---
                IN      NS      ns1.test.lan.

; ---Area 4---
$ORIGIN test.lan.
;NOTA: ns1 è il nome del server che funge da DNS server
ns1             IN      A       192.168.1.1
; Qui potete inserire gli IP dei client-server che hanno un IP statico
client          IN      A       192.168.1.3

Area 1

La prima linea del file specifica il TTL (Time To Live) di questa zona e indica quanto tempo deve trascorrere prima che Bind controlli i file locali per verificare eventuali cambiamenti. Il valore di default è espresso in secondi, ma potrebbe essere espresso anche secondo altre unità di tempo.
Nel caso si sia configurato DHCP per aggiornare automaticamente bind, questo oltre ad inserire nuovi record provvederà anche a dichiare nuovi valori di $TTL. Se per esempio ad un client è stato concesso un lease pari a 7200 secondi nel suddetto file il relativo record apparirà così:

$TTL 7200
caio    IN    A    192.168.1.X
$TTL 86400

Area 2

Le linee successive indicano il SOA (Start Of Authority); il formato di questi record è il seguente:

<domain name>.  IN  SOA  <primary nameserver>. <email address of admin>. (
                    <serial number>
                    <time to refresh>
                    <time to retry>
                    <time to expire>
                    <negative caching ttl>
)

dove

• domain name - indica il nome del dominio, seguito da un punto; specificando invece '@' vale quanto detto nel paragrafo dedicato alla sintassi generale.
• IN e SOA indicano che il server è un SOA e un DNS per internet
• primary nameserver - è il nome di dominio del server che stiamo installando
• email address of admin - l'email dell'amministratore del server, in cui il simbolo @ è sostituito da un .
• serial number - è il valore utilizzato dai server DNS slave per determinare se sono occorsi cambiamenti dall'ultima volta che hanno contattato il master DNS. È del tutto arbitrario (valore minimo 1, valore massimo molto grande) e nel caso di IP statici deve essere modificato manualmente dall'amministratore ogni volta che compie delle modifiche. In questa guida si è scelto un formato del tipo anno-mese-giorno-numero.
• refresh - è l'intervallo di tempo che deve trascorrere prima che un server slave ricontatti il proprio master
• retry - è il numero di tentativi di connessione che un server slave deve effettuare prima di chiudere il tentativo di aggiornamento
• expire - indica quanto tempo lo slave server deve continuare a fornire dati dopo che si è verificato un errore negli aggiornamenti da un master server
• negative caching ttl - è il periodo di tempo in cui uno slave server fornisce risposte negative alle interrogazioni

Area 3

Seguono poi le linee che indicano i Server DNS della rete, nel formato:

    <domain name>. IN NS <nameserver1>. 
    <domain name>. IN NS <nameserver2>. 

NS significa Name Server, i quali possono essere specificati sia tramite FQDN sia con un indirizzo IP. Nel nostro caso il Name Server si chiama ns1 e pertanto la linea diventa:

                IN      NS      ns1.test.lan.

Si noti che omettendo di specificare un 'name' (si veda il paragrafo sulla sintassi generale) bind userà l'ultimo specificato, in questo caso il test.lan. specificato con la precedente direttiva 'SOA'.

Area 4

Infine vengono specificati gli indirizzi delle macchine locali che posseggono un indirizzo IP statico, con la seguente sintassi:

    <full domain name>. IN A <IP address> 

Sintassi generale

Con l'esclusione dell'area 1, vale la seguente sintassi:

NAME     TTL     CLASS     RR     VARIE

• NAME, che può essere:
  • FQDN, per esempio test.lan. nel caso 'RR=NS';
  • Non qualificato, per esempio client nel caso 'RR=A';
  • @, nei soli caso 'RR=NS' e 'RR=SOA'; con questo carattere bind userà il valore specificato nella variabile $origin dell'area 1, oppure qualora non presente uno specificato nella direttiva 'zone' del file 'named.conf.local'.
  • Omesso, è potenzialmente fonte di confusione. Se 'RR=A' bind userà l'ultimo valore di NAME precedente specificato, se invece 'RR=NS' bind userà sempre l'ultimo valore di NAME precedente specificato, ma se assente bind userà quello specificato nella variabile $origin dell'area 1, oppure qualora anche'esso non presente uno specificato nella direttiva 'zone' del file 'named.conf.local'.
• TTL, generalmente omesso se si usa quello definito nell'area 1;
• CLASS, per esempio IN;
• RR, ovvero "DNS Resource Record", per esempio A o NS;
• VARIE, dipende dal parametro RR, per esempio un IP se 'RR=A'.

Misure di Tempo

In generale tutte le misure di tempo possono essere espresse come segue:

• s = secondi = # x 1 secondi, es.: $TTL 86400s equivale a $TTL 86400, ovvero un giorno
• m = minuti = # x 60 secondi, es.: $TTL 1440m, ovvero un giorno
• h = ore = # x 3600 secondi, es.: $TTL 24h, ovvero un giorno
• d = giorni = # x 86400 secondi, es.: $TTL 1d, ovvero un giorno
• w = settimane = # x 604800 secondi

Si noti che tali unità possono essere combinate, per esempio 90s = 1m30s.

/etc/bind/db.192.168.1:

Descrive la zona della nostra rete LAN. Non è presente nella directory /etc/bind, ma va creato con un editor di testo.

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns1.test.lan.       hostmaster.test.lan. (
                                2007081501   ; serial
                                604800       ; refresh
                                86400        ; retry
                                2419200      ; expire
                                604800       ; negative cache ttl
                                );
@       IN      NS      ns1.test.lan.
1       IN      PTR     ns1.test.lan.
3       IN      PTR     client.test.lan.

Il file segue la stessa sintassi vista analizzando il file db.test precedente, con l'unica differenza che nel campo 'name' deve essere indicata l'ultima parte dell'indirizzo IP (o un carattere jolly come @); si noti ad esempio come

ns1        IN     A     192.168.1.1
client     IN     A     192.168.1.3

divenga

1       IN      PTR     ns1.test.lan.
3       IN      PTR     client.test.lan.

Altri file

• /etc/bind/db.0
• db.127
• db.255
• db.empty
• db.local

Questi file descrivono le zone locali predefinite in bind e non andrebbero toccati.

Riavvio del server

Fatta la configurazione, bisogna riavviare il demone bind9:

# /etc/init.d/bind9 restart

Risoluzione di indirizzi internet

Ora il server DNS può risolvere i nomi host per il dominio test.lan presente sulla rete LAN, a condizione che gli IP indicati nel file di configurazione non cambino (da tenere presente che i valori indicati sono puramente indicativi); ciò implica che la nostra rete deve essere configurata con indirizzi IP statici, condizione accettabile se i PC non superano le 10 unità, altrimenti si deve considerare l'utilizzo di un server DHCP. Altra cosa da considerare, è che in questa situazione, Bind non riesce a risolvere i nomi di dominio Internet; per ovviare al problema, bisogna indicare a Bind uno o più server DNS pubblici che possano soddisfare le richieste che il server Linux fa per conto dei client, editando opportunamente il file /etc/bind/named.conf.options aggiungendo queste righe:

allow-query { 127.0.0.1; 192.168.1.0/24; } ;
allow-transfer { none; } ; 
allow-recursion { 127.0.0.1; 192.168.1.0/24; } ;

forwarders {
208.67.222.222;
208.67.220.220;
};

all'interno della sezione principale del file:

options {
        directory "/var/cache/bind";

...
...
...

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

In questo modo i client potranno tranquillamente risolvere sia i nomi host in LAN sia i nomi di dominio Internet.

Per aumentare il livello di protezione sono state aggiunte anche le direttive allow, permettendo le interrogazioni DNS solo dall'interno della lan e impedendo i trasferimenti di zona.

Approfondimenti

Sitografia

• Zytrax DNS open guide
  
• ISC official documentation

---

Guida scritta da: Wtf 22:27, 5 mag 2019 (CEST)	Debianized 20%
Estesa da:
Verificata da:
Verificare ed estendere la guida | Cos'è una guida Debianized