|
Attenzione! Questa è una Pagina di prova. Le informazioni riportate potrebbero essere incomplete, errate e potenzialmente pericolose. Per contribuire alla realizzazione di questa pagina consultare la discussione di riferimento. |
Introduzione
Cos'è e a cosa serve il DNS
In una rete di computer, ogni dispositivo (nodo) è identificato da un indirizzo IP. Memorizzare questi numeri è scomodo. Il Domain Name System (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 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 terminale il seguente comando:
sudo apt install bind9 bind9utils -y
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 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.
Modificare le opzioni: Aprire con un editor di testo e i 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; }; };Avviare e abilitare il 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.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.
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.
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.
- 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.
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.Includere le chiavi pubbliche nel file di zona:
for key in Kexample.com*.key; do echo "\$INCLUDE $key" >> db.example.com; done
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.
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"; };
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.
