Bind: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Bind (visualizza wikitesto)

Versione delle 21:48, 7 mag 2019

12 322 byte aggiunti ,  7 mag 2019
nessun oggetto della modifica
Nessun oggetto della modifica
Nessun oggetto della modifica
Riga 16: Riga 16:
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.
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 ===
=== Importante ===
L'ordine di risoluzione dei nomi è sempre:
L'ordine di risoluzione dei nomi è sempre:


Riga 27: Riga 27:
Si supponga che sul server DNS sia fatta l'associazione (corretta) 'IP/NOME1' e che un utente tramite il proprio file <code>hosts</code> la modifichi in 'IP/NOME2' (fittizia); se dopo tale modifica quest'utente esegue il comando <code>ping NOME2</code> egli raggiungerà correttamente e immediatamente IP. Ipotizzando ora che tale utente elimini dal proprio file <code>hosts</code> l'associazione fittizia 'IP/NOME2' e che successivamente esegua il comando <code>ping NOME1</code>, potrebbe accadere che IP risulti irraggiungibile per diverso tempo, anche mezz'ora.
Si supponga che sul server DNS sia fatta l'associazione (corretta) 'IP/NOME1' e che un utente tramite il proprio file <code>hosts</code> la modifichi in 'IP/NOME2' (fittizia); se dopo tale modifica quest'utente esegue il comando <code>ping NOME2</code> egli raggiungerà correttamente e immediatamente IP. Ipotizzando ora che tale utente elimini dal proprio file <code>hosts</code> l'associazione fittizia 'IP/NOME2' e che successivamente esegua il comando <code>ping NOME1</code>, potrebbe accadere che IP risulti irraggiungibile per diverso tempo, anche mezz'ora.


== Installazione e configurazione del server DNS ==
=== Installazione ===
Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux e le relative utilità, col comando:
<pre>
# apt-get install bind9 dnsutils
</pre>
=== 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 <code>/etc/resolv.conf</code>.<br />
Successivamente bisogna modificare il file principale di configurazione di Bind, ovvero nel caso di Lenny e precedenti <code>/etc/bind/named.conf</code>, mentre nel caso di Squeeze <code>/etc/bind/named.conf.local</code>. È 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.<br />
Sebbene in Lenny e precedenti sia possibile definire tutto nel file <code>/etc/bind/named.conf</code> in questa guida si opterà per inserire le nostre zone "locali" in un file apposito, chiamato <code>/etc/bind/named.conf.local</code> (metodologia divenuta standard in Squeeze, come già detto).
Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato <code>/etc/bind/db.test</code> ed uno chiamato <code>/etc/bind/db.192.168.1</code>, che rappresenta il file in cui inserire i record PTR ("Domain Name Pointer", quelli di ricerca inversa). Di seguito vediamo come impostare il file <code>/etc/resolv.conf</code>, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 <code>/etc/bind/named.conf</code>, ed infine esamineremo i file di zona <code>/etc/bind/db.test</code> e <code>/etc/bind/db.192.168.1</code>, che rappresentano la zona che descrive la nostra rete LAN:
==== /etc/resolv.conf ====
Per quanto riguarda il server:
<pre>
search test.lan
nameserver 127.0.0.1
</pre>
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.<br />
Nel caso di macchine linux prive di 'network-manager' (o altro applicativo equivalente) allora sarà necessario modificare <code>/etc/resolv.conf</code> manualmente come indicato sopra, ma indicando al posto di <code>127.0.0.1</code> l'indirizzo LAN del server (<code>192.168.1.1</code> nel caso di questa guida).==== /etc/bind/named.conf.local ====
<pre>
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";
};
</pre>
==== /etc/bind/db.test ====
Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo.
<pre>
$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
</pre>
===== 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.<br>
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ì:
<pre>
$TTL 7200
caio    IN    A    192.168.1.X
$TTL 86400
</pre>
===== Area 2 =====
Le linee successive indicano il '''SOA''' (Start Of Authority); il formato di questi record è il seguente:
<pre>
<domain name>.  IN  SOA  <primary nameserver>. <email address of admin>. (
                    <serial number>
                    <time to refresh>
                    <time to retry>
                    <time to expire>
                    <negative caching ttl>
)
</pre>
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:
<pre>
    <domain name>. IN NS <nameserver1>.
    <domain name>. IN NS <nameserver2>.
</pre>
'''NS''' significa '''N'''ame '''S'''erver, i quali possono essere specificati sia tramite FQDN sia con un indirizzo IP. Nel nostro caso il Name Server si chiama <code>ns1</code> e pertanto la linea diventa:
<pre>
                IN      NS      ns1.test.lan.
</pre>
Si noti che omettendo di specificare un 'name' (si veda il paragrafo sulla sintassi generale) bind userà l'ultimo specificato, in questo caso il <code>test.lan.</code> 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:
<pre>
    <full domain name>. IN A <IP address>
</pre>
===== Sintassi generale =====
Con l'esclusione dell'area 1, vale la seguente sintassi:
<pre>NAME    TTL    CLASS    RR    VARIE</pre>
* '''NAME''', che può essere:
** FQDN, per esempio <code>test.lan.</code> nel caso 'RR=NS';
** Non qualificato, per esempio <code>client</code> 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 <code>IN</code>;
* '''RR''', ovvero "DNS Resource Record", per esempio <code>A</code> o <code>NS</code>;
* '''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.: <code>$TTL 86400s</code> equivale a <code>$TTL 86400</code>, ovvero un giorno
* '''m''' = minuti = # x 60 secondi, es.: <code>$TTL 1440m</code>, ovvero un giorno
* '''h''' = ore = # x 3600 secondi, es.: <code>$TTL 24h</code>, ovvero un giorno
* '''d''' = giorni = # x 86400 secondi, es.: <code>$TTL 1d</code>, 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 <code>/etc/bind</code>, ma va creato con un editor di testo.
<pre>
;
; 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.
</pre>
Il file segue la stessa sintassi vista analizzando il file <code>db.test</code> 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
<pre>
ns1        IN    A    192.168.1.1
client    IN    A    192.168.1.3
</pre>
divenga
<pre>
1      IN      PTR    ns1.test.lan.
3      IN      PTR    client.test.lan.
</pre>
==== Altri file ====
* <code>/etc/bind/db.0</code>
* <code>db.127</code>
* <code>db.255</code>
* <code>db.empty</code>
* <code>db.local</code>
Questi file descrivono le zone locali predefinite in bind e non andrebbero toccati.
==== Riavvio del server ====
Fatta la configurazione, bisogna riavviare il demone bind9:
<pre>
# /etc/init.d/bind9 restart
</pre>
==== 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 <code>/etc/bind/named.conf.options</code> aggiungendo queste righe:
<pre>
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;
};
</pre>
all'interno della sezione principale del file:
<pre>
options {
        directory "/var/cache/bind";
...
...
...
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};
</pre>
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 <code>allow</code>, permettendo le interrogazioni DNS solo dall'interno della lan e impedendo i trasferimenti di zona.


[[Categoria:DNS e DHCP]]
[[Categoria:DNS e DHCP]]
Wtf
3 155

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/42741"

Menu di navigazione