#format wiki
#LANGUAGE it
<
>
<>
<>
= Introduzione =
== Cos'è e a cosa serve il DNS ==
In una rete di computer, ogni dispositivo (nodo) è identificato da un [[https://it.wikipedia.org/wiki/Indirizzo_IP|indirizzo IP]]. Memorizzare questi numeri è scomodo. Il '''D'''omain '''N'''ame '''S'''ystem (DNS) è un servizio che traduce nomi facili da ricordare (es. `www.example.com`) nei rispettivi indirizzi IP, e viceversa.
Il DNS è un sistema gerarchico e distribuito. Invece di avere un unico server per tutta Internet, esistono server autoritari per specifiche "zone" (domini come `example.com`), che a loro volta fanno riferimento a server di livello superiore (es. i server per `.com`).
== Prerequisiti ==
* '''Hardware''': Per un server DNS critico, è consigliabile utilizzare hardware dedicato.
* '''Partizionamento''': Se possibile, creare [[Hardware/DispositiviPartizioni/PartizionamentoManuale|partizioni separate]] per i log (`/var/log`) e per la cache di BIND (`/var/cache/bind`) può migliorare le prestazioni e la gestibilità.
== Risoluzione Locale: il file /etc/hosts ==
Prima del DNS, la risoluzione dei nomi avveniva tramite il file `/etc/hosts` su ogni singola macchina. Questo file contiene una semplice mappa di indirizzi IP e nomi.
* '''Vantaggi''': Risoluzione immediata, nessuna dipendenza dalla rete.
* '''Svantaggi''': Ingestibile su reti di medie/grandi dimensioni, poiché ogni modifica deve essere replicata su tutte le macchine.
= Installazione di BIND9 =
Per installare '''BIND9''', il software DNS più diffuso su sistemi opensource basati su Debian/Ubuntu, eseguire con il [[AmministrazioneSistema/Terminale|terminale]] il seguente comando:{{{
sudo apt install bind9 bind9utils -y
}}}
{{{#!wiki note
bind9utils include strumenti utili per la diagnostica, come '''dig''' e '''named-checkconf'''.
}}}
= Struttura della Configurazione =
La configurazione di '''BIND9''' si trova principalmente nella directory `/etc/bind/`.
* `/etc/bind/named.conf`: File principale che include gli altri file di configurazione.
* `/etc/bind/named.conf.options`: Contiene le opzioni globali del server, come i forwarder e le liste di controllo degli accessi (ACL).
* `/etc/bind/named.conf.local`: File designato per aggiungere le configurazioni delle zone locali (i domini che il server gestirà).
* `/var/cache/bind/`: Directory dove BIND può scrivere i file di zona per i server slave e i dati di cache.
* `/var/log/`: I log di BIND sono solitamente gestiti da syslog o journald. Per problemi, consultare il file `/var/log/syslog` o dal [[AmministrazioneSistema/Terminale|terminale]] il comando:{{{
journalctl -u bind9
}}}
= Scenario 1: Configurare un Caching-Only Nameserver =
Un server DNS "caching-only" non è autoritario per nessun dominio. Il suo unico scopo è ricevere le richieste dai client della LAN, inoltrarle ai server DNS di Internet, e memorizzare (mettere in cache) le risposte per accelerare le richieste future.
La configurazione di default di '''BIND9''' è già quasi pronta per questo scopo.
0. Modificare le opzioni: Aprire con un [[Ufficio/EditorDiTesto|editor di testo]] e i [[AmministrazioneSistema/PrivilegiDiAmministrazione|privilegi di amministrazione]] il file `/etc/bind/named.conf.options` e aggiungere o modificare la direttiva `forwarders` per specificare a quali DNS esterni inoltrare le richieste.
{{{
// /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// Inserisci qui gli IP dei DNS del tuo ISP o DNS pubblici (es. Google, Cloudflare)
+ forwarders {
+ 8.8.8.8;
+ 1.1.1.1;
+ };
// Assicura che la ricorsione sia permessa solo ai tuoi client fidati
// Di default, BIND permette la ricorsione da 'localhost' e 'localnets'
allow-recursion { localhost; localnets; };
dnssec-validation auto;
listen-on-v6 { any; };
};
}}}
0. Avviare e abilitare il [[AmministrazioneSistema/Systemd|servizio]] systemd:{{{
sudo systemctl start bind9
sudo systemctl enable bind9 # Per avviarlo automaticamente al boot
}}}
Ora configurare i client della rete LAN per usare l'indirizzo IP di questo server come loro resolver DNS.
= Scenario 2: Configurare un DNS Autoritario =
Un server DNS autoritario è responsabile per uno o più domini. Fornisce risposte "ufficiali" per i nomi host all'interno di quelle zone. Configurare un server master per il dominio ''example.com''.
Scenario di esempio:
* '''Dominio''': example.com
* '''Rete''': 192.168.1.0/24
* '''DNS Master Server (ns1)''': 192.168.1.10
== Configurazione del Master Server ==
Modificare il file `/etc/bind/named.conf.local` per dichiarare le zone.
{{{
// /etc/bind/named.conf.local
// Zona di ricerca diretta (nome -> IP)
zone "example.com" {
type master;
file "/etc/bind/db.example.com"; // Percorso al file di zona
allow-transfer { none; }; // Impedisce trasferimenti di zona non autorizzati
};
// Zona di ricerca inversa (IP -> nome)
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.1.168.192"; // Notare l'ordine inverso degli ottetti dell'IP
allow-transfer { none; };
};
}}}
== Creazione dei File di Zona ==
=== File di Zona Diretta (''/etc/bind/db.example.com'') ===
Creare il file `/etc/bind/db.example.com` con il seguente contenuto:{{{
; File di zona per example.com
$TTL 3H ; Time-To-Live di default: 3 ore
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; Seriale (Formato YYYYMMDDNN - **INCREMENTARE AD OGNI MODIFICA**)
8H ; Refresh (ogni quanto uno slave controlla per aggiornamenti)
2H ; Retry (intervallo di riprova se il master non risponde)
4W ; Expire (dopo quanto tempo uno slave considera i dati non validi)
1H ) ; Negative Cache TTL (per quanto tempo ricordare che un record non esiste)
; Name Servers
@ IN NS ns1.example.com.
; Mail Exchanger
@ IN MX 10 mail.example.com.
; Record di tipo A (Address)
ns1 IN A 192.168.1.10
mail IN A 192.168.1.20
server1 IN A 192.168.1.30
; Alias (Canonical Name)
www IN CNAME server1.example.com.
}}}
{{{#!wiki important
Il punto '''.''' alla fine di un nome di dominio completo (FQDN) è obbligatorio e significa "la radice del DNS".<
>Il simbolo @ è una scorciatoia per il nome della zona (in questo caso, example.com).<
>''admin.example.com.'' corrisponde all'email `admin@example.com`.
}}}
=== File di Zona Inversa (/etc/bind/db.1.168.192) ===
Creare il file `/etc/bind/db.1.168.192`:{{{
; File di zona inversa per la rete 192.168.1.0/24
$TTL 3H
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; Seriale (deve essere sincronizzato con la zona diretta)
8H ; Refresh
2H ; Retry
4W ; Expire
1H ) ; Negative TTL
; Name Server
@ IN NS ns1.example.com.
; Record PTR (Pointer - mappa l'ultimo ottetto dell'IP a un nome)
10 IN PTR ns1.example.com.
20 IN PTR mail.example.com.
30 IN PTR server1.example.com.
}}}
== Validazione e Riavvio ==
Prima di riavviare '''BIND''', è fondamentale validare la configurazione:{{{
# Controlla la sintassi dei file di configurazione
sudo named-checkconf
# Controlla la sintassi di un file di zona
sudo named-checkzone example.com /etc/bind/db.example.com
sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.1.168.192
}}} Se non ci sono errori, ricarica la configurazione:{{{
sudo systemctl reload bind9
}}}
= Configurazione Avanzata: Master/Slave e Sicurezza =
== Configurazione di un DNS Slave (Fault Tolerance) ==
Per garantire la continuità del servizio, è buona pratica configurare un secondo server DNS (slave) che si sincronizzi automaticamente con il master.
Scenario di esempio:
* DNS Master (ns1): 192.168.1.10
* DNS Slave (ns2): 192.168.1.11
=== Sul Master (''ns1'') ===
Modificare `/etc/bind/named.conf.local` per permettere il trasferimento della zona solo allo slave:{{{
// /etc/bind/named.conf.local (sul MASTER)
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
+ allow-transfer { 192.168.1.11; }; // IP del server SLAVE
};
//... zona inversa ...
}}} E aggiungi il record NS per il server slave nel file di zona `/etc/bind/db.example.com`:{{{
; /etc/bind/db.example.com (sul MASTER)
; ...
@ IN NS ns1.example.com.
+ @ IN NS ns2.example.com.
; ...
+ ns2 IN A 192.168.1.11
}}} Ricorda di incrementare il seriale e ricaricare BIND sul master!
=== Sullo Slave (''ns2'') ===
Installare '''BIND9''' come fatto sul master. Poi, modificare `/etc/bind/named.conf.local`:{{{
// /etc/bind/named.conf.local (sullo SLAVE)
zone "example.com" {
type slave;
file "slaves/db.example.com"; // BIND scriverà questo file automaticamente
masters { 192.168.1.10; }; // IP del server MASTER
};
//... zona inversa ...
}}} Riavvia BIND sullo slave e controlla i log per messaggi di avvenuto trasferimento.
{{{#!wiki note
Non è necessario creare i file di zona sullo slave; BIND li scaricherà dal master.
}}}
== Sicurezza: Access Control Lists (ACL) ==
Le '''ACL''' permettono di definire gruppi di indirizzi IP per applicare regole di accesso. È una buona pratica definirle in `/etc/bind/named.conf.options`.
{{{
// /etc/bind/named.conf.options
acl "trusted-clients" {
localhost;
192.168.1.0/24; // La nostra LAN
};
options {
// ...
allow-query { any; }; // Permette a chiunque di fare query (standard per DNS pubblico)
allow-recursion { trusted-clients; }; // Permette la ricorsione solo ai client fidati
// ...
};
}}}
== Sicurezza: Trasferimenti di Zona con TSIG ==
Per proteggere i trasferimenti di zona tra master e slave, si usa TSIG (Transaction Signature), che si basa su una chiave segreta condivisa.
0. Generare la chiave (sul master):{{{
tsig-keygen -a hmac-sha256 my-key-name > /etc/bind/tsig.key
}}} Questo crea un file `/etc/bind/tsig.key` con una chiave.
0. Configurare Master e Slave:
* Copiare in modo sicuro `/etc/bind/tsig.key` dal master allo slave.
* Impostare i permessi corretti su entrambi:{{{
sudo chown root:bind /etc/bind/tsig.key && sudo chmod 640 /etc/bind/tsig.key
}}}
* Includere la chiave in `/etc/bind/named.conf` (o in un altro file incluso) su entrambi i server:{{{
// Aggiungi questa riga in cima a named.conf
include "/etc/bind/tsig.key";
}}}
* Modificare le configurazioni di zona per usare la chiave.
Sul Master (`named.conf.local`):{{{
server 192.168.1.11 { // IP dello SLAVE
keys { my-key-name; };
};
zone "example.com" {
type master;
//...
allow-transfer { key my-key-name; };
};
}}}
Sullo Slave (`named.conf.local`):{{{
server 192.168.1.10 { // IP del MASTER
keys { my-key-name; };
};
zone "example.com" {
type slave;
//...
masters { 192.168.1.10; };
};
}}}
== Introduzione a DNSSEC (Zone Signing) ==
'''DNSSEC''' (DNS Security Extensions) garantisce l'autenticità e l'integrità dei dati DNS tramite firme crittografiche a chiave pubblica. Impedisce attacchi di tipo "DNS spoofing".
La sua implementazione è complessa e richiede manutenzione (es. rotazione delle chiavi). Questa è una panoramica semplificata.
0. Genera le chiavi (sul master, nella directory di BIND):{{{
cd /etc/bind/
# Generare la Key Signing Key (KSK) e la Zone Signing Key (ZSK)
dnssec-keygen -a ECDSAP256SHA256 -b 2048 -n ZONE -f KSK example.com
dnssec-keygen -a ECDSAP256SHA256 -b 2048 -n ZONE example.com
}}} Questo creerà dei file .key e .private.
0. Includere le chiavi pubbliche nel file di zona:{{{
for key in Kexample.com*.key; do echo "\$INCLUDE $key" >> db.example.com; done
}}}
0. Firmare la zona:{{{
# Il nome del file della chiave KSK sarà generato dal comando precedente
dnssec-signzone -A -N INCREMENT -o example.com -k Kexample.com.+013+...key db.example.com
}}} Questo crea un file `db.example.com.signed`.
0. Aggiornare la configurazione: Modificare `named.conf.local` per puntare al file firmato:{{{
zone "example.com" {
type master;
- file "/etc/bind/db.example.com";
+ file "/etc/bind/db.example.com.signed";
};
}}}
{{{#!wiki important
'''DNSSEC''' richiede una "catena di fiducia". Per un dominio pubblico, si dovrebbe caricare il record DS (generato durante la firma) presso il registrar di dominio. L'argomento è vasto e va oltre questa guida introduttiva.
}}}
= Propagazione delle Informazioni =
Il tempo necessario perché una modifica su un server DNS master si propaghi attraverso la rete dipende da vari fattori, principalmente i valori di TTL e Refresh.
* '''TTL''' (Time-To-Live): Indica ai server DNS esterni (e ai client) per quanto tempo possono tenere in cache un record prima di doverlo richiedere di nuovo.
* '''Refresh''': Indica a un server slave ogni quanto deve contattare il master per verificare se il seriale della zona è cambiato.
Una modifica sul master sarà visibile da un client che interroga uno slave dopo un tempo che, nel peggiore dei casi, è la somma del Refresh dello slave e del TTL che il client aveva precedentemente in cache.
----
CategoryHomepage CategoryNuoviDocumenti