Documentazione

Italian DHCP & DNS Configuration HOWTO

Lorenzo Benazzi, lorenzo_benazzi-sysadmin (at) yahoo.it

v1.3 2008-10-09

Questo documento ha lo scopo di spiegare come configurare un server DNS Primario Dinamico/DHCP e un server DNS Secondario


  1. Introduzione
  2. File di configurazione per DHCP
  3. File di configurazione DNS comuni
  4. File di configurazione DNS Primario
  5. File di configurazione DNS Secondario
  6. I Root Server
  7. Rete con Samba
  8. Collegamenti

 

1. Introduzione

Il DHCP & DNS Configuration HOWTO è una guida concepita per chi voglia configurare e utilizzare BIND9 e DHCP3 su di un server unix/linux.

DHCP3 è un'implementazione del protocollo DHCP(Dynamic Host Configuration Protocol); il compito di un server DHCP è di assegnare un un indirizzo IP dinamico ad un computer collegato alla stessa rete del server.

BIND9 è un'implementazione del protocollo DNS (Domain Name System); il compito di un server DNS è di convertire i nomi delle macchine negli indirizzi IP. In pratica "mappa" i nomi agli indirizzi e viceversa. Oltre a ciò fa anche altre cose.

Per informazioni su DNS, come la teoria di funzionamento, fare riferimento a DNS HOWTO di Nicolai Langfeldt; il documento risale a dicembre 2001 però è sempre valido per chi parte sta vuole capirne il funzionamento.

1.1. Licenza

Se non specificato diversamente, il copyright dei documenti HOWTO di Linux appartiene ai loro rispettivi autori. I documenti HOWTO di Linux possono essere riprodotti e distribuiti nella totalità o in parte, su ogni mezzo fisico o elettronico, purché questo messaggio sia contenuto in tutte le copie.

è consentita e incoraggiata la ridistribuzione commerciale; tuttavia, all'autore piacerebbe ricevere informazioni su ciascuna di tali distribuzioni.

Tutte le traduzioni, lavori derivati o lavori aggregati che contengono qualsiasi documento HOWTO di Linux devono essere ricoperti da questo messaggio di copyright.

Ossia, non è possibile produrre un lavoro derivato da un HOWTO e imporre delle restrizioni addizionali alla sua distribuzione.

Eventuali eccezioni a queste regole possono essere concesse sotto particolari condizioni; si prega di contattare il coordinatore degli HOWTO di Linux.

In breve, desideriamo promuovere la diffusione di queste informazioni attraverso più canali possibile.

Tuttavia, vogliamo mantenere il copyright sui documenti HOWTO, e gradiremmo essere informati su qualsiasi intenzione di ridistribuire gli HOWTO.

Per maggiori dettagli sulla licenza fate riferimento al documento orginale della licenza LDP prelevabile all'indirizzo.

http://metalab.unc.edu/LDP/COPYRIGHT.html.

1.2. Utilità

Utilità di DHCP

  • automatizza la registrazione di alcuni dati della sottorete, come per esempio gli IP in uso e chi li sta utilizzando
  • documentare i visitatori nella rete
  • centralizza la configurazione di rete
  • facilita i cambiamenti importanti nella configurazione del protocollo IP di rete. Ciò significa che un cambiamento dei DNS o del Gatweway nella sottorete locale può essere fatto senza che l'amministratore debba riconfigurare tutte le macchine
  • Rafforza la restrizione di distribuzione degli indirizzi IP nella sottorete locale
  • Rende più facile agli utenti il passaggio da casa all'ufficio

Utilità di BIND

  • centralizza file hosts su un file di zona (o zone) su una macchina primaria (master)
  • possibilità di backup della/e zona/e su macchine secondarie (slave) in caso la primaria non sia disponibile
  • rintraccia il l'IP della macchina della quale si conosce il nome e viceversa
  • mantiene una cache locale dei nomi risolti delle macchine  internet
  • può eliminare la dipendenza dai dns dell'ISP facendo riferimento direttamente ai root-servers

BIND utilizzato in congiunzione a DHCP, permette di aggiornare automaticamente le i file di zona.


2. File di configurazione DHCP

La configurazione del DHCP è la parte più veloce, ma questo non significa più semplice.
 
