BIND 9.20

🔥 BIND 9 (Berkeley Internet Name Domain) è il software server DNS (Domain Name System) più utilizzato su Internet in ambiente Linux. Il suo compito principale è quello di tradurre i nomi di dominio leggibili dall’uomo (come www.esempio.com) in indirizzi IP numerici (come 192.0.2.1) che i computer utilizzano per comunicare tra loro. La relazione IP e dominio e univoca: un solo indirizzo IP per un solo dominio e viceversa.

Quanto illustrato nell’ immagine sopra, è il minimo per avere internet a portata d’ uomo, senza il servizio DNS dovreste individuare i vari dispositivi collegati alla rete (clients) e i servizi offerti (server) utilizzando gli indirizzi IP, che sono dei numeri. La rete sarebbe composta dai router con i relativi protocolli comunicazione per la realizzazione e lo scambio delle tabelle d’ instradamento utilizzate dai router stessi per inoltrare i pacchetti dati: le informazioni.

🛠️ COMANDI PER L’INSTALLAZIONE di BIND 9.20

sudo apt install bind9 bind9utils bind9-doc dnsutils -y

bind9: il server DNS vero e proprio — bind9utils: strumenti utili per test e debug di bind9 — bind9-doc: documentazione opzionale — dnsutils: comandi come dig e nslookup per verificare il funzionamento del sistema DNS.

La porta 53 (TCP/UDP) deve essere aperta perché le query DNS funzionino. Aprire la porta DNS (TCP/UDP 53) è fondamentale per permettere le query e le risposte DNS tra client e server. Il DNS usa principalmente la porta UDP 53 per le query grazie alla sua velocità, ma passa alla porta TCP 53 per risposte più grandi: dnssec, o trasferimenti di zona.

⭐ – Ecco una panoramica delle sue caratteristiche principali e delle possibilità di configurazioni base:

1. Funzionalità principali

• Server Autorevole: Gestisce e risponde delle zone di cui possiede i record ufficiali, server di zona per Bind o Authoritative Name Server nella gerarchia DNS, è l’ ultimo name server, quello che fornisce gli indirizzi IP collegati al dominio.
• Server Ricorsivo (Recursive o Resolver): ha tre modi di funzionamento: 1)verifica se può risolvere usando la cache altrimenti interroga altri server DNS per trovare l’indirizzo IP richiesto da un client e ne salva il risultato in cache per velocizzare le richieste successive; 2)inoltra la richiesta se non presente nella cache a un altro server ricorsivo; 3)misto, inizia il secondo metodo (forwader) se il risultato è negativo prova con il primo metodo (resolver).
• Supporto DNSSEC: Offre funzionalità di sicurezza per crittografare e autenticare le risposte DNS, prevenendo attacchi come lo spoofing.

2. I file di configurazione di BIND9, sono quelli che offrono le diverse possibilità di funzionamento e si trovano solitamente nella directory /etc/bind/.

• named.conf: Il file principale che include tutti gli altri file di configurazione.
• named.conf.options: Contiene le impostazioni globali (ad esempio, a quali indirizzi IP rispondere, i forwarder da usare, o l’abilitazione delle query ricorsive).
• named.conf.local: Utilizzato per definire le zone locali (i domini che il server deve gestire).
• db.*: file di zona contenenti i record DNS.

Quando parliamo di BIND 9 nel ruolo di Name Resolver (risolutore di nomi), ci riferiamo alla sua capacità di prendere una richiesta del tipo “qual è l’indirizzo IP di google.com?” da un client (come il tuo browser) e trovare la risposta navigando nella gerarchia del DNS. Ecco come funziona in dettaglio questa componente.

1. I due volti di BIND 9 come Resolver ed un terzo volto come Authoritative name server:

In BIND 9, la risoluzione può essere configurata principalmente in due modi, a seconda delle esigenze della rete:

✅A. Resolver Ricorsivo (Caching Name Server)

È il comportamento standard di un server DNS ISP o aziendale. Quando riceve una query da un client:

