Un server DNS e DHCP su Debian

Versioni Compatibili Tutte le versioni supportate di Debian

Introduzione

In una rete locale con un server Linux e client Windows "recenti" (quindi da Windows 2000 in poi), per far sì che le comunicazioni di rete avvengano in modo efficiente, è necessario avere un server DNS che sia in grado di risolvere i nomi host dei vari PC in rete. Linux risponde benissimo a quest'esigenza col pacchetto Bind, che è appunto il server DNS più utilizzato in ambiente Linux. Il problema però è che se abbiamo una rete abbastanza estesa e con cambi frequenti, dovremmo aggiornare a mano i record A e PTR del server DNS, cosa alquanto scomoda per ovvi motivi, senza considerare che un inserimento manuale si presta benissimo ad errori di digitazione.

Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Debian Etch/Lenny, isc-dhcp su Debian Squeeze), il quale assegnerà dinamicamente la configurazione IP ai vari host, e contestualmente aggiornerà dinamicamente i record DNS su Bind, in modo che l'intervento manuale dell'amministratore di sistema sia ridotto al minimo. Il server DNS sarà utilizzato anche per risolvere i nomi di dominio Internet, impostando uno o più forwarders da interrogare se un dominio non è stato definito sul server DNS locale.

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 seguente 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 diver tempo, anche mezz'ora.

Installazione e configurazione del server DNS

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

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).

Ipotizziamo 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:

Lenny e precedenti

Le seguenti modifiche sono necessarie solo in Lenny (o precedenti).

include "/etc/bind/named.conf.options";
// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};
zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};
include "/etc/bind/named.conf.local"

Squeeze

NESSUNA modifica necessaria:

...
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Come si vede le modifiche proposte per Lenny e precedenti non sono altro che lo standard in Squeeze (in buona sostanza si è passati da un unico file di configurazione a tre distinti).

/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.

; ---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---
;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.

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
• 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     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.