#
# $Id: dhcpd.conf,v 1.2.0.0 2003/05/27 10:15:08 peloy Exp $
#
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
# ddns-update-style none;
ddns-update-style interim;

# this has to be the same key as is used in /etc/bind/named.conf
key "rndc-key" {
algorithm hmac-md5;
secret "anD24+THog0NNEFB7sW8ug==";
};

# this section describes what key to use in what zone
zone dogusdomain.lan. {
primary 192.168.0.4;
key rndc-key;
}

zone 0.168.192.in-addr.arpa. {
primary 192.168.0.4;
key rndc-key;
}

# option definitions common to all supported networks...
option domain-name "dogusdomain.lan";
option domain-name-servers 192.168.0.4, 192.168.0.5;

default-lease-time 604800;
max-lease-time 2592000;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# A slightly different configuration for an internal subnet.
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.200 192.168.0.230;
option subnet-mask 255.255.255.0;
option routers 192.168.0.254; # Router RTS
option broadcast-address 192.168.0.255;
option domain-name-servers 192.168.0.4, 192.168.0.5, 212.17.192.49, 213.217.149.50;
option domain-name "dogusdomain.lan";
ddns-domainname "dogusdomain.lan";
ddns-rev-domainname "0.168.192.in-addr.arpa";
option netbios-name-servers 192.168.0.4; # kerberos - check wins on smb.conf
option netbios-node-type 8; # Hybrid - WINS, then bcast res.
default-lease-time 4800;
max-lease-time 7200;
}

Ora analizzaremo le righe più importanti

ddns-update-style interim;

Questa riga serve a segnalare il metodo in cui dhcp aggiornera le relative zone. In questo modo avremo un dns dinamico (DDNS).

L'impostazione interim e quella da preferire; è possibile utilizzare anche l'impostazione ad-hoc ma è deprecata e considerata obsoleta.

key "rndc-key" { algorithm hmac-md5; secret "anD24+THog0NNEFB7sW8ug=="; };

Come nei file di configurazione dnsm anche qui va definita la chiave condivisa.

Non c'è da stupirsi se la sintassi è simile a quella di BIND, sono entrambi prodotti di Internet Systems Consortium, Inc.

option domain-name "dogusdomain.lan";option domain-name-servers 192.168.0.4, 192.168.0.5;

Impostiamo il dominio bogusdomain.lan e gli IP dei DNS.

default-lease-time 604800; max-lease-time 2592000;

default-lease-time definisce la durata della configurazione per l'interfaccia di rete.

max-lease-time definisce il tempo massimo per la durata della configurazione per l'interfaccia di rete.

I tempi sono riportati in secondi. Questi sono i parametri predefiniti; è preferibile modificare i parametri nel pool di indirizzi.

authoritative;

Essendo l'unico server dhcp della rete, va decommentata tale linea in modo che sia autoritativo.

log-facility local7;

Questo parametro serve per la gestione dei log. Di solito non è necessario modificarlo.

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.200 192.168.0.230;
option subnet-mask 255.255.255.0;
option routers 192.168.0.254;
option broadcast-address 192.168.0.255;
option domain-name-servers 192.168.0.4, 192.168.0.5;
option domain-name "dogusdomain.lan";
ddns-domainname "dogusdomain.lan";
ddns-rev-domainname "0.168.192.in-addr.arpa";
option netbios-name-servers 192.168.0.4;
option netbios-node-type 8;
default-lease-time 4800;
max-lease-time 7200;
}

Con subnet e netmask definiamo sottorete con relativa netmask.

range ci permette di impostare l'intervallo di indirizzi da utilizzare.

subnet-mask è la maschera di sottorete.

routers ci serve per definire gli IP dei gateway che ci permettono di collegarci ad altre reti, quali ad esempio Internet.

Anche broadcast-address non necessità di spiegazioni; è l'IP di broadcast.

Con domain-name e domain-name-server sono simili a quelli nella sezione globale, ma potrebbero essere diversi.

ddns-domainname ci permette di impostare la zona su cui verranno effettuati gli aggiornamenti, quindi ddns-rev-domainname sarà la zona inversa di tale dominio.