1. Controlla nella sua cache locale. Se ha già la risposta, la restituisce subito.
2. Se non ce l’ha, interroga i Root Server (i server radice sono 13).
3. Il Root Server lo indirizza ai server del TLD (Top-Level Domain, es. .com).
4. Il server TLD lo indirizza ai Server Autorevoli del dominio specifico (es. google.com).
5. Il server autorevole di zona/dominio o Authoritative Name Server fornisce l’IP finale. BIND 9 salva il risultato in cache (per il tempo stabilito dal TTL) e lo invia al client.

✅B. Forwarding Resolver (Inoltratore)

Invece di fare tutto il lavoro di ricerca da solo (iterazione), BIND 9 può essere configurato per inoltrare tutte le richieste a un altro resolver più a monte (come i DNS di Google 8.8.8.8 o di Cloudflare 1.1.1.1).

• Continua a mantenere una cache locale per velocizzare le richieste successive, ma risparmia banda e risorse non dovendo ripetere il processo iterattivo di contattare i server autorevoli con le richieste recursive, iniziando dai Root Server fino ai Name Server.

2. Configurazione in named.conf per ricorsivo e inoltratore.

Il comportamento del resolver in BIND 9 si definisce principalmente nel file di configurazione named.conf (di solito dentro la sezione options).

Ecco un esempio pratico di configurazione per un Resolver Ricorsivo:

options {
    directory "/var/cache/bind";

    // 1. Abilita la ricorsione
    recursion yes;

    // 2. Sicurezza: permette le query solo dalla rete locale (LAN)
    allow-query { localhost; 192.168.1.0/24; };
    allow-recursion { localhost; 192.168.1.0/24; };

    // 3. Nasconde la versione di BIND per sicurezza
    version "Not Disclosed";

    // 4. Abilita la validazione DNSSEC (fondamentale per i resolver moderni)
    //dnssec-validation auto; //se abilitate avete DNS sicuro, dovete gestire a priori i certificati
};

Se invece volessi trasformarlo in un Forwarding only Resolver, la configurazione cambierebbe così:

options {
    directory "/var/cache/bind";
    recursion yes;
    
    // Inoltra le query a Cloudflare e Google
    forwarders {
        1.1.1.1;
        8.8.8.8;
    };
    // "forward only" significa che se i forwarder non rispondono, non prova a fare ricorsione da solo
    forward only; 
};

3. Funzionalità Chiave del Resolver BIND 9

• Gestione della Cache: BIND 9 memorizza temporaneamente le risposte per evitare di sovraccaricare la rete. Rispetta il TTL (Time to Live) impostato dai proprietari dei domini, ma i sistemisti possono svuotare manualmente la cache in caso di problemi usando il comando:Bashrndc flush
• Validazione DNSSEC: Un resolver moderno deve essere sicuro. BIND 9 verifica le firme digitali dei record DNS per garantire che i dati non siano stati manomessi o falsificati durante il tragitto (evitando attacchi di tipo DNS Spoofing o Cache Poisoning).
• RNDC (Remote Name Daemon Control): È lo strumento a riga di comando che permette di gestire il resolver in tempo reale (ricaricare la configurazione, vedere lo stato, svuotare la cache) senza dover riavviare l’intero servizio.

4. Best Practice di Sicurezza per un Resolver

Un errore comune nel configurare BIND 9 come resolver è creare un Open Resolver (risolvitore aperto). Se il tuo server accetta query ricorsive da chiunque su Internet, i malintenzionati potrebbero usarlo per lanciare attacchi informatici (come i DNS Amplification DDoS).

• Regola d’oro: Usa sempre la direttiva allow-recursion per limitare la risoluzione solo ai tuoi dispositivi o alla tua sottorete fidata.

✅C. BIND come Server Autorevole (Authoritative)

BIND 9 è estremamente versatile perché può essere configurato per svolgere diversi ruoli, separando o unendo le funzioni di Server Risolutore (Caching-Forwader, Caching-Recursive, Caching-Forwader-Recursive) e Server Autorevole (Authoritative). Ecco un’analisi dettagliata di come funziona BIND9 come solo risolutore autorevole.