/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/24; } ;
allow-transfer { none; } ; 
allow-recursion { 127.0.0.1; 192.168.1/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.

Installazione e configurazione del server DHCP

A questo punto prendiamo in considerazione l'ipotesi di necessitare dello stesso tipo di configurazione, per esempio nel caso di una rete locale con 10 o più host oppure nel caso di utenti che devono potersi connettere a più reti, ecc.
In questo contesto, non è saggio mantenere un indirizzamento di rete con IP fissi. È sicuramente più indicato utilizzare un indirizzamento dinamico, servizio fornito da un server DHCP. Nella situazione indicata in precedenza però, i file di zona del dominio test.lan dovranno essere editati ogniqualvolta cambia l'assegnazione dell'indirizzo IP ad un host, per cui va a farsi benedire la comodità dell'utilizzo di un server DHCP; è evidente quindi che la situazione ideale consiste nell'assegnazione di indirizzi IP dinamici agli host e nel contestuale aggiornamento dinamico della corrispondenza indirizzo IP -> nome host. Per fortuna, in Linux ciò è possibile, poiché sarà il server DHCP, opportunamente configurato, ad effettuare gli aggiornamenti dinamici sul server DNS, il quale dev'essere configurato per accettare gli aggiornamenti inviati dal server DHCP. Il primo passaggio della messa in opera della configurazione appena esaminata consiste nell'installazione ed attivazione del server DHCP, senza per il momento prendere in esame l'aggiornamento dinamico del server DNS; per installare il pacchetto dhcp3, utilizzare il solito apt:

• Debian Etch/Lenny

# apt-get install dhcp3-common dhcp3-server

• Debian Squeeze

# apt-get install isc-dhcp-common isc-dhcp-server

quindi, fare una copia di salvataggio del file di configurazione di esempio, crearne uno nuovo vuoto ed editarlo:

• Debian Etch/Lenny

# mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.old
# touch /etc/dhcpd3/dhcpd.conf
# nano /etc/dhcp3/dhcpd.conf

• Debian Squeeze

# mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.old
# touch /etc/dhcp/dhcpd.conf
# nano /etc/dhcp/dhcpd.conf

Ora, aggiungere un ambito DHCP con le opzioni del caso che ci permetta di distribuire i parametri della configurazione TCP/IP ai client della LAN, operazioni che si traducono nel seguente contenuto del file dhcpd.conf:

authoritative;
server-identifier 192.168.1.1;
ignore client-updates;
subnet 192.168.1.0 netmask 255.255.255.0
        {
        range 192.168.1.100 192.168.1.150;
        range 192.168.1.200 192.168.1.250;
        option subnet-mask 255.255.255.0;
        default-lease-time 604800; # cioè una settimana
        max-lease-time 2592000; # cioè 30 giorni
        option broadcast-address 192.168.1.255;
        option routers 192.168.1.254;
        option domain-name-servers 192.168.1.1;
        option domain-name "test.lan";
        option netbios-name-servers 192.168.1.1;
        option netbios-node-type 8;
        }

# Assegnare un IP fisso ad un particolare client
host pc_fisso {
  hardware ethernet 00:0D:87:B3:AE:A6;
  fixed-address 192.168.1.150;
}

A questo punto, far partire (o ripartire) il demone dhcp3-server per attivare la configurazione:

• Debian Etch/Lenny

# /etc/init.d/dhcp3-server start

• Debian Squeeze

# /etc/init.d/isc-dhcp-server start

Configurazione del DNS Dinamico

Giunti fin qui, rimangono da configurare gli aggiornamenti dinamici del server DNS. In questo caso, come già esposto, sarà il server DHCP ad aggiornare dinamicamente il server DNS, al quale dovremo dire che sono consentiti gli aggiornamenti dinamici solamente da parte degli host coinvolti nel processo. In questo caso, ipotizzando che DNS e DHCP siano sulla stessa macchina, abiliteremo solamente localhost all'aggiornamento dinamico del server DNS, e come ulteriore misura di sicurezza, specificheremo che l'aggiornamento delle zone coinvolte avverrà solamente utilizzando una chiave segreta che viene creata automaticamente all'installazione di Bind ed il cui nome file è /etc/bind/rndc.key. Il primo passaggio consiste nel modificare il file /etc/bind/named.conf.local per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:

include "/etc/bind/rndc.key";
controls {
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};

Un'ulteriore modifica da fare al file /etc/bind/named.conf.local è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l'aggiornamento solamente tramite l'utilizzo della chiave segreta:

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

Fatto questo, far ripartire il demone bind9. Ora, rimane da configurare il server DHCP, il quale sarà incaricato di effettuare gli aggiornamenti sul server DNS, e che quindi dovrà obbligatoriamente "autenticarsi" su Bind utilizzando la chiave segreta /etc/bind/rndc.key. Ciò si traduce nell'aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf (/etc/dhcp/dhcpd.conf da Squeeze):

ddns-updates on;
update-static-leases on;    # i client con ip statico sono compresi negli aggiornamenti  
ddns-update-style interim;
ddns-domainname "test.lan.";
ddns-rev-domainname "1.168.192.in-addr.arpa.";
include "/etc/bind/rndc.key";
zone test.lan. {
        primary 192.168.1.1;
        key rndc-key;
        }
zone 1.168.192.in-addr.arpa. {
        primary 192.168.1.1;
        key rndc-key;
        }

L'ultimo passaggio consiste nel rendere la directory /etc/bind scrivibile anche per l'utente bind, in modo tale che Bind possa creare i file di zona con estensione .jnl che contengono i record DNS generati dinamicamente tramite l'aggiornamento di Bind da parte del server DHCP:

# chmod 775 /etc/bind

Verificare che anche i file db.test e db.192.168.1 siano scrivibili da bind (potrebbe succedere che uno o entrambi i file abbiano come proprietario root:bind e che i permessi di gruppo siano di sola lettura).
Ora, un riavvio del demone dhcp3-server (isc-dhcp-server da Squeeze) completerà l'opera, ed avremo una rete con i PC che prendono la configurazione IP da un server DHCP, il quale aggiorna dinamicamente il server DNS in modo tale che tutte le operazioni di risoluzione dei nomi host avvengano correttamente sull'intera rete locale. Il vantaggio di questa soluzione è l'elevata automatizzazione dei processi descritti, che comporta un intervento dell'amministratore di sistema che si limita alla configurazione iniziale ed alla normale manutenzione del server, senza dover svolgere noiosi, inutili e ripetitivi aggiornamenti manuali.

Troubleshooting Bind

Bind non riparte dopo un riavvio

Utilizzando il comando rndc reload qualche volta Bind può rifiutarsi di partire:

metaserver:/etc/bind# rndc reload
rndc: connection to remote host closed

Questo può indicare che

• il server sta usando una vecchia versione del protocollo
• l'host da cui tentiamo di connetterci non è autorizzato alla connessione a Bind
• i clock non sono sincronizzati
• la chiave non è valida

Errori in /var/log/syslog

Una volta che Bind è ripartito, con il comando /etc/init.d/bind9 restart il passo successivo è controllare il file /var/log/syslog in cerca di eventuali errori. Qui sotto proverò ad elencare i più comuni. Ricordatevi di riavviare Bind ogni volta che correggete un errore.

Missing Period in a Zone File

Questo errore indica che ci siamo dimenticati di inserire un punto . alla fine della dichiarazione del FQDN all'interno dei files:

• /etc/bind/db.test
• /etc/bind/db.192.168.1

Filename Typo

I nomi dei files delle zone creati in /etc/bind non corrispondono a quelli specificati nel file /etc/bind/named.conf.local. Dovreste trovare anche un errore come il seguente:

Jul  3 19:22:42 eyrie named[2847]: zone 1.168.192.in-addr.arp/IN: loading from master file
  /etc/bind/db.1.169.192 failed: file not found

Ignoring out-of-zone-data and 0 SOA/NS Records for Reverse DNS?

Questo è un po' criptico:

Jul  3 19:49:28 eyrie named[3028]: /etc/bind/db.1.168.192:3: ignoring out-of-zone data (raptor.loc)
Jul  3 19:49:28 eyrie named[3028]: /etc/bind/db.1.168.192:12: ignoring out-of-zone data (raptor.loc)
Jul  3 19:49:28 eyrie named[3028]: zone 1.168.192.in-addr.arp/IN: has 0 SOA records
Jul  3 19:49:28 eyrie named[3028]: zone 1.168.192.in-addr.arp/IN: has no NS records

Probabilmente uno dei files di zona non contiene le corrette dichiarazioni SOA.

Has no address records

zone 1.168.192.in-addr.arpa/IN: NS 'ns1.test.lan.1.168.192.in-addr.arpa' has no address records (A or AAAA)
zone 1.168.192.in-addr.arpa/IN: not loaded due to errors

Controllare di non aver dimenticato il punto finale nel file db.192.168.1, ovvero che ci sia scritto:

@     IN     NS     ns1.test.lan.

Turning Logging On/Off

Quando siamo alla ricerca di errori, può essere comodo abilitare temporaneamente il log di tutte le operazioni DNS sul file /var/log/syslog usando il comando:

rndc querylog 

Questo porterà alla registrazione di numerose linee come le seguenti:

Jul  3 21:25:40 eyrie named[3189]: client 192.168.1.200#32793: query: eyrie.raptor.loc IN A +
Jul  3 21:25:41 eyrie named[3189]: client 192.168.1.200#32793: query: gyrfalcon.raptor.loc IN A +

Per disabilitare il log occorre ridare il comando precedente.

Test di funzionamento

Una volta eliminati gli errori dai log possiamo testare il corretto funzionamento del server DNS, con i comandi

$ host

oppure

$ dig

Qui di seguito sono elencati alcuni problemi comuni:

Host Does not exist

Authoritative answer

gyrfalcon:~# host eyrie
eyrie.raptor.loc does not exist (Authoritative answer)

Di solito questo indica un problema con il Forward DNS, oppure che è stato dimenticato un punto finale in uno di questi files:

• /etc/bind/db.test
• /etc/bind/db.192.168.1

Try Again

eyrie:~# host eyrie
eyrie does not exist, try again

Occorre specificare il dominio di ricerca all'interno del file /etc/resolv.conf.

Diretto

caio@sempronio:~$ host sempronio
sempronio has address 67.215.65.132
Host sempronio not found: 3(NXDOMAIN) 

L'IP 67.215.65.132 è quello cui OpenDNS reindirizza in caso di errore nella risoluzione dei nomi; tale errore potrebbe quindi comparire solo se oltre ad aver errato qualcosa avete indicato tra i forwarders uno dei server di OpenDNS.
Un simile errore potrebbe essere dovuto ad un'errata definizione di sempronio nel file db.test se l'host è statico, oppure all'impossibilità di dhcpd di aggiornare il file db.test. In ogni caso consultare il file /var/log/syslog per avere maggiori informazioni.

Inverso, SERVFAIL

caio@sempronio:~$ host 192.168.1.X
Host X.1.168.192.in-addr.arpa not found: 2(SERVFAIL)

Controllare di aver definito correttamente tutti i client nel file db.192.168.1, per esempio di non aver scritto qualcosa del tipo:

X     IN     PTR     sempronio.test.lan

mancando evidentemente il punto finale, cioè sempronio.test.lan.
Nel solito file di log dovreste trovare un errore di questo tipo:

unable to add reverse map from X.1.168.192.1.168.192.in-addr.arpa. to sempronio.test.lan: timed out

Inverso, NXDOMAIN

caio@sempronio:~$ host 192.168.1.X
Host X.1.168.192.in-addr.arpa not found: 3(NXDOMAIN)

Il suddetto IP non è presente nel file db.192.168.1, nel caso di indirizzo dinamico ciò potrebbe essere dovuto o all'impossibilita di DHCP di aggiornare tale file, o alla presenza di errori di sintassi nel file che ne impediscono il caricamento o infine ad un inserimento errato da parte del server DHCP. In quest'ultimo caso potrebbe capitare di trovare un record indicato come

192.168.1.X     PTR     sempronio.test.lan.

invece di

X     PTR     sempronio.test.lan.

Se nel file dhcpd.conf è stata inclusa la riga ddns-rev-domainname "1.168.192.in-addr.arpa."; eliminatela, infatti quello che il DHCP fa è appendere 1.168.192.in-addr.arpa. a X.1.168.192. L'errore dovrebbe risultare evidente dal log, dove dovrebbe comparire la riga

added reverse map from X.1.168.192.1.168.192.in-addr.arpa. to sempronio.test.lan

quando invece quella corretta è

added reverse map from X.1.168.192.in-addr.arpa. to sempronio.test.lan

Record not found

eyrie:~# host eyrie
eyrie A record not found, server failure

Il client non sta usando il corretto server DNS. Occorre modificare il file /etc/resolv.conf oppure agire sulla configurazione di Network Manager.

Record query refused

eyrie:~# host eyrie
eyrie.raptor.loc A record query refused

Dopo aver ottenuto questo errore comparirà una linea in /var/log/syslog sul server DNS:

eyrie:~# tail /var/log/daemon.log
Jul  3 21:02:22 eyrie named[3095]: client X.X.X.X#32790: query 'eyrie.raptor.loc/A/IN' denied

Questo indica un problema con la direttiva allow-query { } in /etc/bind/named.conf.options.

Troubleshooting DHCP

dhcp3

Se sul proprio computer è configurato un bridge di rete è possibile che dhcp3-server parta prima che l'interfaccia di rete sia pronta, con conseguente errore e terminazione immediata del demone. Questo significa che avviandolo manualmente il demone partirà regolarmente.
Una possibile soluzione al problema è:

• rinominare lo script presente in /etc/rc.2 da S##dhcp3-server a K##dhcp3-server, in modo da impedirne l'avvio automatico.
• editare il file /etc/network/interfaces aggiungendo in coda all'interfaccia bridge

post-up /etc/init.d/dhcp3-server start
pre-down /etc/init.d/dhcp3-server stop

Si avrà quindi un qualcosa del tipo:

iface br0 inet static
   bridge_ports eth0 eth1
   address 192.168.1.X
   broadcast 192.168.1.255
   netmask 255.255.255.0
   gateway 192.168.1.Y
   post-up /etc/init.d/dhcp3-server start
   pre-down /etc/init.d/dhcp3-server stop

post-up avvia il demone subito dopo aver attivato l'interfaccia br0, mentre pre-down lo termina prima di disattivarla.

Riferimenti Esterni

dhcpd.conf squeeze manpage
dhcp-options squeeze manpage

Zytrax DNS open guide
Bind9, documentazione varia
Dhcp, documentazione varia

NOTE Autore: Ferdybassi Esteso da Wtf 11:52, 6 feb 2012 (CET)

---