netbios-name-servers serve per impostare il server wins per la rete locale. Qui come server wins è impostato vger; su tale server gira infatti samba con supporto wins (per informazioni su samba, visitate http://www.samba.org)

netbios-node-type impostato a 8 serve per la risoluzione nell'ordine WINS e poi Broadcast.


3. File di configurazione DNS comuni

I file di configurazione DNS utilizzati su entrambi i server sono tratti dalla debian sarge.

I file originali di configurazione DNS (/etc/bind) sono stati salvati su una nuova directory (/etc/bind.sav)

E' consiagliato mantenetre una copia dei file di configurazione originali del pacchetto.

3.1. db.0

$TTL  604800
@ IN  SOA  localhost. root.localhost. (
      1         ; Serial
      604800    ; Refresh
      86400     ; Retry
      2419200   ; Expire
      604800 )  ; Negative Cache TTL

@ IN  NS  localhost.

Serve per broadcast inverso.

Non va modificato.

3.2. db.127

$TTL  604800
@ IN  SOA  localhost. root.localhost. (
      1         ; Serial
      604800    ; Refresh
      86400     ; Retry
      2419200   ; Expire
      604800 )  ; Negative Cache TTL

@     IN  NS  localhost.
1.0.0 IN  PTR  localhost.

Server per loopback  inverso. Non va modificato

3.3. db.255

$TTL  604800
@ IN  SOA  localhost. root.localhost. (
      1         ; Serial
      604800    ; Refresh
      86400     ; Retry
      2419200   ; Expire
      604800 )  ; Negative Cache TTL

@     IN  NS  localhost.

Serve per broadcast inverso. Non va modificato.

3.4. db.empty

$TTL  604800
@ IN  SOA  localhost. root.localhost. (
      1         ; Serial
      604800    ; Refresh
      86400     ; Retry
      2419200   ; Expire
      604800 )  ; Negative Cache TTL

@     IN  NS  localhost.

Questo file viene utilizzato dalle zone descritte nell'RFS1918. E' ottimo come modello di partenza per creare un nuovo file di zona.

3.5. db.local

$TTL  604800
@ IN  SOA  localhost. root.localhost. (
      1         ; Serial
      604800    ; Refresh
      86400     ; Retry
      2419200   ; Expire
      604800 )  ; Negative Cache TTL

@     IN  NS  localhost.
@     IN  A   127.0.0.1

Questo file viene usato per il loopback. Non va modificato.

3.6. zones.rfc1918

zone "10.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };

zone "16.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "17.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "18.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "19.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "20.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "21.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "22.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "23.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "24.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "25.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "26.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "27.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "28.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "29.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "30.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "31.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };

#zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };

Questo file va modificato in base alle esigenze.

In questo howto consideriamo che la rete locale abbia come indirizzo 192.168.0.0, quindi la zone 168.192.in-addr.arpa è stato applicato il "#".


4. File di configurazione DNS Primario

Questi sono i file di configurazione presenti sul server vger.bogusdomain.lan (debian sarge)

Il dominio "lan" non esiste tra i  top level domain, tra i quali sono presenti (org, net, edu, com).

Se la vostra ditta ha come dominio bogusdomain.com, l'ideale sarebbe creare una zona local.bogusdomain.com e il server si chiamerebbe vger.local.bogusdomain.com.

4.1. named.conf

include "/etc/bind/named.conf.options";

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";
};
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };
include "/etc/bind/named.conf.local";

Questo file non ha bisogno di modifiche. Le direttive per le zone locali sono definite in named.conf..local.

Questa del file named.conf è presente solo in BIND 9.2.3, pacchetto bind9, su debian sarge.

Su BIND 9.2.1, paccchetto bind9 predefinito di debian woody, si trova solo named.conf.

Allo stesso modo solo su BIND 9.2.3 la delegation-only di net e com è implementata; su BIND 9.2.1 non è disponibile.

4.2. named.conf.local

include "/etc/bind/zones.rfc1918";

key "rndc-key" {
            algorithm hmac-md5;
            secret "anD24+THog0NNEFB7sW8ug--";
};
acl "trusted" { 192.168.0.0/24; 127.0.0.1;};
acl "slave" { 192.168.0.5/24; };

controls {
            inet 127.0.0.1 port 953
            allow { 127.0.0.1; 192.168.0.4; } keys { "rndc-key"; };
};
zone "domainbogus.lan" {
            type master;
            allow-update { key "rndc-key"; };
            allow-query { trusted; };
            allow-transfer { trused; };
            file "/etc/bind/db.domainbogus.lan";
};
zone "0.168.192.in-addr.arpa" {
            type master;
            allow-update { key "rndc-key"; };
            allow-query { trusted; };
            allow-transfer { trused; };
            file "/etc/bind/db.192";
};