Un server autorevole è il “proprietario” ufficiale di una determinata zona DNS (es. tuosito.it). Non cerca le informazioni in giro per la rete: ha già le risposte scritte nei suoi file di configurazione locali e risponde solo per i domini che gestisce direttamente. Rifiuta le recursive richieste inviate dai vari dispositivi se non sono di sua competenza.

Caratteristiche principali:

• Nessuna ricorsione: Se gli viene chiesto un dominio che non conosce (es. google.com mentre gestisce solo tuosito.it), risponde con un errore (REFUSED o NXDOMAIN) oppure reindirizza la richiesta, ma non va a cercarla per conto dell’utente.
• Tipi di Server Autorevoli:
  • Primary (Master): Contiene la copia originale e modificabile del file di zona.
  • Secondary (Slave): Mantiene una copia esatta del file di zona, sincronizzandosi con il Master tramite un processo chiamato Zone Transfer (AXFR o IXFR).

Confronto Diretto

Caratteristica	Server Risolutore (Resolver)	Server Autorevole
Scopo principale	Trovare gli IP per gli utenti naviganti.	Pubblicare gli IP dei propri domini nel mondo.
Chi lo interroga?	I client della rete locale (PC, Router).	Altri server DNS sparsi per il web.
Uso della Cache	Fondamentale per velocizzare la navigazione.	Non usa la cache di altri; legge i propri file.
Configurazione tipica	recursion yes;	recursion no; (Best practice se pubblico)

📌 In passato era comune configurare un unico server BIND9 che facesse sia da risolutore per gli utenti interni, sia da server autorevole per il mondo esterno ed interno. Oggi questa pratica è fortemente sconsigliata per motivi di sicurezza e performance. La best practice odierna prevede di:

1. Configurare un server BIND9 solo Autorevole (esposto su Internet, con ricorsione disattivata) per gestire i propri domini.
2. Configurare un server BIND9 (o altri software come Unbound) solo Risolutore all’interno della rete aziendale/domestica per servire i client.

Esempio Pratico: definizione di una zona

Se vuoi che il tuo server sia autorevole per il dominio mio-dominio.it, dovrai aggiungere la zona nel file named.conf.local:

zone "mio-dominio.it" {
    type master;
    file "/etc/bind/db.mio-dominio.it";
    allow-transfer { 192.168.1.5; }; // IP del server secondario
};

Successivamente, si crea il file di zona corrispondente (db.mio-dominio.it) per inserire i record DNS (SOA, NS, A, MX, ecc.):

$TTL    604800
@       IN      SOA     ns1.mio-dominio.it. root.mio-dominio.it. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.mio-dominio.it.
ns1     IN      A       192.168.1.10
www     IN      A       192.168.1.20

👞 Quanto esposto sopra è riservato al caso di dns solo primary ed in assenza di reverse-zone, grave carenza. Se lo utilizzate al posto del server autorevole del vostro provider dns come ad esempio Aruba, non avendo due ip pubblici per forza di cose potete collegare ad internet solo server primary. La reverse-zone al fine delle richieste PTR sarebbe meglio realizzarla sempre. Se fate questo al fine di ottenere la wildcard di LetsEncrypt dovete aggiungere anche un plugin per bind9, leggi post su LetsEncrypt.

Comandi Utili per la Gestione. Per verificare che la configurazione non contenga errori di sintassi prima di riavviare il servizio, si usano questi comandi:

• Controllo configurazione generale: named-checkconf
• Controllo sintassi di una zona: named-checkzone mio-dominio.it /etc/bind/db.mio-dominio.it
• Riavviare il servizio: sudo systemctl restart bind9

🔎✨🧠📌⭐🛒🧑❓1️⃣2️⃣3️⃣4️⃣👍✅👤🧭🧪➡️✔😊🔥🚀🎯⚠️🚗🏍️🚚🦜🦿🛝🧩🌬️💡🛠️💬🔄️🍾👉👞👠