Analizziamo le righe più importanti:

acl "trusted" { 192.168.0.0/24; 127.0.0.1;};
acl "slave" { 192.168.0.5/24; };

Dichiariamo le liste di controllo: (1) trusted per comprende tutte le macchine di una sottorete e l'interfaccia di loopback; (2) slave è l'IP del server DNS secondario.

key "rndc-key" {
algorithm hmac-md5;
secret "anD24+THog0NNEFB7sW8ug--";
};

Queste linee definiscono la chiave utilizzata da bind e dhcp per comunicare.

controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; 192.168.0.4; } keys { "rndc-key"; };
};

Definizione di un canale per le comunicazioni amministrative. In questo caso con inet si stabilisce la socket TCP di ascolto e la sua porta il cui valore di predefinito è 953.

zone "bogusdomain.lan" {
        allow-update { key "rndc-key"; };
        allow-query { trusted; };
        allow-transfer { trused; };
        type master;
        file "/etc/bind/db.bogusdomain.lan";
};

Queste direttive definiscono la zona  bogusdomain.lan.

Con l'opzione allow-* si dichiarano i canali o le liste di controllo (acl) a cui permettere una determinata operazione: (1)  con update dichiariamo chi può aggiornare il database di zona; (2) con query chi può eseguire interrogazioni al server dns; (3) con transfer chi può eseguire il trasferimento di zona.

In questo caso, l'aggiornamento di database avviene attraverso il canale con chiave md5, le query e i trasferimenti possono essere eseguite dalle macchine della sottorete presenti nella lista trusted. Per maggiore sicurezza, per il trasferimento si potrebbe impostare la macchina nell'acl slave.

4.3. named.conf.options

options {
directory "/var/cache/bind";
  listen-on { 127.0.0.1; 192.168.0.4; };
  version "IX";
  // forwarders { 0.0.0.0; };

  auth-nxdomain yes; # conform to RFC1035
                     # default is no
};

logging { category lame-servers { null; }; };

Il server è impostato per ricevere le query sulla localhost e sul suo indirizzo IP.

La linea version serve a nascondere la reale versione di BIND. In questo caso all'interrogazione della versione il server non risponderà come 9.2.3, ma come IX, che in romano sarebbe appunto 9.

Non sono stati definiti forwarders, ma ciò non vieta di utilizzarli per alleggerire il carico della rete locale.

I motivi per non utilizzare i dns dell'ISP possono essere tanti, tra i quali:

  • indipendenza dall'ISP
  • scarsa affidabilità dei DNS dell'ISP
  • volontà di utilizzare i Open Root Server http://www.open-rsc.org al posto dei Root Server predefiniti; di questo ne parleremo più avanti.

Assegnado  auth-nxdomain yes si fa in modo che il server sia autoritativo.

Le ultime righe fanno si che non vengano loggati i lame-server.

4.4. db.bogusdomain.lan

$TTL  259200  ; 3 days
@     IN     SOA    ns1.domainbogus.lan. hostmaster.vger.domainbogus.lan. (
                                         2004040010 ; serial
                                         10800      ; refresh (3 hours)
                                         3600       ; retry (1 hours)
                                         604800     ; expire (1 weeks)
                                         3600       ; minimum (1 day)
                                         )
             NS                          ns1.domainbogus.lan.
             NS                          ns2.domainbogus.lan.
             A                           192.168.0.4
             MX     10                   mail.domainbogus.lan.
             TXT                         "dominio principale"

Alpha        A      192.168.0.1
Beta         A      192.168.0.2
Gamma        A      192.168.0.3
vger         A      192.168.0.4
ns1          CNAME  vger
mail         CNAME  vger
voyager6     A      192.168.0.5
ns2          CNAME  voyager6

È stato definito un dominio domainbogus.lan con server autoritativo ns1.domainbogus.lan e hostmaster@vger.domainbogus.lan che rappresenta l'indirizzo di posta a cui va inoltrata la segnalazione di problemi.

Al nome domaingous.lan è assegnato lo stesso indirizzo IP di vger.domainbogus.lan. Il record MX indica quale server si occuperà di smistare la posta per il dominio.

4.5. db.192

$TTL  259200  ; 3 days
@     IN     SOA    ns1.domainbogus.lan. hostmaster.vger.domainbogus.lan. (
                                         2004040010 ; serial
                                         10800      ; refresh (3 hours)
                                         3600       ; retry (1 hours)
                                         604800     ; expire (1 weeks)
                                         3600       ; minimum (1 day)
                                         )
             NS                          ns1.domainbogus.lan.
             NS                          ns2.domainbogus.lan.
             A                           192.168.0.4
             MX    10                    mail.domainbogus.lan
             TXT                        "Zona inversa dominio principale"
1            PTR   alpha.domainbogus.lan.
2            PTR   beta.domainbogus.lan.
3            PTR   gamma.domainbogus.lan.
4            PTR   vger.domainbogus.lan.
5            PTR   voyager6.domainbogus.lan.

Questo file serve per la risoluzione inversa della zona. Non ha bisogno di particolari spiegazioni.


5. File di Configurazione DNS Secondario

Questi sono i file di configurazione presenti sul server voyager6.bogusdomain.lan (debian woody).

5.1. named.conf

include "/etc/bind/named.conf.options";

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

Da notare che le linee di delegation-only non sono state inserite. BIND 9.2.1 non implementa tale funzione.

5.2. named.conf.local

include "/etc/bind/zones.rfc1918";

key "rndc-key" {
        algorithm hmac-md5;
        secret "anD24+THog0NNEFB7sW8ug--";
};

acl "trusted" { 192.168.0.0/24; 127.0.0.1;};

zone "rtsystem.lan" {
        type slave;
        allow-query { trusted; };

        file "/etc/bind/db.rtsystem.lan";
        masters { 192.168.0.4; };
};

zone "0.168.192.in-addr.arpa" {
        type slave;
        file "/etc/bind/db.192";
        masters { 192.168.0.4; };
};

Notare che la sezione per la comunicazione col dhcp è stata eliminata.

Ciò dipende dal fatto che si presume che il server vger sia in downtime per aggiornamento/manutenzione; tale servizio non sarà quindi disponibile.

Su un server secondario si imposta type come slave e poi si indica il master (o i master, dipende dai casi).

Si poteva impostare anche questo server come master, ma per una questione di affidabilità/robustezza della rete, è sempre meglio avere almeno un server di tipo slave.

I dati vengono copiati tra i server sfruttando il trasferimento di zona - zone transfer - che può a seconda dei casi essere addizionale (AXFR) o incrementale (IXFR).

5.3. named.conf.options

options {
        directory "/var/cache/bind";
        listen-on { 127.0.0.1; 192.168.0.5; };

        version "IX";

        // forwarders { 0.0.0.0; };

        auth-nxdomain yes; # conform to RFC1035
                          # default is no
};

logging { category lame-servers { null; }; };

Questo file non ha subito grandi modifiche. Non necessita quindi di spiegazioni.

5.4. db.bogusdomain.lan

Non è necessario creare il file db.bogusdomain.lan. Dopo aver configurato named.conf.local ed aver avviato il servizio named, il sistema si occuperà di creare il file.

Se il file esiste già, assicurarsi che il seriale sia inferiore a quello del master, in modo che avvenga la sincronizzazione.

5.5. db.192

Anche per questo file non è necessaria alcuna operazione. Come per il precedente, se non esiste verrà creato.

Valgono le stesse regole del precendente.


6. I Root Server

I root server sono quelle macchine che memorizzano i Top Level Domain (TLD).

Qui in questa sezione non ne spiegherò il funzionamento. Tale compito lo lascio al DNS Howto di Nicolai Langfeldt.

6.1. db.root

; <<>> DiG 9.2.3 <<>> @e.root-servers.net . ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38134
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
.                     518400  IN  NS I.ROOT-SERVERS.NET.
.                     518400  IN  NS J.ROOT-SERVERS.NET.
.                     518400  IN  NS K.ROOT-SERVERS.NET.
.                     518400  IN  NS L.ROOT-SERVERS.NET.
.                     518400  IN  NS M.ROOT-SERVERS.NET.
.                     518400  IN  NS A.ROOT-SERVERS.NET.
.                     518400  IN  NS B.ROOT-SERVERS.NET.
.                     518400  IN  NS C.ROOT-SERVERS.NET.
.                     518400  IN  NS D.ROOT-SERVERS.NET.
.                     518400  IN  NS E.ROOT-SERVERS.NET.
.                     518400  IN  NS F.ROOT-SERVERS.NET.
.                     518400  IN  NS G.ROOT-SERVERS.NET.
.                     518400  IN  NS H.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
I.ROOT-SERVERS.NET.  3600000  IN  A  192.36.148.17
J.ROOT-SERVERS.NET.  3600000  IN  A  192.58.128.30
K.ROOT-SERVERS.NET.  3600000  IN  A  193.0.14.129
L.ROOT-SERVERS.NET.  3600000  IN  A  198.32.64.12
M.ROOT-SERVERS.NET.  3600000  IN  A  202.12.27.33
A.ROOT-SERVERS.NET.  3600000  IN  A  198.41.0.4
B.ROOT-SERVERS.NET.  3600000  IN  A  192.228.79.201
C.ROOT-SERVERS.NET.  3600000  IN  A  192.33.4.12
D.ROOT-SERVERS.NET.  3600000  IN  A  128.8.10.90
E.ROOT-SERVERS.NET.  3600000  IN  A  192.203.230.10
F.ROOT-SERVERS.NET.  3600000  IN  A  192.5.5.241
G.ROOT-SERVERS.NET.  3600000  IN  A  192.112.36.4
H.ROOT-SERVERS.NET.  3600000  IN  A  128.63.2.53
;; Query time: 297 msec
;; SERVER: 192.203.230.10#53(e.root-servers.net)
;; WHEN: Sat Apr 3 19:48:17 2004
;; MSG SIZE rcvd: 436

6.2. rootsvr-control

La versione originale di questo script di Al Longyear è disponibile nella sezione Manutenzione di DNS Howto di Nicolai Langfeldt.

Riporto di seguito la versione modificata che utilizzo.

#!/bin/sh
#
# Update the nameserver cache information file once per month.
# This is run automatically by a cron entry.
#
# Original by Al Longyear
# Updated for BIND 8 by Nicolai Langfeldt
# Miscelanious error-conditions reported by David A. Ranch
# Ping test suggested by Martin Foster
# named up-test suggested by Erik Bryer.
#
(
  echo "To: hostmaster <hostmaster>"
  echo "From: system <root>"
  # Is named up? Check the status of named.
  case `rndc status 2>&1` in
    *refused*)
    echo "named is DOWN. db.root was NOT updated"
    echo
    exit 0
    ;;
  esac
  PATH=/sbin:/usr/sbin:/bin:/usr/bin:
  export PATH
  # NOTE: /etc/bind must be writable only by trusted users or this script
  # will cause root compromise/denial of service opportunities.
  cd /etc/bind 2>/dev/null || {
  echo "Subject: Cannot cd to /etc/bind, error $?"
  echo
  echo "The subject says it all"
  exit 1
  }
  # Are we online? Ping a server at your ISP
  case `ping -qnc 1 some.machine.net 2>&1` in
    *'100% packet loss'*)
    echo "Subject: db.root NOT updated. The network is DOWN."
    echo
    echo "The subject says it all"
    exit 1
    ;;
  esac
  dig @e.root-servers.net . ns >db.root.new 2> errors
  case `cat db.root.new` in
    *NOERROR*)
    # It worked
    :;;
    *)
    echo "Subject: The db.root file update has FAILED."
    echo
    echo "The db.root update has failed"
    echo "This is the dig output reported:"
    echo
    cat db.root.new errors
    exit 1
    ;;
  esac
  echo "Subject: The db.root file has been updated"
  echo
  echo "The db.root file has been updated to contain the following information:"
  echo
  cat db.root.new
  chown bind.bind db.root.new
  chmod 644 db.root.new
  rm -f db.root.old errors
  mv db.root db.root.old
  mv db.root.new db.root
  rndc restart
  echo
  echo "The nameserver has been restarted to ensure that the update is complete."
  echo "The previous db.root file is now called  
  /etc/bind/db.root.old."
) 2>&1 | /usr/lib/sendmail -t
exit 0

Su una debian woody, in chown utilizzate root.root pechè non esiste uid bind e gid bind.

Inoltre converrebbe sostituire:

rndc restart

con

/etc/init.d/bind9 restart

o

/etc/init.d/bind9 reload

Questo perché rndc non supporta l'opzione restart.

Nel crontab ho inserito la riga seguente:

0 0 1 * * /root/.bin/rootsvr-control >/dev/null 2>&1

7. Rete con Samba 

Fino a Windows NT 4 i sistemi si basavano su WINS; WINS è un'implementazione degli RFC1001/1002 di NetBIOS Name Service (NBNS).

Con l'avvento di Windows 2000, si è passati ad una gestione basata sull'uso di DNS e Active Directory.

Qui non verrà spiegato l'uso di Microsoft DNS o Active Directory, ma l'integrazione di tra BIND, DHCP e Samba in un Dominio Windows 2000.

Si presuppone che la rete si trovi dietro un firewall. Alcuni di queste impostazioni sono insicure e all'avvio/riavvio lo stesso BIND ve lo segnalerànei log di sistema.

I file di configurazione utilizzati sono quelli del master server. Samba è installato sullo stesso server in cui si trova BIND e DHCP.

Per informazioni su samba consultate il sito ufficiale.

7.1. named.conf, named.conf.options

I file named.conf e named.conf.options non hanno subito alcuna modifica.

Sono più che validi così.

7.2. named.conf.local

acl "trusted" { 192.168.0.0/24; 127.0.0.1;};
acl "slave" { 192.168.0.5/24; };

controls {
            inet 127.0.0.1 port 953
            allow { 127.0.0.1; 192.168.0.4; } keys { "rndc-key"; };
};
zone "domainbogus.lan" {
            type master;
            allow-update { trusted; };
            allow-query { trusted; };
            allow-transfer { trused; };
            file "/etc/bind/db.domainbogus.lan";
};
zone "_msdc.domainbogus.lan" {
            type master;
            allow-update { trusted; };
            allow-query { trusted; };
            allow-transfer { trused; };
            file "/etc/bind/db._msdc.domainbogus.lan";
};
zone "_site.domainbogus.lan" {
            type master;
            allow-update { trusted; };
            allow-query { trusted; };
            allow-transfer { trused; };
            file "/etc/bind/db._site.domainbogus.lan";
};
zone "_tcp.domainbogus.lan" {
            type master;
            allow-update { trusted; };
            allow-query { trusted; };
            allow-transfer { trused; };
            file "/etc/bind/db._tcp.domainbogus.lan";
};
zone "_udp.domainbogus.lan" {
            type master;
            allow-update { trusted; };
            allow-query { trusted; };
            allow-transfer { trused; };
            file "/etc/bind/db._udp.domainbogus.lan";
};
zone "0.168.192.in-addr.arpa" {
            type master;
            allow-update { trusted; };
            allow-query { trusted; };
            allow-transfer { trused; };
            file "/etc/bind/db.192";
};

Il file named.conf.options è stato modificato perchè il server DNS possa servire anche un dominio Windows 2000.

Le zone _*.bogusdomain.lan sono necessari al corretto funzionamento di Active Directory..

Da notare che allow-update è impostato per far riferimento alla lista di controllo (acl) trusted e non ad un canale con chiave md5.

Ciò è necessario perchè i client windows al loro avvio possano registrare le informazioni nelle zone _*.bogusdomain.lan.

7.3. dhcpd.conf

Anche questo file non ha bisogno di modifiche.


8. Collegamenti

I dati sono in ordine alfabetico.

8.1. Documentazione

bind9.net - DNS, BIND, DHCP, LDAP e Directory Services.

DNS-Howto di Nicolai Langfeldt - Risale a fine 2001, però è ancora un documento valido.

DNS Resources Directory -  Un punto di informazione.

OpenSkills - L'Esperimento Aperto di Knowledge Condiviso per System & Network Administrator: ci si trovano molte informazioni utili.

8.2. Libri

DNS and BIND, 4th Edition(Aprile 2001) - di Paul Albitz e Cricket Liu. Edito dalla O'Really. In lingua Inglese.

8.3. Software

Debian - La distro Linux utilizzata.

ISC - I produttori di DHCP e BIND-

Samba - Per creare un fileserver su UNIX accessibile da Windows che utilizza il protocollo SMB/CIFS.

SETI@home - I server e le workstation che uso, durante la notte elaborano i dati SETI@home.